Inside the matching engine
The matching engine is the load-bearing piece of TransactIG. It is what turns a 51% baseline match rate into an 88% rate inside a single quarter — without manual intervention growing in proportion to volume.
This page describes the engine conceptually: how multi-pass matching is organised, how tolerance bands are configured, which exception classes the engine recognises, and where real-time matching is appropriate versus batch.
It does not publish pass counts, signal weights, or internal scoring formulas. Those are the patent-protected core. What it does publish is the customer-facing shape — the levers a finance lead actually touches.
Multi-pass resolution, in business language
The matching engine is organised as a sequence of passes, each progressively relaxing a different dimension of strictness. The first pass resolves transactions that share an exact strong identifier — a UTR on a bank credit, an IRN on a GSTR-1 invoice, a challan number on a TDS deposit, a UMRN on a NACH presentment. The strong-identifier pass clears the easy volume cleanly and quickly.
On the residual that remains, the engine runs progressively economic-identity-based resolution — the same transaction recognised by counterparty, amount, date band, and narration pattern even though the reference numbers do not line up. This is the layer where most legacy reconciliation tools give up and dump the residual into a manual exception queue. The engine's job here is to close out the residual with as much confidence as the strong-identifier pass closed out the easy volume.
Each subsequent pass touches a different dimension — date band, amount band, reference partial-match, narration similarity, counterparty alias. The exact number of passes, the precise order, and the scoring weights at each stage are part of the patent-protected core and are not published on this page. What is published is the shape: a finance lead configuring TransactIG sees a small number of tolerance levers, not a runtime debugger.
The cumulative outcome is the 51% to 88% match-rate move that customers see inside the first quarter. The remaining 12% is typed by the variance taxonomy — not abandoned to a manual queue.
Configurable tolerance bands
Five tolerance dimensions are exposed to the finance lead — date window, amount window, reference-number strictness, narration similarity, and counterparty alias group. Each is configurable per ledger pair (bank-vs-ERP, gateway-vs-ERP, GSTR-2B-vs-purchase-register, 26AS-vs-TDS-ledger) and each ships with industry-preset defaults so that the team is not starting from a blank slate.
Configurations are versioned and audit-logged. Every change is attributed to an operator, stamped with a time, and bound to the matches it influenced — so the statutory auditor asking why a tolerance band was widened receives a documented answer, not an oral one.
| Tolerance band | What it controls | How it is set |
|---|---|---|
| Date window | How many days on either side of the source date the engine should consider a candidate match. Tuned per ledger pair — bank-vs-ERP is usually narrower than gateway-settlement-vs-ERP because settlement lag is longer. | Configurable per industry preset. Real-time rails (UPI) sit at zero. Batch rails (NACH) sit wider. |
| Amount window | Either an absolute rupee threshold or a percentage of the transaction value. Used to absorb gateway MDR, NACH return-charge deductions, and small rounding differences that would otherwise generate spurious exceptions. | Absolute and percentage are independently configurable. Either can be set to zero for strict matching. |
| Reference strictness | How strict the engine should be about partial-match on identifiers — full string equality, prefix match, contains-substring, or fuzzy similarity above a threshold. Higher strictness reduces false matches; lower strictness recovers more residuals. | Per ledger pair. Bank narration parsing is typically looser than UTR or IRN matching. |
| Narration similarity | A similarity score above which two narration strings are considered to describe the same economic event. Captures the case where the same counterparty appears under different shortened-name conventions across systems. | Scored on a 0 to 1 scale. Production presets sit in a strict band by default. |
| Counterparty aliases | An alias group — multiple legal-entity name strings, GSTINs, and bank account numbers that map to the same economic counterparty. Maintained per tenant. Versioned and audit-logged so that adding an alias is a traceable controls event. | Maintained per tenant. Imported from ERP master where available; editable inside the engine. |
Strong identifiers vs economic identity
A useful way to read the engine is in two halves. The first half clears transactions on strong identifiers — UTR, IRN, challan, mandate reference, virtual-account-number. These are the easy 70 to 80% of volume on most ledger pairs. A reconciliation tool that does only this half looks impressive on a clean test data set and falls over on production data, because production data is where the strong identifiers go missing.
The second half is where the engine earns its keep — economic identity. The same money, under a different label, across two systems. A Razorpay net payout of 96,40,000 against three gross invoices booked at 1,00,00,000 with MDR at roughly 2%, GST on the MDR at 18%, and TDS at 2% under Section 194O withheld by the gateway under the e-commerce operator rules. The reference numbers do not align. The amounts do not align. But the economic identity does, and the engine recognises it as a clean three-to-one match with a typed Fee-and-Tax variance attached to the gap.
A second production-shape example: a Section 194C TDS deduction by a corporate customer against a vendor invoice. The vendor's bank credit is the gross-minus-2%. The vendor's ERP shows an invoice at gross. The vendor's 26AS shows the TDS credit at 2%. The engine resolves the three sources into one matched economic event with the TDS credit treated as a recoverable claim — not as an unexplained shortfall on the bank reconciliation.
This is why a generic global reconciliation product cannot be retrofitted for Indian books. The economic-identity layer is where the Indian tax overlay lives, and the engine is engineered for exactly that overlay.
Exception classes the engine recognises
When a transaction does not clear in any pass, the engine does not dump it into a single undifferentiated exception bucket. It routes it into the variance taxonomy — a typed classification that tells the finance team what shape the residual is, and what the downstream action should be.
Eight headline classes are described below. The full taxonomy is documented on the variance taxonomy page.
Timing differences
In-flight transactions on a closing date — money that has left one ledger but not yet landed in the other. The engine recognises the lead-lag pattern, holds the variance in a timing bucket with an expected clearance window, and ages it down without operator intervention if it clears on time.
Partial settlements
One invoice cleared by multiple receipts, or one receipt covering multiple invoices. Frequent in B2B retainers, milestone-billed IT services contracts, and NACH batch presentment. The engine assembles the many-to-one and one-to-many relationships rather than flagging each leg as an orphan.
Fee and tax variances
Gateway MDR, TDS withheld at source under Sections 194C / 194H / 194J / 194Q, GST on gateway commission, marketplace fees, and the layered netting under TCS Section 52 of the CGST Act. The engine resolves the gross-vs-net mismatch as a typed variance class rather than as unexplained leakage.
Missing legs
The transaction was booked on one system and never recorded on the other — a real revenue or tax leak rather than a reconciliation timing issue. The engine separates these from timing variances so a finance lead can route them straight into recovery rather than a watch list.
Duplicate detection
The same transaction posted twice — most commonly when a manual journal is added in parallel with an automated bank-feed import, or when a returned NACH presentment is re-presented. The engine identifies the duplicate class with the original reference, not just the duplicate amount.
Write-off candidates
Aged residuals below a configurable materiality threshold, with a documented audit trail explaining why they are eligible for write-off. The engine produces the supporting evidence for the journal, rather than the journal being raised without a recoverable variance class behind it.
Currency-conversion variances
Differences between booked-rate and settled-rate on cross-border invoices, gateway settlements in USD or AED, and Section 9 IGST-on-imports situations. The engine separates the FX gain or loss from any underlying mis-match so that the FX variance is not mistaken for a recoverable leakage class.
Aged-out items
Items that have moved past the configured age threshold without clearing through any pass. The engine routes these into a controls bucket rather than letting them silently accumulate in the residual — the bucket that, for most finance teams, was where leakage used to live.
Real-time vs batch — when each fits
The matching engine runs in two operating shapes. The choice is not a product choice; it is a workflow choice. The engine supports either shape, often inside the same tenant for different transaction classes.
Real-time fits
Transactional rails where downstream automation needs an answer in seconds. UPI receipts that trigger an auto-clearance journal. NACH presentment acknowledgments that release a customer dispatch. Virtual-account credits that unlock a B2B credit hold. Real-time matching is also the right shape for high-volume marketplace settlement where queue depth would otherwise build.
Batch fits
Workflows that wait on a regulatory source-of-truth file. Month-end close on the financial ledger. GSTR-2B reconciliation that runs after the 14th. 26AS and AIS reconciliation that runs after the quarter-end deadline. Settlement reconciliation against a payment-aggregator daily statement. Batch is also the right shape for the GST credit-note three-way match where the credit note may arrive in a later month.
Same engine, both shapes
TransactIG supports real-time and batch in the same engine. The pass logic is identical; the difference is whether the engine is event-triggered or schedule-triggered. A finance team can start with a batch-only deployment and move specific transaction classes to real-time as they automate the downstream workflow — no separate product, no re-implementation.
Audit-grade traceability for every cleared match
Every match the engine clears carries a tamper-evident trail. The trail records which pass cleared the match, which fields were load-bearing for the decision, which configuration version was in force at the time, and which operator (if any) intervened. When a statutory auditor under CARO 2020 or an internal-audit function under ICFR asks how a particular ledger entry was cleared, the answer is a line-item one — not a retroactive reconstruction.
The same evidence pack supports a tax-audit response under Section 44AB and a GST departmental scrutiny under Section 61. The Form 3CD reporting line on TDS deductions tracks back to the matched bank credit and the matched 26AS entry. The GSTR-9 annual return ties back to the matched purchase register and the matched GSTR-2B. The auditor does not need to ask for the workings file — the workings file is the matched ledger.
This is the regulator-defensible posture that a finance head running a board-level controls programme actually needs. Match rate is a productivity number; traceability is a controls number. The engine produces both as a single output, not as a choice between them.
Industry presets — 24+ shipped configurations
The engine ships with 24 or more industry presets. Each preset is a starting configuration of tolerance bands, tax-overlay rules, and variance-taxonomy routings tuned for that vertical's typical book shape. An NBFC ledger does not look like a hospital ledger does not look like a D2C marketplace ledger. A new customer in any of these verticals does not start from zero — they start from a preset that already knows the shape of their reconciliation.
Presets are starting points, not lockdowns. Every tolerance band, alias group, and taxonomy routing is editable per tenant. The preset is the floor on day one; the configuration history is owned by the customer from week two onward.
What we do not publish, and why
The pass-by-pass internal mechanics, the specific tolerance defaults that ship in each industry preset, and the scoring approach used inside individual passes are patent-protected and not described on this page. We describe the customer-facing shape of the engine in full detail. We do not describe the engineering inside it.
Customers under NDA receive a deeper engineering walkthrough during the evaluation window — sufficient depth to make a board-level architecture decision, sufficient protection to keep the engine's competitive position intact for the customers who have already adopted it. This is the same posture TransactIQ takes on its OCR engine: describe the shape, withhold the trade-secret core.
What this page is not, deliberately: an internal engineering document published in public, where a fast follower could read the architecture out of the marketing site and arrive at a same-shape product in a quarter. That posture would not serve customers who have already chosen the engine on the basis that the architecture stays defensible.
Information security management system certified against the 2022 revision of the ISO standard.
Consent, purpose-limitation, data-retention, and fiduciary-duty requirements shape every operating surface of the matching engine.
Master Directions on Outsourcing of IT Services and IT Governance shape the operating model for regulated-entity customers.
Customer ledger data and matched evidence never leave the India data plane on any TransactIG deployment tier.
See the engine on your own ledger
Terra Insight will run a live matching walkthrough on a slice of your real data — not a demo dataset. You will see the pass results, the typed variances, and the rupees attached to each class. Evaluating customers receive the deeper engineering briefing under NDA.
Request a walkthrough