Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
At 200 transactions per month, a finance team can reconcile in a spreadsheet. At 2,000 transactions, the spreadsheet becomes the problem — not the solution. A reconciliation engine exists for the scale where manual matching breaks down.
Core Components of a Reconciliation Engine
A reconciliation engine has four functional components that distinguish it from a spreadsheet or an ERP module:
1. Data ingestion layer: Accepts inputs from multiple sources — bank statements (MT940, CSV), TRACES Form 26AS downloads, GSTR-2B JSON, payment gateway settlement files — in their native formats. No manual reformatting.
2. Matching rules engine: Applies configurable matching logic — exact match on primary reference, tolerance match on amount, pattern match on known deduction types (TDS, MDR). Rules are configured per reconciliation type and per organisation.
3. Exception classifier: Items that do not match after all passes are classified by exception type — not simply flagged as “unmatched.” The classification determines which team member handles the exception and by what deadline.
4. Audit trail: Every match, every exception classification, and every manual override is logged with timestamp and user. The audit trail is queryable for any period — essential for statutory audit and GST officer inquiries.
Rules vs Patterns: How Engines Work
What a Matching Engine Handles
| Case | What it looks like |
|---|---|
| Exact match | Reference number, amount, and date all agree |
| Small amount difference | Rounding or bank charges within a configured tolerance band |
| Known deduction | Net receipt after TDS (net amount × 10/90 at 10 percent) |
| Partial reference | Truncated reference, same counterparty, close date |
| Exception | Anything left unmatched goes to an exception queue for human review |
A well-configured engine achieves 85–90% auto-match rates. The 10–15% exceptions are where human attention creates value — not in the matching itself.
Why Excel Breaks at Scale
The Structural Limitations
Excel breaks for reconciliation at scale for three reasons specific to Indian finance:
VLOOKUP collision on net-of-TDS amounts: When searching for ₹90,000 (a payment after 10% TDS), Excel will match any other entry of ₹90,000 — including unrelated transactions. A reconciliation engine matches on the combination of counterparty TAN + section code + quarter, not just amount.
No GSTR-2B native matching: Excel has no native connection to GSTN. Each month requires a manual download, a format conversion, and a formula-based comparison that breaks on any format change from GSTN.
No exception routing: Excel can flag a mismatch, but it cannot route it to the correct resolver — TDS mismatches need the accounts receivable team, ITC mismatches need the GST manager, bank exceptions need treasury. Routing in Excel is a manual process.
Why One Matching Rule Is Not Enough
Handling several match criteria matters because different transaction types match on different criteria. A NACH batch credit matches on the NACH presentation date and total amount — not on invoice number. A TDS receipt matches on the deductor TAN and section code — not on the NEFT narration. A platform settlement matches on the gateway settlement ID — not on the bank credit date.
A single-pass matching engine with a fixed criterion fails on all three. An engine configured per transaction type applies the right criterion to each.
Variance Taxonomy in Reconciliation Engines
Named variances are the difference between a reconciliation engine and a raw matching tool. When an item cannot be matched, the engine classifies it:
- FEE_DEDUCTION: Platform MDR or commission deducted from settlement — expected, no action needed
- TAX_DEDUCTION: TDS deducted — expected, generates TDS receivable entry
- TIMING_DIFFERENCE: Amount correct, date differs — carry forward to next period
- AMOUNT_MISMATCH: Genuine discrepancy — escalate for investigation
- ROUNDING: Sub-rupee difference — auto-resolve per tolerance rule
A named variance is resolved in one step. An unnamed “unmatched” exception requires the reviewer to diagnose it from scratch — which is what most spreadsheet-based processes produce.
Choosing an Engine vs a Compliance Tool
A compliance tool (like a GST filing portal) helps you file returns. It does not help you match your internal purchase register against GSTR-2B before filing. The reconciliation layer lives between your internal data and the compliance portal.
Reconciliation software India that includes a configurable matching engine handles both the India-specific reconciliation requirements (TDS, GSTR-1 / GSTR-3B, NACH) and the data integration layer — connecting directly to ERPs like SAP, Oracle, or Tally via API or file export.
For organisations where bank reconciliation is the primary complexity driver, bank reconciliation software handles the bank statement vs ledger matching with the same variance classification approach.
The Reserve Bank of India publishes guidelines on payment system data formats — relevant for organisations implementing MT940 or ISO 20022 integration with reconciliation engines.