ACH return codes: the complete R01-R85 reference, checked against the official sources

What is an ACH return code?

An ACH return code is a three-character code that the receiving bank (RDFI) writes into an addenda record of type 99, at positions 4 to 6, to tell the originator why an entry was sent back. Exactly 70 of them officially exist: R01 to R47, R50 to R53, R61, R62, R67 to R77, and R80 to R85. Codes such as R63, R64, R65 and R66 are published widely across the web but are not return codes at all — they are the addenda sub-codes of R69, 'Field Error(s)'. The question a code really answers is whether you may send the entry again: an unauthorized return (R05, R07, R10, R29, R51) may not be reinitiated without a fresh authorization, while R11 — an unauthorized code — may be corrected and re-sent.

Validate your file right now

Free, instant and 100% in your browser - no file is ever uploaded.

Open the ACH / NACHA Validator

Where the code actually lives in the file

A return is not a message you receive alongside the payment. It is an entry, inside an ACH file, carrying an addenda record of type 99. The code sits at positions 4 to 6 of that 94-character record — which is why a return is something you parse, not something you read in an email.

799R01 091000010000001      091000019100001...
 │ │  └── positions 4-6: the return reason code
 │ └───── positions 2-3: addenda type 99 = a return
 └─────── position 1: record type 7 = addenda

Two consequences that people get wrong, both expensive. A return is a real entry: money comes back. A Notification of Change, addenda type 98, is a zero-dollar entry: the payment went through, and the bank is telling you to correct your data for next time. Treating a NOC as a failed payment and re-sending it pays the same invoice twice.

And the fields of a return are not rewritten. Nacha states that each field of a return or a NOC stays unchanged from the original entry. There is no SEC code called 'RET'; the Company Entry Description does not become 'RETURN' or 'SOFTWARE'. Real returned files carry whatever the original carried — 'TRANSFER', 'Vendor Pay'. A parser that looks for those markers will find nothing, and conclude, wrongly, that the file is not a return.

The codes that actually matter

Out of seventy, a handful account for the overwhelming majority of returns — and the Federal Reserve groups them for you, by name, in its own ACH Return Reason Report.

R01 — Insufficient Funds

The account is valid and open; the money simply was not there at posting. It comes back within two banking days. It is also one of the few codes you may reinitiate, under the conditions the Nacha rules set: identical Company Name, Company ID and Amount, and 'RETRY PYMT' in the Company Entry Description.

R02, R03, R04 — what the Fed itself calls the Invalid/Admin Returns

Account closed; no account or unable to locate; invalid account number. These are data problems, not money problems: your record of the customer's account is wrong, and sending the same entry again will fail the same way. Fix the mandate, not the timing.

R05, R07, R10, R11, R29, R51 — the Fed's Unauthorized Returns group

This is the group that carries regulatory risk, because an unauthorized return rate above the Nacha threshold puts your ability to originate at stake. It is also the group where reinitiating is not a retry but a rules violation — with the single exception of R11, below.

R14 and R15 — a death

The representative payee or the account holder has died. These are the only two codes that carry a Date of Death, at positions 22 to 27 of the addenda 99. On every other return code that field is blank — and a parser that reads it anyway will produce a date out of thin air.

The myths — and one of them was ours

This section exists because the free content on ACH return codes is, in places, simply wrong, and the errors are repeated by large and reputable payment companies. We re-checked all seventy codes against Nacha's own ISO 20022 mapping guide, the Federal Reserve's ACH Return Reason Report and the US Treasury's Green Book. Four findings.

R63, R64, R65 and R66 are not return codes

The official list goes from R62 straight to R67 — in Nacha's guide and in the Fed's report alike. What is published as 'R63 — Incorrect Dollar Amount' is in fact sub-code 03 of the R69 addenda, as the Green Book prints it. If you built a lookup table from a vendor page, it contains four codes that will never arrive, and it is missing the mechanism that produces them.

R11 is not a 'Checksum Abbreviation Error'

Stripe's public page says it is. That is wrong, and it inverts the advice. R11 means the customer states the debit did not match the terms of the authorization — wrong amount, debited too early. Since 2020 it is the one unauthorized code you may fix: correct the underlying error and send a new entry within 60 days of the return's settlement date, with no new authorization needed.

R85 is not an IAT code

R80 to R84 apply to outbound IAT entries. R85's scope, in Nacha's own table, is every SEC code EXCEPT IAT: it is a domestic-coded entry that the gateway recognises as an outbound international payment which should have been an IAT in the first place. Lumping R80-R85 together as 'the IAT codes' gets the one that matters backwards.

R44 exists — and we were the ones getting this wrong

'Invalid Individual ID Number', for ENR entries. It is in Nacha's guide and in the Fed's report. We had deliberately left it out of this site, because the vendor pages we had sourced it from contradicted each other — we mistook the absence of a reliable source for the absence of a code. It is published now, and this page exists partly to say so.

R69, 'Field Error(s)', does not name the faulty field in the code. It names it in the addenda, as a two-digit sub-code — and this list is the entire reason R63-R66 look real to anyone who has seen it out of context (source: Green Book, public domain):

01Return contains incorrect DFI Account Number
02Return contains incorrect Original Entry Trace Number
03Return contains incorrect dollar amount
04Return contains incorrect Individual Identification Number / Identification Number
05Return contains incorrect Transaction Code
06Return contains incorrect Company Identification Number
07Return contains an invalid Effective Entry Date

All 70 ACH return codes

