Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
A corporate paying ₹38 crore monthly payroll for 4,200 employees via NACH-Credit reconciles against the gross bank debit only. Failed credits are surfaced days later when employees raise tickets, statutory return-file exceptions go untracked, and vendor NACH-Credit failures push payments outside the Section 43B(h) MSME window.
Join the credit instruction file (per-beneficiary), the bank debit advice (gross), and the NACH return file (per-beneficiary failure with reason code) on the batch ID and the beneficiary key. The settled value equals gross debit minus return value. Each return-file row triggers a repost workflow via NEFT or RTGS with same-day SLA.
Batch ID and beneficiary master, NACH return-code library for credit-side returns, gross-debit minus return-value reconciliation rule, repost-via-NEFT workflow, exception MIS to payroll and accounts payable, and a 43B(h) and TDS-deposit timing rule.
Same-day visibility of failed credits, employee and vendor tickets prevented because the corporate acted first, statutory payment timing preserved, and a defensible audit trail showing every credit either landed or was reposted.
For a corporate, NACH-Credit is the largest single cash movement of the month. Payroll, employer PF and ESI contributions, and a chunk of vendor settlement leave the bank in one batch — typically on the last business day of the month or the first business day of the next, depending on policy. The bank statement shows one gross debit. The reconciliation, if it stops at that gross debit, is reconciliation in name only. The actual credits — 4,200 of them, in the worked example below — succeed and fail independently, and the failures matter.
What NACH-Credit Reconciliation Involves
NACH-Credit reconciliation is the daily-or-batch process of matching every per-beneficiary credit instruction the corporate submitted against the per-beneficiary settlement outcome the bank reports back, and clearing exceptions the same business day.
Three data sources drive the reconciliation. The credit instruction file is the corporate’s submission to the presenting bank — one row per beneficiary, with bank account, IFSC, amount, and beneficiary reference. The bank debit advice is the gross amount the bank pulls from the corporate’s account on the settlement date, referenced to the batch ID. The NACH return file lists the per-beneficiary credits that failed, with NPCI-standard return reason codes.
The reconciliation equation is simple: gross debit minus return value equals settled value, and settled value equals sum of credits that actually landed on beneficiary accounts. Any other arithmetic is an exception.
The NACH-Credit Lifecycle
Step 1: Batch Preparation
The payroll or accounts payable system generates the NACH-Credit batch file in the NPCI-specified ACH file format. Each detail record contains the beneficiary account number, IFSC code, amount, transaction reference, and beneficiary name. The header and trailer carry the batch totals — number of credits and gross amount — which must match the detail rows exactly.
Step 2: Submission and Cut-Off
The corporate submits the batch to its presenting bank, usually via an authenticated portal or H2H connection. The settlement date is determined by the cut-off the corporate hits — pre-cut-off batches typically settle T+0; post-cut-off batches settle T+1. Cut-off times vary by bank; most settle on the 11:00 AM working-day window.
Step 3: Settlement and Bank Debit
On the settlement date, the bank debits the corporate’s account for the gross batch value and submits the batch to NPCI for credit to beneficiary banks. The debit advice on the corporate’s statement references the batch ID.
Step 4: Return File Receipt
T+1 from settlement, the presenting bank forwards the NACH return file. Each row identifies a failed credit by transaction reference and reports the reason code. The corporate’s reconciliation engine joins this file against the original credit instructions to identify which beneficiary did not receive the credit.
Step 5: Repost and Exception MIS
Failed credits are reposted via NEFT or RTGS the same business day, after validating that the beneficiary master is current. An exception MIS goes to payroll for employee credits and to accounts payable for vendor credits.
NACH-Credit Return Code Reference
| Return Code | Reason | Common Cause | Corporate Response |
|---|---|---|---|
| 02 | Account Closed | Employee or vendor changed bank | Update master, repost via NEFT |
| 03 | No Such Account | Wrong account number in master | Validate with beneficiary, repost |
| 04 | Account Inoperative | Dormant account at beneficiary bank | Notify beneficiary, repost when active |
| 05 | Account Frozen | Legal or KYC freeze on beneficiary | Hold pending resolution |
| 06 | Account Type Mismatch | NRE or NRO mismatch on transfer | Validate account type, repost |
| 11 | Mandate Not Registered | Mandated credit without active mandate | Re-register mandate workflow |
| 12 | Amount Mismatch | Header total does not match detail | Reject entire batch, rebuild |
| 25 | Invalid Beneficiary Details | Name and account mismatch | Validate KYC, repost |
The code library is shared with NACH-Debit but the action map for credits is different — there is no DPD counter, no retry policy, only a repost workflow.
Worked Example: ₹38 Cr Monthly Payroll for 4,200 Employees
A mid-size services company runs a monthly payroll batch of 4,200 employees with a gross value of ₹38 crore. Average net pay is approximately ₹90,000 per employee. The batch is submitted to the presenting bank on the 31st (or the last business day of the month) by 10:00 AM and settles same day.
Typical return rate on a stable payroll book is 0.6 to 1.1 percent — call it 0.8 percent, or 34 failed credits per cycle. Of those, around 60 percent are code 02 or 03 (employee changed banks and HR did not update the bank master), 25 percent are code 04 (dormant account), and the balance are codes 05, 06, and 25.
Before structured reconciliation: the payroll team confirmed the gross debit landed and closed the cycle. Failed credits surfaced over the following three or four business days as employees raised tickets through the HR helpdesk. By the time HR had reposted via NEFT, 34 employees had been without their salary for two to five business days. On the vendor side, the same pattern produced 12 failed credits that did not get reposted before the 45th day from invoice receipt, triggering Section 43B(h) disallowance exposure of ₹6.2 lakh on the manufacturing arm of the business.
After structured reconciliation: the credit instruction file, the bank debit advice, and the return file land in the reconciliation engine the same day. The 34 failed employee credits are reposted via NEFT within four hours of return-file receipt — before any helpdesk ticket is raised. Employees see the credit by end of the settlement day. The 12 vendor failures are reposted the same evening, well inside the 43B(h) window. The MIS reports the return-code histogram month-over-month, which surfaces the underlying bank-master hygiene problem and drives an HR data clean-up.
The annual saving is not in the bank charges (those are negligible at this volume) — it is in the avoided 43B(h) disallowance, the avoided employee-experience cost, and the avoided manual correction effort. Sizing your own NACH-Credit exception cost is straightforward — run the three-way match exception cost calculator and substitute exception count and per-exception cost for your payroll and vendor batches.
NACH File Format Notes
The NACH ACH file is a fixed-width text format. Each batch has one header record, many detail records, and one trailer record. The header carries the file creation date, the corporate user number, and a unique batch reference. Each detail record is a fixed-length row with positional fields for transaction reference, beneficiary account number, IFSC, amount in paise, beneficiary name, and a few free-text fields for the corporate’s reference.
The trailer carries the count of detail records and the sum of amounts. If the trailer totals do not exactly match the detail rows, the batch is rejected at the bank’s edge with code 12 (amount mismatch) on the entire batch — not on individual records. Reconciliation engines should validate the file before submission to avoid a full-batch reject that would force a same-day rebuild.
Statutory Payment Timing Implications
For vendor payments, NACH-Credit failures interact with two statutory windows.
Section 43B(h) of the Income Tax Act requires that payments to MSME suppliers be made within 45 days of acceptance of the goods or services (15 days if no agreement). A failed NACH-Credit that is not reposted within the window pushes the payment date past the cut-off and disallows the expense in the year of accrual, taxing it instead in the year of payment. Same-day reposting via NEFT prevents the disallowance.
TDS deposit timing is also affected. The TDS on vendor payments must be deposited by the seventh of the next month (or by the 30th of April for March deductions). If the underlying payment is delayed because of an unreconciled NACH-Credit failure, the corporate still has to deposit TDS on the original payable date, even if the vendor has not yet been paid. Reconciliation engines should emit a vendor-payment-not-credited flag the same day so accounts payable does not lose visibility.
Common Pitfalls
Reconciling only against the gross debit: catches the batch landed but misses every per-beneficiary failure.
Manual repost from spreadsheets: every NACH-Credit failure that is reposted by hand without a system reference loses the audit trail tying the original credit to the eventual NEFT.
Stale beneficiary master: the same employee or vendor returns repeatedly because the bank-account update never lands in the master.
Ignoring the return-code histogram: the histogram tells you which root cause is dominant — bank changes (codes 02, 03), dormancy (code 04), data quality (codes 06, 25). Each root cause points to a different upstream fix.
Closing Note
NACH-Credit reconciliation is straightforward in design: gross debit minus returns equals settled, settled equals sum of beneficiary credits, every other state is an exception. The reason it goes wrong in practice is that corporates anchor their reconciliation on the gross bank debit instead of the per-beneficiary credit record. Moving the anchor to the credit record — and adding the return file as a primary data source — closes the loop the same day and protects every downstream statutory and contractual window the payroll and vendor batches touch.