Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
Every CFO evaluating reconciliation software for an Indian enterprise in 2025 faces the same structural problem: most global product rankings do not test for the compliance requirements that make Indian reconciliation categorically different from reconciliation in other markets. The best reconciliation software for an Indian business is the one built to handle TDS deduction chains, GSTR-2B ITC matching, NACH batch return classification, and Indian payment settlement netting — not the one with the highest overall rating on a global software directory.
This guide covers what the India compliance stack requires from reconciliation software, how purpose-built and generic platforms compare across seven evaluation dimensions, how the matching engine determines exception quality, and what to verify before committing to a deployment.
What Reconciliation Software Is
Reconciliation software is a platform that ingests financial records from two or more data sources, applies configurable matching rules, identifies confirmed matches, and produces a structured exception queue for items that do not match. The core function is not reporting — it is matching with explainability.
For Indian enterprises, the data sources involved in a complete reconciliation programme include bank statements (MT940, OFX, or bank CSV), ERP general ledger exports, payment gateway settlement files, GSTR-2B from the GST portal, Form 26AS and AIS from TRACES, NACH batch files from NPCI, and statutory payment challans. Each source has a different file format, a different data structure, and different matching logic requirements. A reconciliation platform must handle all of these through a shared ingestion and matching layer — not through separate tools with separate exception queues.
The distinction between reconciliation software and a reconciliation module within an ERP is meaningful. An ERP module is built around the ERP’s own transaction data. Reconciliation software is built around the problem of matching data from sources that the ERP does not control — bank statements, GSTN, TRACES, payment gateways. Finance teams using large ERP modules report that reconciliation exceptions involving external data sources — GSTR-2B mismatches, Form 26AS discrepancies, gateway settlement variances — still need manual resolution outside the system, because the ERP module cannot natively parse and match external format data at transaction level.
The evaluation question is not “does our ERP have a reconciliation module” — it is “does that module match GSTR-2B at invoice level and explain the variance when a mismatch exists.”
Why India Requires a Different Approach
India’s financial compliance stack generates more parallel reconciliation obligations per transaction than most other markets. A single vendor invoice from an IT services firm can simultaneously create a bank matching requirement, a TDS deduction chain to reconcile against Form 26AS, a GST ITC claim to reconcile against GSTR-2B, and — if paid by NACH — a mandate-level matching requirement against the NACH return file. Generic reconciliation tools built for markets without these parallel obligations cannot handle this natively.
TDS Deduction Chains
TDS under Sections 194C, 194J, 194H, 194I, 194A, and others requires a three-way match: invoice gross amount, TDS deducted at source, and net bank credit. The matching problem is not just amount-plus-date — it requires the TDS certificate number, the deductor PAN, the applicable section, and the deposit quarter to all align with TRACES/Form 26AS data.
The further complexity is timing: TDS deducted in March may be deposited in April, which shifts it into the following financial year for Form 26AS purposes. A reconciliation engine that matches by financial year without handling this quarter-boundary exception will systematically misfile TDS receivable and generate false unmatched exceptions.
Organisations on generic accounting platforms find that TDS net-of-gross receipt matching requires manual adjustment because the platform was not designed for the Indian deduction-at-source model. This is not a configuration gap — it is an architectural one.
GSTR-2B ITC Matching
GSTR-2B is a supplier-facing ITC statement with locking behaviour. ITC appearing in GSTR-2B for a given tax period is locked to that period. Rule 36(4) of the CGST Rules caps ITC claims to the eligible credit appearing in GSTR-2B, which means reconciliation software that compares purchase invoices to GSTR-2A (the non-locking predecessor document) will compute a different ITC eligible amount than what the GST portal enforces. Any Indian enterprise software that does not distinguish between GSTR-2A and GSTR-2B is not compliant with current ITC claiming rules.
The reconciliation requirement here is not just comparison — it is period-accurate, GSTIN-level matching with the ability to carry forward unmatched ITC into the next period and track cumulative mismatches per supplier GSTIN.
NACH Batch Return Classification
NACH (National Automated Clearing House) batch reconciliation requires disaggregating a single bulk bank credit into individual mandate outcomes. A NACH batch of 2,000 mandates arrives as one credit in the bank statement but must be reconciled at mandate level — with NPCI return codes (R01 through R12) classifying each return reason. An R01 return (insufficient funds) has a different resolution path from an R06 return (account frozen) or a mandate that simply was not presented.
Generic reconciliation tools that match NACH as a single bank entry miss the mandate-level reconciliation entirely. For NBFCs and lenders processing NACH at scale, mandate-level classification is the difference between a DPD counter that updates accurately and one that generates systematic errors.
UPI, POS, and Payment Gateway Settlement Netting
Payment gateway and UPI settlement files net multiple deductions before crediting the merchant: MDR fees, GST on MDR, TCS under Section 52 of the CGST Act (for marketplace operators), and refund adjustments. The bank credit is the net figure. Reconciliation must first unpack the settlement file to reconstruct the gross transaction amount and each deduction category before the bank matching can begin.
Software that matches only on the net bank credit amount will produce false positives — apparent matches where the components do not reconcile — and cannot explain settlement variances at the deduction level.
What This Evaluation Covers
Bank and Ledger Matching
The foundational reconciliation layer: bank statement entries matched against ERP cash or bank ledger entries. The matching uses UTR (Unique Transaction Reference) as the primary signal for RTGS, NEFT, and IMPS transfers, since UTR is assigned by the banking network and appears in both the bank statement narration and the ERP payment reference when populated correctly. For reconciliation software India to achieve high automated match rates on bank transactions, UTR-first matching is not optional — it is the difference between 88% automated match and 51%.
Where UTR is absent or truncated (common in older narration formats), the matching engine falls back to payment reference number, counterparty name, and amount within a tolerance band. The tolerance band must be configurable per transaction type: ₹5,000 or 5% for high-signal UTR matches is appropriate; 1% or ₹500 for partial-signal matches prevents false positives.
TDS and Form 26AS Reconciliation
TDS receivable tracking requires matching the TDS deducted by each counterparty against the corresponding Form 26AS entries from TRACES. The matching must identify: amounts correctly reflected in Form 26AS, amounts deducted but not yet deposited by the deductor, amounts reflected in the wrong section or quarter, and PAN mismatches between the vendor master and the TRACES record.
For TDS reconciliation software to handle all TDS sections accurately, the ingestion layer must parse Form 26AS Part A (TDS on salary), Part A1 (TDS other than salary), and the AIS (Annual Information Statement) that replaced certain Form 26AS fields from FY 2021-22 onwards. Section-level mapping — 194C vs 194J vs 194H — determines which ledger account the TDS credit posts to, so section mismatches create downstream GL errors, not just reconciliation exceptions.
GSTR-2B ITC Matching
GSTR-2B reconciliation matches the purchase invoice register against the ITC reflected in GSTR-2B for the same tax period. Matching dimensions are: supplier GSTIN, invoice number, invoice date, taxable value, IGST/CGST/SGST amounts, and HSN code (for reconciliation purposes). Common variance types include: invoices in the purchase register not appearing in GSTR-2B (supplier has not filed GSTR-1), invoices in GSTR-2B not matched to a purchase register entry (supplier has filed but the invoice reference was not captured in the ERP), and rate mismatches (supplier charged 18% GST but the purchase register reflects 12%).
The ITC carry-forward treatment — eligible ITC not claimed in the current period because the invoice appeared in a later GSTR-2B — requires period-level tracking that generic tools do not maintain.
NACH Mandate-Level Reconciliation
NACH reconciliation disaggregates the batch-level bank credit into individual mandate outcomes using the NPCI return file. For each mandate, the reconciliation engine must confirm: the mandate was presented, the bank debit occurred, the bank credit arrived in the collection account, and the outcome (success or return with code) was recorded against the borrower’s loan account.
Return codes R01 through R12 have specific resolution workflows. R01 (insufficient funds) typically triggers a retry mandate. R05 (payment stopped by account holder) triggers a collections escalation. Reconciliation software that classifies returns only as “returned” without code-level breakdown creates manual triage work downstream.
Platform Settlement and Gateway Reconciliation
Settlement reconciliation for payment gateways — Razorpay, PayU, Cashfree, Amazon Pay, Flipkart Seller, Meesho — requires parsing the settlement file to reconstruct gross transaction amounts, MDR, GST on MDR, TCS, refunds, and chargebacks before matching the net credit to the bank statement. The reconciliation engine must handle settlement files in gateway-specific CSV formats, with different column structures, deduction categories, and settlement cycle timings per gateway.
For marketplace sellers with multiple gateway relationships, a single reconciliation run covers multiple settlement files against multiple bank credits. The exception queue must be segmented by gateway, not presented as one merged exception list.
Comparison: Spreadsheet, ERP Module, and Purpose-Built Platform
| Evaluation Dimension | Spreadsheet / VLOOKUP | ERP Reconciliation Module | Purpose-Built Platform |
|---|---|---|---|
| TDS net-of-gross matching | Manual formula per payment | Partial — matches ERP entries only, not Form 26AS at transaction level | Native — three-way match with section, PAN, and quarter validation |
| GSTR-2B ITC matching | Manual download and compare | Limited — compares ERP data to GSTR-2A in most modules; GSTR-2B support varies | Native GSTR-2B period-locked matching with carry-forward tracking |
| NACH mandate-level reconciliation | Not feasible above 500 mandates | Not supported — NACH is not an ERP transaction type | Native — NPCI file parser with R-code classification per mandate |
| UPI / gateway settlement unpacking | Manual formula per gateway | Not supported — settlement files are not ERP source documents | Pre-built parsers for 10+ gateways; MDR, TCS, and refund separation |
| Automated match rate | 51% average on mixed datasets | 60–70% on ERP-internal data; drops for external sources | 88% on test dataset of 781 rows across mixed transaction types |
| Exception explanation | ”No match” — no variance code | Partial — highlights difference amount but does not classify cause | Variance codes: FEE_DEDUCTION, TAX_DEDUCTION, ROUNDING, PARTIAL_PAYMENT, PENALTY_OR_INTEREST, UNEXPLAINED |
| India data residency | User-dependent (file storage) | Depends on ERP deployment | AWS Mumbai (ap-south-1) — India-resident infrastructure |
| Audit trail | None inherent | ERP-level log, not reconciliation-level | Immutable timestamped log at each matching step and exception override |
How the Matching Engine Works
The matching engine in a purpose-built Indian reconciliation platform operates as a 4-pass pipeline. Each pass handles a different category of matching complexity, and transactions confirmed in an earlier pass do not proceed to later passes — which means the system’s capacity is preserved for harder matching problems.
Pass 1: Exact match. Transactions where all primary identifiers align — UTR, reference number, amount, and date — are confirmed in the first pass without any tolerance expansion. These are the “easy” cases: a clean RTGS credit with the payment reference captured correctly in both the bank statement and the ERP. Pass 1 handles the majority of high-volume, low-complexity transactions and resolves them without consuming matching resources.
Pass 2: Signal-weighted composite match. For transactions where an exact match is not available — truncated bank narrations, partial reference numbers, counterparty name variations — the engine computes a composite confidence score from multiple signals. The signal weights reflect the reliability of each identifier in the Indian banking context:
- UTR or exact reference match: 0.40
- Partial reference number match: 0.25
- Counterparty name match: 0.15
- Transaction date within ±1 day: 0.10
- Payment mode (NEFT, RTGS, UPI, NACH): 0.05
- Amount match (before tolerance): 0.05
A transaction scoring above 0.55 is treated as a high-confidence composite match and moved to the confirmed queue.
Pass 3: Tolerance-expanded match. Transactions where the composite score does not reach the 0.55 threshold are re-evaluated with amount tolerance expansion applied:
- Score ≥0.55: tolerance of 5% or ₹5,000 (whichever is lower)
- Score ≥0.40: tolerance of 2% or ₹2,000
- Score ≥0.25: tolerance of 1% or ₹500
These tolerance tiers handle the most common Indian variance sources: MDR deductions on gateway payments, TDS deductions where the net credit differs from the invoice amount, and rounding differences from rupee-paisa computation. Tolerance expansion is not applied uniformly — it scales with the confidence score so that a low-confidence match requires a smaller variance to be accepted.
Pass 4: Many-to-many aggregation. The final pass handles scenarios where one bank entry corresponds to multiple transactions (a consolidated NEFT covering three invoices) or multiple bank entries correspond to one ERP transaction (a split payment). Aggregation matching compares sum combinations within a date and counterparty window against candidate matches. This pass resolves bulk payment scenarios that would otherwise appear as exceptions.
On a test dataset of 781 rows representing a mixed Indian enterprise transaction set, this pipeline improved the automated match rate from a 51% baseline (single-field matching) to 88%. The remaining 12% form the exception queue, pre-classified by variance code so resolution can be delegated by code type rather than requiring case-by-case investigation.
Industry Coverage
| Industry | Primary Reconciliation Drivers | India-Specific Complexity |
|---|---|---|
| IT Services / SaaS | TDS 194J receivable, forex invoices, multi-client bank matching | Section 195 for non-resident payments; Form 15CA/15CB for forex remittances |
| NBFC / Lending | NACH mandate disaggregation, loan repayment matching, advance tax | NACH R-code classification; RBI IRACP norms for DPD accuracy |
| Healthcare | TPA settlement unpacking, CGHS/ESIS reimbursement, pharmacy GST | Multi-payer split matching; TDS 194J on doctor professional fees |
| E-commerce / Marketplace | Platform settlement netting, TCS 52 reconciliation, return adjustments | Gateway-specific settlement formats; GSTR-2B TCS credit matching |
| Real Estate / Developers | Buyer payment tracking, TDS 194IA, RERA compliance milestones | Form 26QB matching; stage-linked payment schedule reconciliation |
| Manufacturing / Trading | Vendor TDS across multiple sections, GSTR-2B ITC for input materials | Composite supply GST; HSN-level ITC tracking |
| Staffing / HR Services | TDS 194C contractor payments, payroll bank matching, PF/ESI reconciliation | High-volume small-amount 194C; bulk payroll NEFT disaggregation |
| Professional Services | TDS 194J receivable from multiple deductors, GST on services | Quarterly TDS reconciliation across 50+ client deductors |
Evaluation Guide: What to Look For
Evaluating reconciliation software for an Indian enterprise involves more than feature comparison. The questions below distinguish platforms built for India from platforms adapted for India.
Ask for a live TDS demo with your data format. Request a demonstration using a sample of your actual Form 26AS and TDS receivable ledger export. A platform that requires significant configuration to handle your TDS sections before it can run is not pre-configured for India — it is a generic tool being adapted. Purpose-built platforms with India presets should handle 194C, 194J, 194H, 194I, and 194A sections without per-section development.
Verify GSTR-2B, not GSTR-2A. Ask specifically whether the platform matches against GSTR-2B or GSTR-2A. GSTR-2A is real-time but does not lock, which means it is not the basis for ITC claims under current rules. A platform that cannot distinguish GSTR-2B period-locking from GSTR-2A will not calculate your eligible ITC correctly.
Request the exception classification taxonomy. Ask what happens to unmatched items. A platform that returns “unmatched — 43 items” is not solving your problem. A platform that returns “FEE_DEDUCTION: 12 items, TAX_DEDUCTION: 8 items, ROUNDING: 6 items, PARTIAL_PAYMENT: 11 items, UNEXPLAINED: 6 items” has pre-sorted the resolution queue. Each variance code has a different resolution owner and resolution SLA.
Check the audit trail at transaction level. Ask whether the audit trail records who matched each exception, with what override reason, and at what timestamp. For audit and tax assessment purposes, the ability to trace every reconciliation decision to a named user and a stated reason is as important as the match rate itself.
Confirm the deployment timeline. A 2-to-4-week deployment timeline is achievable for a purpose-built platform with India presets. If the vendor’s timeline is 3 months, ask what development work is included — and why that development is required for standard Indian reconciliation types.
Evaluate the match rate contract. Ask whether the vendor will contractually commit to a match rate target. A target of 70–85% is realistic for a mixed Indian enterprise transaction set. Vendors who decline to commit to a match rate are not confident in their matching engine’s performance on Indian data.
Security and Deployment
Infrastructure security for reconciliation software handling Indian enterprise financial data is governed by two considerations: data residency requirements and certification standards.
On data residency: financial transaction data processed by the reconciliation engine — bank statements, GSTR-2B extracts, Form 26AS data, NACH files — is classified as sensitive financial data under RBI guidelines and the DPDP Act 2023. Storage and processing within India-resident infrastructure is not advisory for regulated entities — it is a compliance obligation. The platform should be deployed on AWS Mumbai (ap-south-1) or equivalent India-based cloud infrastructure.
On certification: ISO 27001:2022 certification covers the information security management system governing how the platform handles, stores, and transmits financial data. The 2022 revision of the standard includes updated requirements for cloud environments and data classification that the older 2013 version did not cover. An ISO 27001:2022-certified deployment provides a documented, independently audited security framework — relevant to internal audit and board-level risk assessment.
Deployment timeline for a purpose-built India reconciliation platform is 2 to 4 weeks: one week for data source mapping and connector configuration, one week for integration testing with production-format data, one week for parallel running (new platform alongside existing process), and one week for production cutover and sign-off. No custom development is required when the transaction types are covered by the platform’s existing India presets. The 24+ industry presets available in the platform cover the full range of Indian enterprise reconciliation scenarios — from NBFC NACH batch to real estate developer TDS 194IA — through configuration parameters rather than code changes.
The demo engagement follows a structured process: a discovery meeting to map your specific reconciliation types, a use case scoping session to identify the data sources and exception categories involved, and a configuration review before go-live. The match rate target is agreed before deployment, not after.
The Institute of Chartered Accountants of India publishes standards and guidance notes that set the audit expectations for reconciliation documentation, including the level of traceability required for TDS receivable reconciliation and ITC claiming in annual accounts. The audit trail generated by a purpose-built reconciliation platform is designed to satisfy these requirements at every line item.