ACH Return Codes: NACHA File Format and R01–R85 List

ACH return codes are the three-character reason codes — R01 to R85, 70 of them in force — that a receiving bank puts on an ACH entry it sends back, and they travel inside the same fixed-width NACHA file format that carried the payment out. The format is six record types in nested envelopes; the return is an entry detail record plus an addenda record carrying the code. Read the file and the code list together and a bounced US payment stops being a bank phone call.

Nacha publishes the rulebook and its return-code appendix as paid products, so this post works the way the pain.002 reject codes post does: Nacha's own public rule pages and its ACH Guide for Developers for structure and rule changes, cross-checked against the Federal Reserve's FedACH forms and bank-published code cards for the titles.

The file: six record types, 94 characters each

Every record is exactly 94 characters, and the file is blocked in tens: if the record count isn't a multiple of ten, the file is padded with lines of 9s. The first character of each line is the record type:

A file holds one or more batches (5 … 8), a batch holds one or more entries (6), and each entry may carry addenda (7). That nesting is the same idea as BAI2's 01–99 envelopes — header, content, trailer with checkable totals — just on the outbound side.

The fields that decide whether it posts

File header. The immediate destination is a space followed by the nine-digit routing number of the bank receiving the file; the file ID modifier (a capital letter or digit) tells apart two files created on the same day.

Batch header. The service class code declares the batch's direction: 200 mixed debits and credits, 220 credits only, 225 debits only. The company identification identifies you as the originator. The company entry description is the ten characters that often appear on the receiver's statement — and since 20 March 2026 two values are mandated: PAYROLL for PPD credits paying wages and similar compensation, and PURCHASE for consumer debits authorising online purchases, per Nacha's company entry description rule. The effective entry date is the date you want the entries to settle; the settlement date is left blank because the ACH Operator fills it in. The originating DFI identification is the first eight digits of your bank's routing number.

Entry detail. The receiving DFI identification is the first eight digits of the receiver's routing number, with the ninth — the check digit — in its own field. The account number field is 17 characters, the amount is in cents with no decimal point, and the addenda record indicator (0 or 1) says whether a 7 record follows. The trace number is 15 digits: your bank's eight-digit routing prefix plus a sequence number, ascending within the batch. Every return and every notification of change quotes it back, so it is the key your reconciliation should hold on to — the ACH equivalent of the pain.001 EndToEndId.

The transaction code is the first data field and decides debit versus credit and checking versus savings:

A prenote is a zero-dollar entry that tests the routing and account number before the first live payment. It proves the account exists and can take entries; it does not prove it belongs to the payee you think it does.

Controls. The batch and file control records repeat counts and totals, plus an entry hash: the sum of the eight-digit receiving DFI identifications of every entry, truncated to the rightmost ten digits. Entry and addenda records both count; headers and controls don't. The totals exist so that a truncated or altered file cannot balance — the same checkable arithmetic BAI2 trailers hand you on the way back.

SEC codes: what kind of payment the batch is

The Standard Entry Class code in the batch header tells every bank in the chain which rules apply — authorisation requirements, return windows, which addenda are allowed. The ones a corporate treasury originates or receives:

Others matter mostly because return codes refer to them: ARC, BOC and POP convert paper checks into ACH debits, RCK re-presents a returned check, XCK replaces a destroyed check, and ENR is the automated enrollment federal agencies use for direct deposit. On the SAP side, the payment medium workbench format ACH carries CCD, CTX and PPD as format supplements; how the format tree maps F110 data into those fields is in the DMEE post.

How a return comes back

A return is an ordinary entry detail record in a file from your bank, followed by a type 99 addenda record: the return reason code in positions 04–06, the original entry trace number in 07–21, a date of death for R14/R15, and the original receiving DFI identification.

The clocks matter as much as the codes. The receiving bank (RDFI) has two banking days after settlement for most returns. Unauthorized consumer returns — R05, R07, R10, R11 — get 60 calendar days. R29, the corporate version, stays on two banking days. If your bank (the ODFI) thinks a return is itself wrong, it can dishonor it within five banking days of the return's settlement, and the RDFI can contest that dishonor within two banking days; after that the dispute leaves the network.

