Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
NACH and eNACH collections arrive as one bank credit per batch, so lenders and subscription businesses cannot see which mandates paid, which were returned and which were re-presented.
Evaluate any NACH tool on whether it follows each debit from presentation file to bank credit to return file and reports per mandate, using a real day with returns and re-presentations.
Inputs: presentation files, return files, bank batch credits and the loan or billing schedule. Outputs: per-mandate status, return reason group, retry history, charge treatment and collection MIS.
A per-mandate collection report that ties to the bank credit and flags any unexplained residual in the batch.
A NACH reconciliation tool must follow each debit from the presentation file, to the bank’s batch credit, to the return file, and then report per mandate, not per batch. To test one, pick a real collection day that includes returns, re-presented debits and a single bank credit covering many customers, and ask every vendor to process it.
This guide is vendor-neutral. For the daily process, see NACH EMI reconciliation for NBFCs and NACH reconciliation for lenders.
What should the tool read and produce?
NACH is operated by NPCI, and eNACH mandates are registered electronically through net banking or debit card authentication. A typical collection cycle generates four inputs:
- the presentation file your sponsor bank submits for the due date;
- the bank credit, usually one amount for all successful debits in the batch;
- the return file, listing each failed debit and its reason;
- your loan or billing schedule, showing what was due from whom.
From these, the tool should produce a status for each mandate (collected, returned, re-presented or pending), the return reason, the retry history and a collection MIS by product, branch or due date. Ask the vendor exactly how a batch total is joined back to individual mandates, and what happens when the return file arrives a day after the credit.
How should returns be classified?
Return reasons should be grouped by who caused them, because each group needs a different next step:
- Customer cause: for example insufficient balance or payment stopped by the customer. Next action: retry on a permitted date, borrower contact, bounce charge as per your loan agreement.
- Bank cause: for example account frozen, technical rejection or a mismatch at the destination bank. Next action: check with the sponsor bank; usually no charge to the customer.
- Our cause: for example wrong amount, expired or cancelled mandate, or a duplicate presentation. Next action: fix the file or mandate; no charge to the customer.
For lenders, the charge treatment must follow the RBI circular on penal charges in loan accounts dated 18 August 2023, applied from 1 January 2024, which replaced penal interest with penal charges that cannot be capitalised. For customer-cause returns caused by insufficient funds, Section 25 of the Payment and Settlement Systems Act, 2007 treats dishonour of an electronic funds transfer mandate much like a bounced cheque, so the return date and reason must be kept as evidence.
Ask the vendor to show the current NPCI return reason list the tool uses and how it is updated. Do not rely on a reason list copied from an old document; the NACH return reasons guide explains the categories in words.
What scenarios should the decision table cover?
| Scenario | Expected output | Red flag |
|---|---|---|
| Partial batch credit | Credit split by mandate; returns listed separately | Batch shown as reconciled because the total ties |
| Bounced debit re-presented | Re-presentation linked to original return with retry count | Treated as a new, unrelated debit |
| Closed or cancelled mandate | Mandate flagged for re-registration; no further presentation | Same mandate presented again next cycle |
| Duplicate presentation | Second debit flagged for refund or adjustment | Customer charged twice without an alert |
| Return file arrives late | Mandates held as pending until the file is read | Credit split assuming all succeeded |
| Unexplained residual | Difference flagged for review | Residual absorbed into a suspense ledger |
What does a worked batch look like?
In an illustrative batch, 640 debits of ₹4,500 each are presented, so ₹28,80,000 is due. The return file lists 37 returns, worth ₹1,66,500. The expected credit is therefore ₹28,80,000 minus ₹1,66,500, or ₹27,13,500 for 603 successful debits. The bank credits ₹27,09,000. The tool should show 603 mandates as collected, 37 as returned with grouped reasons, and a residual of ₹4,500 flagged for review. That residual equals exactly one EMI, so the likely cause is one return missing from the file or one debit reversed later. A tool that marks the batch as reconciled at ₹27,09,000 has hidden the problem.
What should you ask about scale and controls?
Ask how many batches and sponsor banks the tool handles in one day, whether the loan management system is updated automatically or by file, how bounce charges and their 18 percent GST are posted, and whether every manual change to a mandate status is logged with user and time.
How Terra Insight fits
NACH reconciliation is on the TransactIG roadmap and is not available to buy today. TransactIG currently delivers TDS reconciliation and bank-to-books reconciliation with an exception queue and audit-ready exports. Use this guide to evaluate any NACH tool, and see the NACH batch reconciliation page for background.