Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
A reconciliation exception queue that grows by 100 items per month without resolution does not represent a matching problem — it represents a process failure. Matching identified the exceptions; the process failed to resolve them.
The distinction matters because the fix is different. Improving the match rate reduces new exceptions. Improving exception management reduces the backlog. Both are required.
What Counts as an Exception
In a reconciliation context, an exception is any item that the matching engine could not resolve automatically. There are four distinct types in an Indian finance context:
Unmatched ledger item: An invoice or entry in your books with no corresponding bank credit, TRACES entry, or GSTR-2B credit.
Unmatched external item: A bank credit, TRACES TDS entry, or GSTR-2B credit with no corresponding ledger entry.
Amount mismatch: Both items exist, but the amounts differ — most commonly because TDS was deducted and not accounted for, or MDR was deducted from a payment gateway settlement.
Reference mismatch: Both items exist with matching amounts, but the reference fields do not match — a common cause is NEFT narration that does not contain the invoice number.
Exception Classification: Minor vs Major
Before routing exceptions for review, they should be classified by type. Unclassified exceptions require the reviewer to diagnose from scratch — which takes 5–10 minutes per exception. Named exceptions route themselves and resolve in 1–2 minutes.
| Exception type | Classification code | Auto-resolution? | Resolver |
|---|---|---|---|
| TDS deducted (expected) | TAX_DEDUCTION | Generate TDS receivable | AR team |
| MDR deducted | FEE_DEDUCTION | Post to MDR expense | Finance ops |
| Payment timing difference | TIMING_DIFFERENCE | Carry to next period | System |
| Genuine amount mismatch | AMOUNT_MISMATCH | Escalate | Finance manager |
| Missing bank credit | MISSING_CREDIT | Follow up with bank | Treasury |
| Duplicate entry | DUPLICATE | Block and alert | Controller |
Routing and Escalation Logic
Routing determines which team member sees each exception and in what timeframe. Effective routing rules:
- By exception type: TDS exceptions to the AR team, bank exceptions to treasury, GST exceptions to the GST manager
- By amount: Exceptions above ₹1 lakh flagged to the controller within 24 hours; exceptions above ₹10 lakh flagged to the CFO
- By age: Exceptions unresolved after 3 business days escalated one level; unresolved after 7 days escalated to CFO
Resolution SLAs and Tracking
Each exception type should have a named resolution deadline. The key SLAs for Indian reconciliation:
- TDS deduction exceptions: 2 business days to generate TDS receivable
- GSTR-2B mismatch: 5 business days (before GSTR-3B filing on the 20th)
- Bank credit missing: 1 business day (contact bank with UTR)
- Amount mismatch above ₹10,000: 3 business days (investigate and resolve or escalate)
SLA tracking converts exception management from an informal process to a measurable one — the exception resolution rate and average resolution time become KPIs.
Root Cause Analysis for Recurring Exceptions
The 80/20 of Exception Root Causes
In most Indian finance teams, 3–5 root causes account for 70–80% of recurring exceptions:
- TDS deductors filing with wrong PAN: Creates Form 26AS mismatches every quarter. Fix: send correction request once; add deductor to quarterly watch list.
- Platform MDR rate not updated: Gateway changes MDR; books still use old rate. Fix: update the rate in the reconciliation system; reconcile retroactively.
- Supplier GSTR-1 filing delay: Creates monthly GSTR-2B mismatches. Fix: track late-filing suppliers; follow up after 14th if invoice not in GSTR-2B.
- NEFT narration without invoice reference: Bank credit cannot be auto-matched. Fix: require clients to include invoice number in payment narration; add counterparty reference lookup.
- NACH batch posting at aggregate level: Batch credit not disaggregated. Fix: configure disaggregation rule in reconciliation system.
Building an Exception Prevention System
Prevention works at two levels: upstream (preventing exceptions from entering the system) and in-system (auto-resolving known exceptions before routing to human review).
Upstream prevention:
- Require counterparty payment narrations to include invoice reference
- Validate GSTIN on all purchase invoices at receipt
- Maintain a deductor TAN register with correct section codes
In-system prevention:
- Auto-resolve TDS deductions that match the expected rate for the deductor (known pattern)
- Auto-resolve MDR deductions within contracted rate tolerance
- Suppress recurring timing-difference exceptions for known late-filing suppliers (carry forward automatically)
Reconciliation software India that classifies exceptions at generation — not at review — enables both upstream prevention (counterparty rules) and in-system prevention (auto-resolution of known patterns). The reviewer sees only genuine exceptions, not a queue contaminated with auto-resolvable items.
Bank reconciliation software with narration-parsing rules can match NEFT credits to invoices even when the narration format varies — reducing the most common category of bank reconciliation exceptions.
The Reserve Bank of India publishes guidelines on payment dispute and exception handling for regulated entities — relevant for payment aggregators and NBFCs managing NACH exception workflows.