Grouped by what they are about, most common first. Each code links to its own page: what it means, what causes it, the return window when an official source states one, and whether you may send the entry again. This table is generated from the same data our validator uses, so it cannot drift away from the tool.

Funds

Account

Authorization & disputes

Data & format

Routing

Administrative

Other

Codes that do not exist, whatever a search result tells you: R48, R49, R54 to R60, R63 to R66, R78, R79, and anything above R85. One new code is coming: R90, 'Entry Returned Due to RDFI's Sanctions Compliance Obligations', takes effect on 17 March 2028 — and on the same day R16 loses its OFAC half and goes back to meaning 'Account Frozen' alone.

What to do when a return lands

In order. The first two steps take a minute, and they are the two that prevent the expensive mistakes.

1Read positions 4 to 6 of the addenda 99. That is the code — not the label your bank's portal decided to put on it.
2Ask the only question that really matters: is it an unauthorized return? R05, R07, R10, R29 and R51 may not be reinitiated. Sending the entry again is not a retry, it is a rules violation.
3If it is R11, you may correct and re-send — within 60 days of the return's settlement date, with no new authorization. It is the exception to the rule above, and it is worth real money.
4If it is R69, open the addenda. The two-digit sub-code tells you which field the ODFI says is wrong, and there are seven of them.
5If it is R01 or R09, reinitiation is allowed under the Nacha rules: Company Name, Company ID and Amount must be identical, and 'RETRY PYMT' must appear in the Company Entry Description. The rules also cap how many times and for how long — those exact figures are published only in the paid rulebook, and we do not quote numbers we cannot source.

Then validate the corrected file before you send it. A second return on the same entry is not free, and on the unauthorized codes it is not even allowed.

Validate an ACH file before it comes back

Drop a NACHA file into the validator: record structure, ABA check digits, entry hash, batch and file control totals — and the addenda decoded, including returns (99), notifications of change (98) and IAT (10 to 18). It runs entirely in your browser; the file never leaves your machine.

Open the ACH validator

Official sources — and what we refuse to say

The Nacha Operating Rules book is copyrighted and sold. We have not bought it and we do not reproduce its prose. Everything on this page is checked against free official publications: Nacha's own ISO 20022 mapping guide, which carries the full code table; the Federal Reserve's ACH Return Reason Report, which lists the codes it processes with and without activity — which is what makes it decisive on which codes exist; and the US Treasury's Green Book, which is in the public domain. Where only the paid rulebook states a number — the dishonored and contested return windows, the exact reinitiation limits — this page says the rule exists and does not invent the figure.

Frequently Asked Questions

How many ACH return codes are there?

Seventy. R01 to R47, R50 to R53, R61, R62, R67 to R77, and R80 to R85. Nacha's ISO 20022 mapping guide and the Federal Reserve's ACH Return Reason Report list the same set, and the Fed's report is decisive because it enumerates the codes it processes with and without activity — a code missing from it is a code that does not exist.

Is R63 a real ACH return code?

No. Neither are R64, R65 and R66. The official list goes from R62 straight to R67. What is published elsewhere as 'R63 — Incorrect Dollar Amount' is sub-code 03 of the addenda attached to R69, 'Field Error(s)'. The confusion is understandable — the sub-code list reads exactly like a list of return codes — but an R63 will never arrive in your file.

What is the difference between R10 and R11?

Both are unauthorized returns and both carry a 60-day window. R10 means the customer says the debit was not authorized at all. R11 means the customer says the debit did not follow the terms of an authorization that does exist — a wrong amount, a debit taken too early. The practical difference is decisive: with R11 you may correct the error and send a new entry within 60 days of the return's settlement date, without obtaining a new authorization. With R10 you may not.

Can I re-send an entry that was returned?

It depends entirely on the code. R01 and R09 (funds) may be reinitiated under the Nacha rules, with identical Company Name, Company ID and Amount and 'RETRY PYMT' in the Company Entry Description. The unauthorized codes — R05, R07, R10, R29, R51 — may not: they need a fresh authorization, and re-sending is a rules violation. R11 is the exception: correct and re-send within 60 days, no new authorization required.

Where is the return code in an ACH file?

In an addenda record of type 99, at positions 4 to 6 of the 94-character record. Position 1 is the record type ('7' for an addenda), positions 2 and 3 are the addenda type code ('99' for a return). Positions 22 to 27 hold a Date of Death, but only on R14 and R15 — on any other code that field is blank.

What is the difference between a return and a Notification of Change?

A return (addenda 99) sends the money back: the payment failed. A Notification of Change (addenda 98) is a zero-dollar entry: the payment succeeded, and the receiving bank is telling you that some of your data — an account number, a routing number, a transaction code — must be corrected for next time. Re-sending a NOC as a payment pays the same invoice twice.

How long does a bank have to return an ACH entry?

Two banking days is the administrative norm: the Green Book states that a return must be received by the opening of business on the second banking day following the settlement date of the original entry. Consumer unauthorized debits carry an extended window of 60 calendar days. The exact windows for dishonored and contested returns are published only in the paid Nacha rulebook — we do not quote figures we cannot source, and R68 'Untimely Return' and R72 'Untimely Dishonored Return' exist precisely to sanction a missed deadline.

Is a new ACH return code coming?

Yes. R90, 'Entry Returned Due to RDFI's Sanctions Compliance Obligations', takes effect on 17 March 2028. On the same day, R16 loses the OFAC half of its meaning and goes back to being 'Account Frozen' alone. Neither change is live today, and R90 does not exist in the network yet.