Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
What NACH Is and Why Reconciliation Is Non-Trivial
NACH (National Automated Clearing House) is the NPCI-managed system that replaced the legacy ECS (Electronic Clearing Service) for bulk debit and credit transactions. It is the infrastructure behind most EMI collections, insurance premium debits, mutual fund SIP mandates, and recurring subscription payments in India. When a NBFC, bank, or subscription business debits a customer's bank account for a recurring payment, the debit runs through NACH.
NACH reconciliation is not just about confirming that money arrived. It is about confirming that the right amount arrived for the right customer on the right due date — and for every mandate that did not succeed, understanding why, updating the borrower's account accordingly, and determining the correct next action. These are three operationally distinct activities that a reconciliation process must handle together.
At 500 mandates per batch, this is manageable manually. At 50,000 mandates per batch — which is common for mid-size NBFCs — it requires a structured, automated process. The difference is not just speed: manual reconciliation at this scale produces errors that accumulate across batches, eventually creating a misaligned loan ledger that is expensive and time-consuming to correct.
The NACH Data Structure: What the Return File Contains
A NACH debit transaction starts when the presenting bank submits a batch file to NPCI on the sponsor bank's behalf. NPCI routes each debit to the destination bank and receives an accept or return response. The return file — provided to the presenting bank and then to the originating organisation — contains the outcome for every mandate in the batch.
Each record in the NACH return file includes: the Unique Mandate Reference Number (UMRN), the account number and IFSC of the destination account, the transaction amount, the presentation date, the settlement date, the transaction status (Accepted / Returned), and where returned, the return reason code. The UMRN is the link between the NACH return file and your internal loan or subscription management system — it maps each mandate outcome to a specific borrower and EMI record.
Why UMRN matching is harder than it appears
UMRN matching is exact: a UMRN in the return file must match a UMRN in your system. The problem arises when UMRN management is inconsistent: old mandates reused after loan restructuring, UMRN not captured at the time of mandate registration, or multiple active mandates for the same borrower without a clear primary designation. These data quality issues surface during reconciliation as unmatched returns — entries in the return file with no corresponding system record — and must be resolved through manual investigation.
Common NACH Return Codes and Required Actions
| Code | Description | Category | Follow-Up Action |
|---|---|---|---|
| 01 | Funds Insufficient | Retriable | Retry within policy window; mark as 30 DPD if retry fails |
| 05 | No Account / Unable to Locate | Non-retriable | Trigger collections workflow; verify account details |
| 20 | Account Closed | Non-retriable | Update loan record; collect new mandate or bank account |
| 25 | Mandate Cancelled by Account Holder | Non-retriable | Escalate to relationship manager; stop future submissions |
| 27 | Stop Payment | Dispute | Treat as disputed EMI; contact borrower immediately |
| 09 | Technically Impaired | Retry | Resubmit mandate file; confirm format compliance with bank |
TransactIG maps NACH return codes to structured variance classifications with configurable retry and escalation logic. See NACH batch matching pattern →
Where NACH Reconciliation Breaks at Scale
Return file received after business day cut-off
NACH return files from NPCI are received within 24 to 48 hours of batch submission, but the exact timing varies. If the return file arrives after the lending system's end-of-day processing run, the mandate status updates for that day are delayed by 24 hours. For portfolios with a high bounce rate, this delay means that DPD (Days Past Due) calculations are incorrect for at least one day per batch cycle — which, multiplied across 50,000 mandates, produces material errors in portfolio NPA reporting.
Partial settlement in multi-instalment batches
Some NACH configurations allow partial debit — where the destination bank debits whatever funds are available, not the full mandate amount. This creates a partial settlement entry in the return file: status is "Accepted" but the settled amount is less than the presented amount. In a spreadsheet-based reconciliation process, partial settlements frequently fall through the cracks because the matching condition (status = Accepted) is met, but the amount mismatch is not checked. The result is a borrower whose EMI is recorded as paid in full when only a portion was collected.
Mandate amendments not reflected in batch
When a borrower changes their bank account or increases their EMI amount, a new or amended mandate must be registered before the next batch. If the amendment processing is delayed, the old mandate may be debited — potentially returning as "Account Closed" — while the new mandate is not yet active. Reconciliation must identify these cases and prevent both a double-debit attempt and a missed collection.
The NACH Reconciliation Process: From Return File to Ledger Update
Step 1 — Ingest return file and validate format
Receive the NACH return file from your presenting bank or NPCI portal. Validate the file format (NACH debit return files follow the NACH debit transaction format with the status field populated by the destination bank's response). Count the records and confirm they match the count in the submitted batch file. A count mismatch at this stage indicates a transmission error that must be resolved before reconciliation proceeds.
Step 2 — Match UMRN to loan system records
Match each return file record to the corresponding loan account or subscription record using the UMRN as the primary key. For accepted transactions, verify that the settled amount equals the expected EMI or instalment amount. For returned transactions, extract the return reason code and classify accordingly. Unmatched records — where the UMRN is not found in the system — are flagged for immediate investigation.
Step 3 — Update loan ledger and trigger workflows
For accepted transactions, post the collection to the loan account and update the next due date. For returns, update the account status based on the return code: codes 01 and 03 may be flagged for retry within the configured window, codes 20, 25, and 27 require escalation to relationship management or collections. For all returns, update the DPD counter from the due date, not from the return receipt date.
The NACH batch reconciliation pattern in TransactIG is pre-configured for Indian NACH debit return file formats, with UMRN-based matching, partial settlement detection, and configurable retry and escalation logic. See how NBFCs and lending organisations use this pattern to manage EMI collection reconciliation at scale.
For the broader context of how NACH sits within an enterprise reconciliation framework, see the reconciliation software guide covering all five major reconciliation types — bank, TDS, GSTR-2B, platform settlement, and NACH — in a single unified framework.
The NPCI NACH product overview provides the technical specifications for NACH debit and credit transactions, including the return reason code list and file format requirements.
NACH Debit vs NACH Credit Reconciliation
NACH supports two fundamentally different transaction types — debit and credit — and each requires a different reconciliation approach. Most NACH reconciliation guidance focuses exclusively on the debit side (collections), but organisations that use NACH credit for disbursements face a distinct set of reconciliation challenges.
NACH Debit (collections) is used for EMI collection by NBFCs and banks, insurance premium collection, mutual fund SIP debits, and recurring subscription billing. The reconciliation question is: for each mandate submitted, was the debit successful, and if not, what was the return reason code? The financial risk is on the collecting side — a missed collection means a delayed payment that must be tracked, retried, or escalated.
NACH Credit (disbursements) is used for salary payments, dividend distribution, government Direct Benefit Transfer (DBT) payments, vendor batch payments, and interest credit on fixed deposits. The reconciliation question is different: was the credit delivered to the correct account, and does the total disbursed match the total authorised? The financial risk is on the paying side — a credit to the wrong account or a duplicate credit creates an overpayment that is difficult to recover.
For NACH debit, the key matching field is UMRN mapped to the borrower's loan account. For NACH credit, the key matching field is the beneficiary account number mapped to the payroll record, dividend register, or vendor payment batch. Return handling also differs: a NACH debit return (code 01, insufficient funds) triggers a collection follow-up, while a NACH credit return (code 05, account not found) triggers a payroll or disbursement correction. Organisations using both NACH debit and credit must maintain separate reconciliation workflows, even though both flow through the same NPCI infrastructure.
NACH Return Charges and Financial Impact
Every failed NACH debit (return) incurs a return charge levied by the destination bank. These charges vary by bank and mandate type but typically range from ₹150 to ₹750 per failed transaction. While individually small, these charges compound rapidly at portfolio scale and represent a significant, often untracked, operational cost.
Consider a mid-size NBFC with 50,000 active mandates and an 8% bounce rate. At 4,000 returns per batch and an average return charge of ₹250, the monthly return charge burden is ₹10 lakh. Over a financial year, this amounts to ₹1.2 crore in return charges alone — before accounting for the cost of the missed collections themselves, the operational cost of follow-up, and the interest income lost on delayed EMI receipts.
The reconciliation implication is twofold. First, return charges must be extracted from the bank statement and matched to specific failed mandates — they appear as separate debit entries in the bank statement, not as part of the NACH return file. Without this matching, return charges are recorded as generic bank charges and the per-borrower cost of failed collection is understated. Second, tracking return charges by return code helps identify systemic issues: a high volume of code 01 returns (insufficient funds) concentrated on specific due dates may indicate that the batch submission timing is misaligned with salary credit dates — an operational adjustment that can reduce bounce rates by 2-4 percentage points.
For a detailed reference of all NACH return codes and their operational implications, see our article on NACH return codes in India.
ECS to NACH Migration Impact on Reconciliation
The migration from ECS (Electronic Clearing Service) to NACH brought significant improvements to batch processing infrastructure, but it also changed the reconciliation data model in ways that affect matching logic and reference field handling.
Settlement speed improved from T+3 to T+1. Under ECS, batch settlement took 3 business days, creating a wider timing difference window in bank reconciliation. NACH settles within T+1, which reduces timing-related mismatches but also compresses the window for reconciliation and exception resolution. Organisations that reconciled ECS batches weekly must now reconcile NACH batches daily to keep pace with the faster settlement cycle.
Standardised return codes replaced bank-specific rejection reasons. Under ECS, each bank used its own rejection description — a text string that varied in format and terminology. NACH introduced a standardised numeric return code system (01 through 68), making automated classification possible. However, organisations that migrated from ECS without updating their reconciliation logic may still be parsing legacy text-based rejection reasons instead of using the standardised codes — resulting in misclassified returns and incorrect retry decisions.
UMRN replaced inconsistent ECS reference numbers. ECS mandates used bank-specific reference numbers that were not portable across the NPCI network. NACH introduced the UMRN (Unique Mandate Reference Number) as a universal identifier that persists across the mandate lifecycle. For reconciliation, UMRN provides a reliable primary matching key that ECS never had. However, organisations that migrated existing mandates from ECS to NACH may have legacy records where the UMRN was not captured or mapped to the original ECS reference — creating a matching gap for historical mandates.
For a complete analysis of the migration timeline, data format changes, and reconciliation adjustments required, see our detailed guide on ECS to NACH migration reconciliation.