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.