Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
The difference between reconciliation software and reconciliation infrastructure is not just a matter of scope — it is a matter of architectural intent.
Software is built to solve a specific problem. Infrastructure is built to be the platform on which problems get solved. For Indian finance teams managing TDS, GST, bank, NACH, and platform settlement reconciliation simultaneously, the distinction determines whether you are buying three tools or one.
Software as a Point Solution
A reconciliation point solution solves one matching problem well. Examples:
- A bank reconciliation tool that imports bank statements and matches against the cash ledger
- A TDS matching module that compares the TDS receivable ledger to Form 26AS downloads
- A GSTR-2B comparison tool that flags ITC differences between the purchase register and GSTR-2B
Each of these solves a real problem. The limitation appears when the business needs all three — and then adds a fourth (platform settlement reconciliation) and a fifth (NACH batch disaggregation). Five point solutions mean five exception queues, five audit trails, five monthly processes, and five integration maintenance efforts.
Infrastructure as a Configurable Layer
Reconciliation infrastructure handles all matching types through a shared engine with configurable rules. The architecture looks like this:
| Layer | What it handles | Configured by |
|---|---|---|
| Data ingestion | Bank MT940, GSTN JSON, ERP exports, gateway CSV | Pre-built connectors + file parser |
| Matching engine | Multi-pass matching with tolerance bands | Rules configured per reconciliation type |
| Exception classifier | Named variance codes per exception type | Industry preset + custom rules |
| Workflow | Exception routing, escalation, sign-off | Role and SLA configuration |
| Audit trail | Immutable log of all matching and override events | System-generated |
The finance team interacts with one exception queue — not five separate tools. An unmatched NACH item and an unmatched TDS receipt appear in the same interface, routed to different reviewers based on exception type.
The API-First Approach
Why File-Based Integration Has Limits
Monthly file-based integration (download Form 26AS, upload to reconciliation tool, export exceptions to spreadsheet) introduces a structural delay: reconciliation is always at least one week behind the transaction date.
For organisations processing transactions continuously — e-commerce, payment aggregators, NBFCs — this delay means exceptions accumulate between monthly runs. An API-first architecture connects to data sources programmatically and enables daily or intraday matching.
API-first matters most for:
- NBFCs: NACH batch credits received daily need same-day disaggregation against loan accounts
- E-commerce: Settlement credits from Razorpay and PayU need daily matching against order data
- Healthcare: TPA settlement files received weekly need immediate matching against patient claim registers
- Real estate: Developer with 500 units needs buyer payment matching within 24 hours of receipt
Why Industry Presets Matter
An industry preset is a pre-configured set of matching rules for a specific sector. It encodes the structural characteristics of that sector’s reconciliation challenge:
A healthcare preset knows that one TPA settlement credit = many patient claim amounts, and applies split-matching logic automatically.
A real estate preset knows that buyer TDS under Section 194IA must be matched to the property consideration amount, the buyer PAN, and the Form 26QB reference.
An NBFC preset knows that a NACH batch carries a presentation date and a mandate batch ID, and applies bounce code classification when items return.
Without presets, configuring these rules requires development work. With presets, configuration is a parameter exercise — typically completed in the first week of deployment.
Future-Proofing with Infrastructure
The Indian regulatory and payment landscape changes regularly: new GST rules, new RBI payment system guidelines, new e-invoice requirements, new TDS sections. A point solution requires a new version release — or a new tool — when the rules change. Infrastructure requires a rule update.
Reconciliation software India built as infrastructure, not as a collection of point solutions, absorbs regulatory change through configuration updates rather than product updates.
Bank reconciliation software that is part of a broader infrastructure platform — sharing the same matching engine, exception queue, and audit trail — prevents the tool proliferation that makes reconciliation harder to manage as the business scales.
The Reserve Bank of India publishes payment system guidelines that directly affect reconciliation infrastructure requirements — particularly for payment aggregators, NBFCs, and entities holding nodal accounts.