Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
A common frustration among SAP FICO users is that while the system records every entry correctly, producing a reconciled view across bank statements, TDS receivables, and GST ITC requires manual steps outside the system — exports, downloads, spreadsheet joins, and manual exception review. This is not a deficiency in the ERP. It is a description of what ERPs are designed to do and what they are not.
Understanding where ERP capability ends and where reconciliation software begins is the prerequisite for building a finance operations stack that is both audit-ready and operationally sustainable at scale.
What ERP Systems Are Designed to Do
An ERP is a system of record. When a purchase order is raised, a goods receipt posted, and a vendor invoice matched, the ERP records the liability, the asset receipt, and the payment obligation — each as a timestamped ledger entry. When a bank payment is made, the ERP records the outflow. When a TDS deduction is made, the ERP records the TDS payable.
The ERP’s job is accurate bookkeeping: capturing the financial event as defined by the business’s own processes, applying the chart of accounts, and maintaining the integrity of the general ledger. It does this well. The world’s largest enterprises rely on SAP and Oracle for exactly this function.
What the ERP does not do is verify. It records what the business’s internal processes say happened. It does not independently confirm that the bank statement agrees, that Form 26AS reflects the TDS the deductor claims to have deposited, or that the payment gateway’s settlement matches the order value less the platform’s deductions. That verification step — matching the internal record against multiple external sources and explaining the differences — is the reconciliation function.
Where the Gap Appears: Why Indian Finance Teams Experience It Acutely
For Indian enterprises, the gap between ERP records and external verification is wider than in most other markets, for three specific reasons.
The TDS Deduction Chain
TDS is deducted at source by the payer, not the payee. When a client deducts TDS under Section 194J and remits the net amount, the ERP records the full invoice value and the TDS receivable. The bank receives the net credit. The TDS deposit confirmation appears only when the deductor files their quarterly return and the amount flows into the payee’s Form 26AS on TRACES.
This creates a three-way matching requirement: gross invoice in ERP, net bank credit, and TDS credit in Form 26AS. The ERP holds two of these data points internally. The third — Form 26AS — is an external data source on a government portal. ERP modules do not natively ingest Form 26AS and match it against open TDS receivables.
GSTR-2B Auto-Populated ITC
Input Tax Credit under GST is claimable only to the extent it appears in the buyer’s GSTR-2B — the auto-populated reconciliation statement generated by the GST portal from suppliers’ filed returns. The buyer’s ERP records ITC based on invoices received. GSTR-2B reflects ITC based on what suppliers actually filed.
The difference between what the ERP recorded and what GSTR-2B shows is the ITC mismatch. Under Rule 36(4) of the CGST Rules, excess ITC claimed in GSTR-3B relative to GSTR-2B can trigger demand notices under Section 73. The ERP has no native capability to ingest GSTN JSON, compare it to the purchase register, and classify the differences. Organisations on generic accounting platforms find that GSTR-2B matching requires a separate manual step — a download from the GST portal, a VLOOKUP against the purchase register, and manual exception flagging.
NACH Batch Returns
For NBFCs and lenders, NACH batch credits arrive as a single bank entry representing hundreds of individual mandate presentations. The ERP records the aggregate bank receipt. The actual reconciliation — matching each mandate outcome to the borrower’s loan account, updating the Days Past Due counter, and classifying bounce returns by NPCI return code — is a disaggregation exercise that the ERP’s bank reconciliation module is not designed to perform.
What ERP Does vs What Reconciliation Software Does
| Task | ERP | Reconciliation Software |
|---|---|---|
| Record ledger entry from invoice or voucher | Yes — primary function | No — reads ERP records, does not replace them |
| Ingest bank statement and match to open items | Basic statement import; limited matching logic | MT940, OFX, bank-specific CSV; multi-signal matching with UTR priority |
| Ingest Form 26AS and match to TDS receivable ledger | No native connector to TRACES | Ingests Form 26AS, maps to ERP TDS receivable, classifies variance by section |
| Ingest GSTR-2B and match to purchase register | No native GSTN JSON ingestion | Parses GSTN JSON, compares to purchase register, codes ITC mismatches |
| Disaggregate NACH batch credit to individual loan accounts | No — aggregate entry only | NPCI XML parsing; mandate-level matching; bounce code classification |
| Classify exceptions by variance type | Flags open items as unmatched | FEE_DEDUCTION, TAX_DEDUCTION, ROUNDING, PARTIAL_PAYMENT, PENALTY_OR_INTEREST, UNEXPLAINED |
| Write cleared entries back to ERP | Internal posting only | RFC or API writeback to SAP FI; import file for Tally; REST for Oracle |
How the Two Systems Work Together
The operational model is sequential. Each step in the workflow has a clear owner.
Step 1: ERP Records the Ledger Entry
When an invoice is posted, a payment is made, or a TDS liability is accrued, the ERP creates the ledger entry. This is the source of truth for what the business intended to happen. The ERP entry defines the amount, counterparty, date, and account classification.
Step 2: Reconciliation Software Ingests the External Feed
Bank statements arrive as MT940 or bank-specific CSV. GSTN data arrives as JSON from the GST portal. NACH returns arrive as NPCI XML. Form 26AS is downloaded from TRACES. Payment gateway settlements arrive in gateway-specific CSV formats. The reconciliation software’s ingestion layer normalises all of these into a common transaction schema — same field names, same date format, same amount representation — so they can be compared against ERP data.
Step 3: The Matching Engine Runs
The matching engine applies the four-pass pipeline: exact match first, then signal-weighted matching using UTR (weight 0.40), partial reference (0.25), counterparty name (0.15), date (0.10), payment mode (0.05), and amount (0.05), then tolerance matching for configured variance bands, then aggregation for one-to-many or many-to-one scenarios. Items confirmed at each pass exit the queue. On a 781-row test dataset, this architecture produced an 88% match rate, compared to 51% on single-field matching.
Step 4: Exceptions Are Routed for Review
Unmatched items are classified by variance code and routed to the appropriate reviewer. A TAX_DEDUCTION exception goes to the TDS team. A ROUNDING exception is available for bulk approval. An UNEXPLAINED exception with a high amount goes to the accounts manager with an escalation flag. Each exception carries a full data record — the ERP entry, the external feed entry, the signals evaluated, and the variance amount — so the reviewer has everything needed to resolve it without further investigation.
Step 5: Cleared Entries Are Written Back to the ERP
Once an exception is resolved — approved as a legitimate variance, corrected, or confirmed as matched — the cleared entry is written back to the ERP via the configured integration. For SAP, this posts a clearing document in FI. For Tally, the cleared journal is written as an import file. The ERP open item is closed, the reconciliation audit trail records the outcome, and the finance team’s control environment is complete.
Why India’s Compliance Stack Makes the Gap Wider
The three scenarios described above — TDS deduction chains, GSTR-2B ITC matching, and NACH batch disaggregation — do not exist in equivalent form in most other markets. This is why the gap between ERP capabilities and Indian enterprise reconciliation requirements is structurally larger than the gap that finance teams in the US or UK face.
Adding one more: GST TCS under Section 52. E-commerce operators are required to collect Tax Collected at Source at 1% on net value of taxable supplies. The TCS deduction appears in the marketplace settlement file — not in the ERP, because the business did not deduct it. The seller’s ERP records the gross order value; the bank receives the settlement net of TCS and MDR. Matching the settlement to the order requires parsing the marketplace settlement file, accounting for TCS, MDR, commission, and reversal adjustments, and producing a net reconciled figure.
None of these matching requirements are native ERP capabilities. All of them are standard functions of purpose-built reconciliation infrastructure.
For finance teams managing this compliance stack, the operational choice is not between ERP and reconciliation software. It is between reconciliation software and a manual process — spreadsheets, VLOOKUP formulas, and staff hours. The automated reconciliation platform India layer sits on top of the ERP and handles the external-source matching that the ERP cannot. TDS reconciliation software addresses the specific matching architecture for Form 26AS, quarterly return reconciliation, and the TDS net-of-gross exception type.
The Institute of Chartered Accountants of India publishes internal control standards that treat reconciliation as a required financial control — one that must be evidenced with documentation. A manual reconciliation process that produces no audit trail does not satisfy this requirement, regardless of how accurately the ERP’s ledger entries were recorded.
What Automated Reconciliation Changes
For a finance team that currently handles the ERP-to-external-source gap through manual processes, the operational change is measurable. The matching engine handles the volume matching, reducing the reconciliation run from several staff days per month to a matter of hours. Exception classification means the team works on exceptions that require human judgment — the UNEXPLAINED items — rather than spending time categorising every unmatched entry.
The compliance impact is direct: quarterly TDS reconciliation against Form 26AS, which typically takes 3 to 8 staff days for organisations with 50 or more active deductors, compresses to exception review only. GSTR-2B matching, which requires manual download, format conversion, and VLOOKUP, runs automatically each time the GSTN data is refreshed. The audit trail produced by the matching engine satisfies the evidence requirement for financial controls without additional documentation effort.
The ERP remains unchanged. The ledger entries it holds are still the source of truth. The reconciliation layer verifies them — and makes the verification process systematic rather than ad hoc.