Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
Bank reconciliation, in a market without tax-at-source deductions, is a straightforward matching problem: cash book entry vs bank statement line. The number of transactions is the only scaling challenge.
In India, reconciliation is structurally different — not just more work, but a different class of problem. Here is the architecture of that difference.
The Three-Layer Problem Unique to India
Indian finance teams operate three reconciliation processes simultaneously, each with different data sources and different regulatory deadlines:
Layer 1 — Bank reconciliation: Cash book vs bank statement. The base layer — present in every market. In India, complicated by the fact that NEFT and RTGS credits may carry narrations that do not directly map to invoice references.
Layer 2 — TDS reconciliation: TDS receivable ledger vs Form 26AS on TRACES. This layer is unique to India’s tax-at-source framework. Every payment received from a deductor carries a deduction that must appear in a government portal within 3–7 days. If it doesn’t, the credit is effectively lost until the deductor files a correction.
Layer 3 — GST reconciliation: Purchase register + ITC claimed in GSTR-3B vs ITC available in GSTR-2B. Mandated by GSTN rules since January 2022, this layer requires continuous matching against a portal that updates once per month.
| Layer | Data source | Update frequency | Regulatory risk |
|---|---|---|---|
| Bank | Bank MT940 / portal statement | Daily | Audit, cash position error |
| TDS | TRACES Form 26AS | 3–7 day lag per challan | Lost credit, demand notice |
| GST | GSTN GSTR-2B portal | Monthly (14th of month) | ITC reversal + 18% interest |
| Platform | Settlement files per gateway | T+1 to T+3 per gateway | Revenue misstatement |
How TDS Changes Every Transaction
The Net-of-TDS Receipt Problem
Every professional services invoice, contractor payment, rent receipt, or commission received by an Indian business arrives net of TDS. The bank credit is not the invoice amount — it is the invoice amount minus the applicable TDS rate.
Section 194J (professional services): 10% deduction. Invoice ₹1,00,000 → bank credit ₹90,000 + TDS receivable ₹10,000. Section 194C (contractors): 1% or 2% deduction depending on deductor type. Section 194H (commission): 5% deduction.
A matching engine that does not understand TDS as a structural deduction — not an exception — will fail on every such invoice.
Platform Aggregation Adds a Third Dimension
A Razorpay or Cashfree settlement is not one transaction. It is a batch of hundreds or thousands of individual orders, net of MDR (Merchant Discount Rate), GST on MDR, TCS at 1% on gross sales, and any refund adjustments. The bank credit is a single line; the underlying transactions are in a settlement CSV.
This creates a third matching challenge: before comparing the bank credit to revenue, the settlement must first be unpacked from a batch amount to individual transaction amounts.
GST Introduces Timing Mismatches
The GSTR-2B Lag
A supplier invoices on February 28. They file their GSTR-1 for February on March 11. The buyer’s GSTR-2B for February is generated on March 14 — and the invoice appears there. The buyer filed their GSTR-3B for February on February 20 and did not yet have the invoice in GSTR-2B.
Result: ITC claimed in February GSTR-3B does not match GSTR-2B for February. The buyer must either reverse the claim or carry it forward to March.
This timing mismatch is structural — it exists for every invoice filed by a supplier in the last 10 days of any month. At scale, it affects hundreds of invoices per month.
How Indian Enterprises Cope Today
Most Indian finance teams cope through one of three approaches, each with limitations:
- Spreadsheets with monthly downloads: Manageable below 500 transactions/month. Breaks at scale.
- ERP reconciliation modules: Handles bank and AR/AP well, but typically has no GSTR-2B matching or TDS section-level reconciliation.
- Manual exception handling by CA: Expensive and slow for anything requiring systematic matching across data sources.
Infrastructure vs Tool: The Right Mental Model
The distinction between reconciliation software and reconciliation infrastructure matters here. A software tool handles one reconciliation type — bank, or TDS, or GST. Infrastructure handles all three through a shared engine, with India-specific rules (TDS sections, GSTR-2B matching, platform settlement unpacking) configured by preset rather than built custom.
For an organisation managing all three layers, reconciliation software India designed for the Indian context reduces the problem from three separate matching processes to one unified exception queue.
Organisations with significant bank reconciliation complexity — multiple accounts, NACH batches, virtual account credits — benefit from dedicated bank reconciliation software configured for India’s payment rails.
The GST portal publishes the GSTR-2B matching rules and ITC claim deadlines that govern Layer 3 of the reconciliation process.