A notification of change is different: a zero-dollar COR entry with a type 98 addenda, carrying a C code (C01 incorrect account number, C02 incorrect routing number, C05 incorrect transaction code) and the corrected value. The payment posted; your master data didn't match. The NOC tells you exactly which field to change on the vendor or customer record before the next run.

ACH return reason codes: the full list

Titles below are Nacha's, condensed where the official wording runs to a paragraph.

R01–R33: the returns an originator sees

R34–R39: limited participation and converted checks

R40–R47: automated enrollment (ENR) only

R50–R53: re-presented checks (RCK) only

R61–R77: dishonored and contested dishonored returns

R61–R70 are sent by the ODFI dishonoring a return; R71–R77 by the RDFI contesting that dishonor.

R80–R85: international (IAT) entries

The gaps are real. R48–R49, R54–R60, R63–R66 and R78–R79 are not assigned. Lists that still show R63–R66 ("incorrect dollar amount", "incorrect transaction code" and so on) are describing field errors that the current rules carry inside an R69 dishonored return, as field codes 01–07 in the addenda. A code table built from one of those lists will map codes your bank never sends. All 70 codes above are current: Nacha's recent changes repurposed codes rather than retiring them (next section). R30 and R33 belong to check-truncation and destroyed-check programmes a corporate originator will rarely touch.

The codes whose meaning moved

Three rule changes decide how you read a code, and a code table older than the first two will misroute returns today:

• R10 and R11, April 2020. Nacha split the unauthorized reasons: R10 now means no relationship or no authorization at all; R11 was repurposed to mean an authorization exists but the entry broke its terms — wrong amount, debited early, or part of an incomplete transaction. R11 counts as an unauthorized return for return-rate purposes, and since April 2021 it also carries the unauthorized entry fee.
• R06 and R17, 1 October 2024. An ODFI may now request a return for any reason (R06; the RDFI's compliance is optional). And an RDFI may use R17 to return an entry it believes was initiated under questionable circumstances — account takeover, business email compromise, payee impersonation — with QUESTIONABLE in the addenda information.
• R16 and R90, 17 March 2028. A new R90, "Entry Returned Due to RDFI's Sanctions Compliance Obligations", takes over sanctions returns, and R16 narrows to frozen accounts. Approved, not yet live — which is why it sits outside the list above.

"

An R17 with QUESTIONABLE in the addenda is not a data error to fix and resend. It is the receiving bank telling you the payment was probably induced by someone other than your real counterparty.

That matters for payment fraud controls: an R17 QUESTIONABLE on a vendor payment is the signature of an invoice-redirection fraud that already got past your beneficiary checks, and it belongs in the fraud queue, not the repair queue.

The return rates Nacha watches

Returns are also a scorecard. Nacha's risk and enforcement rules set an unauthorized return rate threshold of 0.5% (R05, R07, R10, R11, R29, R51), an administrative return rate level of 3.0% (R02, R03, R04) and an overall return rate level of 15.0% for debits. The threshold is a limit the originator has to get back under; a level is the point at which Nacha may open a preliminary inquiry into the origination practices behind it. If you collect by ACH, those three numbers belong on the same dashboard as your DSO.

Where returns meet your treasury system

You rarely read the raw return file. Returns reach treasury through the bank's reporting: a BAI2 detail record, or a camt.053/camt.054 entry — Nacha publishes an ISO 20022 guide to carrying the ACH return data in camt.053. From there the EBS posting rules have to recognise the line as a return, find the original by trace number, and reverse the clearing. What I would build: keep the R code as data on the reversal, and route by family — R02/R03/R04/C-codes to master-data repair, R01/R09 to cash and collections, R05/R07/R10/R11/R29 to the customer and mandate owner, R17 QUESTIONABLE to fraud. And key the table by code set: an ACH return and an ISO 20022 reject are different lists, exactly as pain.002 rejects and SEPA returns are.

Same Day ACH is about to carry bigger payments: its per-payment limit rises from $1 million to $10 million on 17 September 2027. A mishandled return on a single $10 million payment is a cash-positioning problem, not a back-office one.

See also the BAI2 file format walkthrough, bank statement formats: MT940 vs camt.053 vs BAI2, pain.002 status and reject codes, and payment fraud prevention in treasury.