How TransactIG is built
Reconciliation looks like a match-or-no-match decision. Underneath, it is a pipeline that ingests heterogeneous data, runs multiple resolution passes, applies India-specific tax overlays, and routes variances into a taxonomy the finance team can act on.
This page describes the architectural shape of TransactIG — the stages every transaction moves through, the configurable tolerance bands that decide what counts as a match, and the India tax overlay that distinguishes us from generic ledger-matching software.
The architecture is the reason customers move from a 51% match rate to 88% inside the first quarter — not a single clever algorithm, but a pipeline engineered for the failure modes Indian books actually present.
Five-stage reconciliation pipeline
Every transaction TransactIG processes moves through the same five stages. Each stage is independently observable and configurable. Read this as the structural sibling of the TransactIQ pipeline — ingest, parse, categorise, engineer features, deliver — so the two product engines share a common operating shape.
Ingest
ERP exports, bank statements, payment-gateway settlement files, marketplace payout reports, and tax-portal downloads (26AS, AIS, GSTR-2B, TRACES challan files) arrive in the formats finance teams actually have — XLSX, CSV, MT940, PDF, password-protected ZIPs, SFTP drops, and direct ERP API pulls. TransactIG accepts all of them. No pre-staging, no format-normalisation handoff to the customer team.
Normalise
Every record is resolved into a canonical transaction shape — date, counterparty, instrument, amount, narration, reference identifier, tax components, and a provenance pointer back to the source row. Narration parsing is India-specific: UPI handles, NEFT references, IMPS beneficiary names, NACH UMRNs, RTGS UTRs, and GST invoice IRNs are recognised by construction, not by regex localisation.
Match (multi-pass)
The engine runs more than one resolution pass over the same data set. Earlier passes lean on strict identifier matching where exact references exist; later passes progressively relax which fields are load-bearing, falling back on economic-identity matching — counterparty, amount, date corridor, narration shape, instrument class. Each pass is independently observable, and a finance lead can see why any given transaction cleared on the pass it cleared on.
Classify variance
Anything that does not clear lands in a typed variance code — timing, partial settlement, fee, tax withholding, FX, missing leg, duplicate, write-off candidate. This is the patent-filed differentiator: variances are not a binary fail bucket, they are a taxonomy that a downstream workflow can act on without human re-triage.
Post back
Cleared matches and classified variances post back into the customer's ERP — journal entries for fee classes, suspense reversals for timing variances, write-off proposals routed to the controller queue, and audit-ready evidence packs against each posting. The reconciliation loop closes where the books live.
Multi-pass matching, not one-shot matching
The single biggest reason naive ledger-matching software stalls at a 50-60% match rate on Indian books is that it tries to clear every transaction in one pass.
TransactIG runs more than one resolution pass over the same data. Earlier passes use strict identifier matching — UTR to UTR, IRN to IRN, UMRN to UMRN — and clear the transactions where the source systems agreed on a reference. Later passes progressively relax which fields are load-bearing, falling back on economic-identity matching when an identifier is truncated, mis-keyed, or absent on one side.
Each pass tightens or relaxes a different surface — date corridor, amount band, narration similarity, counterparty inference. Every cleared match carries a record of which pass cleared it, so a finance lead reviewing the run sees a layered breakdown rather than a single opaque number.
For the pass-by-pass narrative — when to widen a band, when to escalate, how passes interact with industry presets — see the matching engine page.
Configurable tolerance bands
Tolerance bands are how the engine is calibrated to a customer's ledger pair, industry, and workflow. They are configured in business language — finance leads tune them directly. Nothing here requires engineering involvement.
Date corridor
How many calendar or business days a counterparty leg can lead or lag the ERP leg before the engine treats it as a timing variance. Different per ledger pair — a NACH mandate cycle and a Razorpay T+1 settlement live on different clocks.
Amount tolerance
Absolute and percentage bands on the value of a match. Tighter on intercompany ledgers; looser on platform settlements where rounding, fee netting, and slab-based TDS create predictable minor variances.
Narration similarity
A threshold on how close two narration strings need to be before they are treated as the same counterparty event. Calibrated to the rail — UPI narrations carry more signal than RTGS reference lines.
Reference-number partials
How much of a UTR, IRN, UMRN, or invoice reference must match before the field is treated as load-bearing. Allows the engine to handle truncated bank fields and prefix-stripped gateway references without forcing the finance team to clean source data.
The same engine reconciles a multi-specialty hospital's TPA settlement queue and a D2C brand's Razorpay payouts because the tolerances are surface, not core. 24+ industry presets ship with calibrated defaults; customers tune from there.
Patent-filed variance taxonomy
Unmatched transactions are not a binary fail. They are a typed taxonomy that a downstream workflow can act on without human re-triage.
Every variance lands in a typed code that captures why the match did not clear. The classes are stable across industries: timing variance, partial settlement, fee class, tax-withholding variance, FX variance, missing leg, duplicate, and write-off candidate. Each class has a defined downstream action — a controller queue, an auto-journal template, a write-off review, or an escalation.
This is the hand-off point into automated downstream workflows. A timing variance on a T+1 Razorpay payout self-clears on the next run; a tax-withholding variance on a section-194Q payment routes to the AP controller with the deducting amount already computed; a write-off candidate above the policy threshold escalates to the finance head with one click of approval.
For the full classification map and posting playbook, see the variance taxonomy page.
India tax overlay — TDS, GST, TCS, statutory
Every reconciliation in India has a tax shadow. TransactIG carries that shadow inside the engine — not as an after-the-fact report module.
TDS sections in the engine
194C, 194J, 194H, 194I, 194Q, 194R, 194S, 192, 195, 206C and the 2026 migration payment codes (1001-1092) are first-class citizens in the matching logic — not an after-the-fact deduction tab. A settlement leg short by a section-194Q TDS amount is recognised as a tax-withholding variance, not an unmatched.
GSTR-2B and ITC reconciliation
Inward supply records, GSTR-2B downloads, e-invoice IRN linkage, and IMS actions feed the same engine that reconciles bank statements. ITC eligibility is computed from the matched state, not from a separate spreadsheet. DRC-01B and DRC-01C exposures fall out as variance codes a controller can action.
TCS, NACH returns, statutory withholdings
TCS under 206C, NACH bounce reason codes, PF/ESI contributions, and MSME 43B(h) settlement windows are modelled inside the engine so that statutory variances do not need a parallel workbook. The same taxonomy that flags a fee miss flags a PF cheque returned with reason code C04.
Why this matters vs global recon platforms
Generic ledger-matching software treats tax as something a customer overlays after the match clears. In Indian books, the tax is the match — a settlement without its TDS, GST, or TCS leg is incomplete by definition. TransactIG is engineered around that fact.
ERP, bank, gateway, tax — four data planes, one engine
The architecture diagram in prose: four data planes feed one engine, and the engine reconciles across all four in the same workflow. There is no separate sub-product for bank, gateway, or tax — they share a code path.
General ledger, AR sub-ledger, AP sub-ledger, fixed-asset register, and intercompany ledgers from SAP FI/CO, Oracle Fusion, Tally Prime, Zoho Books, Busy, Dynamics 365, Sage, and Odoo. Direct connectors and file-based ingestion are both first-class.
Statements from 200+ Indian bank formats — public sector, private sector, foreign banks, cooperative banks, and small finance banks. MT940, MT942, BAI2, CAMT.053, XLSX, CSV, PDF, and password-protected variants are normalised into the same canonical transaction shape.
Razorpay, PayU, Cashfree, Stripe, and marketplace payout files from Amazon, Flipkart, Meesho, Ajio, Myntra, and Swiggy/Zomato. Fee, tax, refund, and chargeback legs are decomposed before they enter the matching engine — not after.
26AS, AIS, GSTR-2B, TRACES challan files, TDS payment confirmations, and e-invoice IRN registries. Treated as authoritative for tax legs the same way a bank statement is authoritative for cash legs.
For the connector matrix — which ERPs, banks, gateways, and marketplaces ship with native ingestion and which arrive via file drops — see the integrations page.
Operated where the data lives — AWS Mumbai, India residency
All TransactIG deployment shapes keep customer data inside the India data plane. Managed-tier customers run on Terra Insight's AWS Mumbai tenant; private-tier customers receive a dedicated single-tenant data plane; on-premise customers run TransactIG inside their own infrastructure.
RBI Master Direction on Outsourcing of IT Services and the DPDP Act 2023 shape this choice. Data localisation is met by architecture, not by post-hoc process — a reconciliation transaction does not leave India to clear.
Deployment tier selection — managed cloud, private tenant, or on-premise — is driven by the customer's governance posture, not by feature gating. The matching engine, the variance taxonomy, and the tax overlay are identical across tiers. See the deployment page for the tier comparison.
Four architectural principles
The principles that shape TransactIG's reconciliation engine are the same ones that shape TransactIQ's bank statement analysis pipeline. Explicitly stated so customers can judge the products against them.
Deterministic over probabilistic
Every match and every variance is rule-traceable. A finance lead, an internal auditor, or a regulator can follow exactly why the engine cleared a transaction or routed it to a variance class. Where ML is used — narration parsing, layout recognition — its role is classification inside a rule-governed pipeline, not as the final reconciliation verdict.
India-first, not localised
TDS sections, GST forms, NACH return reasons, e-invoice IRNs, and 2026 migration payment codes are built into the engine. The product is not a global recon platform with an Indian localisation pack — the Indian regulatory surface is the core, not an extension point.
Config-driven, not rebuild-driven
Tolerance bands, variance routing, and industry presets are configuration over a common engine. A hospital's TPA settlement workflow and a D2C brand's Razorpay payout workflow share the same code path; the difference is preset. Upgrades apply across tenants without bespoke engineering.
Operated inside the India data plane
All TransactIG deployment shapes — managed cloud, private tenant, on-premise — keep customer data inside India. Managed-tier customers run on Terra Insight's AWS Mumbai tenant; private-tier and on-premise customers run inside their own infrastructure. RBI IT governance direction on data localisation is met by architecture, not by process.
See the security page for the certifications, controls, and regulator-engagement posture in full.
Want the deeper architecture briefing?
Enterprise customers receive a detailed architecture walkthrough — pass-by-pass behaviour, variance code map, India tax overlay coverage — under NDA through the integration window.
Request a demo