US NACHA ACH Return & NOC File Parser
Read the return and Notification-of-Change files your bank sends back, reconcile rejected payments and keep partner bank data correct
What this module does
When you originate an ACH file, some entries come back. Your bank returns a NACHA return file carrying an Rnn reason code (insufficient funds, account closed, no account, unauthorized, stop payment, etc.) for every rejected entry, and a separate Notification of Change (NOC / COR) file carrying a Cnn code that asks you to correct stale routing, account, transaction-code or name data for future entries.
This module reads both file types - the fixed-width 94-character NACHA record format, blocked in groups of ten - and turns them into structured, searchable records you can reconcile against the payments you sent out. It then applies Notification-of-Change corrections back onto the matched partner bank account so the next file is right the first time.
Key features
Full NACHA return parser
Reads File Header (1), Company/Batch Header (5), Entry Detail (6), Addenda type 99 returns and type 98 Notifications of Change, Batch Control (8) and File Control (9). Accepts CRLF, LF or a single unbroken 94×N character blob - some banks deliver no line breaks.
Every published Rnn return code
The complete NACHA return reason code table (R01 through R85), each mapped to its official title and an action category: retryable (funding), account problem (do not retry), unauthorized / disputed, or administrative.
Notification of Change (Cnn)
Decodes the corrected-data payload of every change code (C01-C14): corrected routing number, account number, transaction code, individual / company name and identification - each unpacked from the addenda-98 layout defined by the NACHA Operating Rules.
Automatic write-back
Apply a Notification of Change directly to the matched partner bank account: the corrected account number, routing number (ABA validated before it is written) and account-holder name are updated, with the change logged on the partner's chatter.
Reconciliation to payments
Each returned entry is matched to a partner bank account on the receiving account number (refined by routing number), then to the originating outbound account.payment by partner and amount. Unmatched items are flagged for manual review.
Real ABA routing validation
Every routing number - on the bank record and inside the parsed file - is checked with the federal 3-7-1 modulus-10 checksum and the Federal Reserve routing-symbol range test, the same algorithm the ACH Operator uses.
Return reason categories
| Category | Example codes | Recommended action |
|---|---|---|
| Retryable (funding) | R01, R09 | Re-present after funds are available |
| Account problem | R02, R03, R04, R13, R16, R20, R28 | Do not retry - fix the account data |
| Unauthorized / disputed | R05, R07, R10, R11, R29, R51 | Stop re-origination without fresh authorization |
| Administrative | R06, R08, R24, R26, … | Review individually |
How it works
- Upload the NACHA return or NOC file your bank delivered (or load a built-in sample to see the parser at work).
- Parse it - the module extracts every returned entry and every notification of change into structured items.
- Reconcile - returns are matched to partner bank accounts and outbound payments; NOC corrections are applied to the partner bank record after ABA validation.
- Filter and act - group by category, kind or status; export and follow up on unauthorized or account-problem returns.
Privacy & scope
This module is a pure file parser and reconciler. It reads the NACHA files you already received from your own bank - it transmits nothing to any external service, contacts no gateway and stores no credentials. Your financial data never leaves your database.
Compatible with Odoo 18 and Odoo 19. Built on the Community accounting base - no Enterprise modules required.
Screenshots
Return Noc Files
Import Return File
All Items
Update date: 2026-07-02