ACH return codes are the R-codes a receiving bank attaches to every return to say why it came back: R01 for insufficient funds, R02 for a closed account, R03 for no account found, R10 and R11 for a customer's claim that a debit was not authorized or not as authorized, and dozens more. Getting the code right matters because each one sends a different instruction to the originator and lands in a different one of Nacha's return-rate measures, so a wrong code can push a legitimate business toward an inquiry or let a bad one hide. The difficulty is that the hardest codes are chosen from a customer's own words, not from the core. Botminds' ACH Returns & NOC Management proposes each code with the evidence behind it and has a second specialist re-check a sample daily; this guide explains how to measure whether those codes, or anyone's, are right.
Examples come from a fictional sample bank, Tessaly Community Bank, as it runs through the solution in October 2026. Code meanings and rules are from Nacha's public rule pages and the U.S. Treasury, linked where they appear.
ACH return codes grouped by what they tell the originator
| Family | Common codes | What the code tells the originator | Which Nacha rate it counts in |
|---|---|---|---|
| Funding | R01 insufficient funds | The authorization stands; the money was not there. It may be reinitiated within the rules’ limits. | Overall only |
| Account data | R02 account closed · R03 no account / unable to locate · R04 invalid account number structure | The account details are wrong or the account is gone. Fix the data before the next debit. | Administrative and overall |
| Unauthorized, consumer | R05 · R07 authorization revoked · R10 not known or not authorized · R11 not in accordance with the authorization | The customer disputes the authority behind the debit, with a signed statement. R11 alone allows a corrected new entry without a new authorization. | Unauthorized and overall |
| Unauthorized, business | R29 corporate customer advises not authorized | The business account holder disputes a CCD or CTX debit, inside the two-day window. | Unauthorized and overall |
| Questionable | R17 with “QUESTIONABLE” | The RDFI itself believes the entry was fraudulent or initiated under questionable circumstances. | Overall; not administrative |
| Requests and status | R06 returned per ODFI request · R14, R15 deceased · R16 account frozen · R20 non-transaction account | Something about the request or the account holder’s status, not about the originator’s authorization. | Overall |
Which ACH return codes matter most, and why is each one a decision?
By volume, the funding and account-data codes matter most; by consequence, the unauthorized codes do. A Federal Reserve study that matched every FedACH consumer debit return in a 2006 sample to its original entry found insufficient funds behind roughly seven in ten returned items, with administrative problems and what the authors called potentially suspicious activity each around a tenth (Armantier et al., Federal Reserve Bank of Minneapolis, 2010; the study's own words are in the eleven tasks of an ACH returns desk). Those shares are old, but no newer public breakdown exists, and they match what an operations team sees in its own exception report.
Why consumer debits came back, in the Fed's matched 2006 FedACH data
The code is a decision because the originator acts on it. An R01 says try again later within the rules' limits on reinitiation. An R03 says your data is wrong. An R10 says the customer does not know you or never authorized you, and Nacha is blunt about what follows: "an unauthorized debit cannot be remedied," and reinitiating an entry returned as unauthorized is "an improper reinitiation practice" (Nacha, ACH Network Risk and Enforcement Topics). The same customer, the same debit, coded two ways, sends the originator down two different roads.
What is the difference between R10 and R11?
R10 means the customer says the originator is not known to them or was never authorized to debit the account; R11 means there was an authorization, but this entry broke its terms, for example the wrong amount or an earlier date. Nacha re-purposed R11 for that meaning in April 2020, because R10 had become a catch-all "including some for which a valid authorization exists, such as a debit on the wrong date or for the wrong amount" (Nacha, Differentiating Unauthorized Return Reasons).
“A key difference between R10 and R11 is that with an R11 return an Originator is permitted to correct the underlying error, if possible, and submit a new Entry without being required to obtain a new authorization.”
Nacha, Differentiating Unauthorized Return Reasons (effective April 1, 2020 and 2021)
Both require the customer's written statement of unauthorized debit, both have a 60-day return timeframe for consumer accounts, and both count in the unauthorized return rate and the unauthorized entry fee. The difference falls entirely on the originator. After an R11 it can correct the amount or the date and send a new entry "within 60 days of the Settlement Date of the R11 Return Entry," without asking the customer again. After an R10 it has lost the customer's authority and needs a new one. Neither code covers "disputes about goods and services," which stay between the customer and the merchant.
R07, R10 and R11: what the customer's statement must say for each
What the customer says: I do not know this company, or I never gave it permission to debit my account.
What the originator can do next: Nothing on the old authority. A new debit needs a new authorization.
What the customer says: I gave permission, then took it back before this debit.
What the originator can do next: Stop debiting. The relationship existed; the authority ended on the date the customer gives.
What the customer says: I authorized this company, but this debit was the wrong amount, too early, or otherwise outside what I agreed.
What the originator can do next: Correct the error and send a new entry within 60 days of the return’s settlement, without a new authorization.
R07: revoked is not the same as never authorized
R07 is the code for a debit the customer once authorized and then revoked before the debit was made. Nacha's 2020 reorganisation of the statement rules filed "authorization revoked" alongside the unauthorized-debit grounds and noted it "continues to use return reason code R07." It is the code most often lost when a claim is coded from a form rather than from the statement, because a customer who cancelled a subscription will often tick the box that says she never authorized it.
At the sample bank, Dana Whitcombe disputed two $189.00 WEB debits from VANTORRA CLUBS, settled on September 2 and October 2. The claim form said R10. Her signed statement said she revoked the authorization on August 3, and she attached the cancellation email from that day. Both debits came after the revocation, so the agent proposed R07 for $378.00, explaining that R10 "would say she never authorized Vantorra Clubs, which her own statement contradicts."
Why it matters: an R10 tells the club it has no customer; an R07 tells it it has an ex-customer it kept billing. The first looks like identity misuse or a bad authorization flow; the second looks like a cancellation process that does not work. For the club's bank, watching its unauthorized rate, the two point to different fixes. The written statement of unauthorized debit, element by element shows where in the form that choice is made.
Which ACH return codes are unauthorized?
Six codes count as unauthorized: R05, R07, R10, R11, R29 and R51. Nacha's Risk Management Advisory Group lists exactly those and explains that the label means "the Originator does not have authorization to debit the account" (Nacha RMAG, 2024). They are the codes that make up the unauthorized return rate, held to Nacha's 0.5% threshold, and the codes that carry the unauthorized entry fee the ODFI pays the RDFI.
R29 is the business counterpart. Nacha's 2020 rule kept it for corporate entries: "R29 will continue to be used for CCD & CTX to non-consumer accounts." A business account holder's dispute does not get the consumer's 60 days, so an R29 has to be identified and sent inside the ordinary two-day window. R05 covers a debit to a consumer account sent with a corporate entry code, and R51 an improperly originated re-presented check (RCK) entry; both are rarer, and both still count toward the 0.5% line.
R17 QUESTIONABLE, R03 and R04: one symptom, different messages
When an incoming debit carries an account number that does not exist, the RDFI can return it as R03 or R04, an administrative error, or as R17 with the word "QUESTIONABLE" if it believes the entry was "initiated under questionable circumstances." Nacha introduced that use of R17 in 2019 and said plainly that it is optional: "the RDFI may continue to use R03 (No Account/Unable to Locate Account) or R04 (Invalid Account Number Structure)" (Nacha, Return for Questionable Transaction). In October 2024 Nacha widened R17 so an RDFI may use it for any entry it believes is fraudulent, still on the standard two-day timeframe (Nacha, Risk Management Topics 2024); how that sits beside Nacha's false pretenses rules is a fraud question more than a coding one.
The choice matters for measurement. Returns marked R17 "QUESTIONABLE" are not counted in the administrative return rate, so an RDFI that flags suspicious invalid-account debits as R17 removes them from the originator's administrative rate while sending a stronger warning. A bank that never uses R17 sends the same signal as a typo. At the sample bank, three incoming credits that looked fraudulent were proposed as R17 and routed to the ACH operations manager rather than approved in the batch. Credit fraud monitoring itself, which Nacha's rules required of every RDFI from June 19, 2026, is ACH credit monitoring by RDFIs, the work of ACH Fraud Monitoring.
Measure accuracy by code family, not one pass rate
A single "codes correct" percentage hides the errors that matter, because the easy families dominate the count. If 70% of returns are insufficient funds coded straight from the core, a bank can report 97% accuracy while getting a quarter of its customer claims wrong. Accuracy should be measured within each family, against the evidence for that family, and the confusions that cross a rate boundary should be counted separately.
The confusions to count, and what each one costs
| Confusion | How it happens | What it changes |
|---|---|---|
| R10 coded when R07 was right | Claim coded from the form; the statement says the customer revoked | The originator treats an ex-customer as a stranger; its cancellation problem goes unfixed |
| R10 coded when R11 was right | A wrong-amount or early debit described as “not authorized” | The originator must seek a new authorization instead of correcting and resending |
| R03 or R04 where R02 was right | The account existed but was closed; the posting run read it as unknown | The originator’s data is wrongly blamed; at the sample bank one such change was made with reason RC-05 |
| R03 or R04 where R17 was warranted | A pattern of invalid accounts not flagged as questionable | The administrative rate rises and the fraud signal is lost |
| R15 used on a joint account | A death flag returns a survivor’s federal benefit | Treasury notes it can trigger an improper death termination for the surviving spouse |
| Unauthorized code without a signed statement | An extended return sent on a phone call alone | The return is not supported under the Nacha Rules and can be challenged |
The federal benefit row is worth reading in full in the Treasury's guide, because it shows how far a wrong code travels. "Any payment returned for 'death' will cancel both the Direct Deposit authorization and the recipient's entitlement to that payment," the Green Book warns (U.S. Treasury, Green Book). The code is read by a machine at the other end, and the machine acts on it.
What happens if the wrong return code is used?
Usually nothing visible at first: the return settles and the money moves. The damage arrives downstream. The originator acts on the wrong instruction, the originator's rates move in the wrong column, and a customer whose claim was coded R10 when she revoked keeps hearing from a company that thinks it has a fraud problem. A wrong unauthorized code on a debit the customer had actually authorized also exposes the RDFI: the Federal Reserve's ACH circular lets the sending bank dispute a return it believes was improper (Operating Circular 4), and what a dishonored or late return costs follows that dispute through settlement.
Nacha's assignments are specific enough that a code is checkable against the rule. Its 2021 reversals rule, for example, sends an improper reversal to a consumer account back as R11 and one to a business account as R17 (Nacha, Reversals and Enforcement). Because the originator acts on the code as soon as the return arrives, the check belongs before the file, not after it. The codes themselves are still changing: Nacha has approved a new R90 for returns made to comply with sanctions obligations, listed under March 17, 2028 (Nacha, New Rules).
How do you audit ACH return codes?
Audit return codes by re-deriving a sample from the evidence alone, without seeing the code first, and scoring agreement family by family. The checklist below is the method ACH Returns & NOC Management's daily re-check follows, and it works the same way on a manual process.
A return code audit a second specialist can run every day
- Sample within each family
Draw separately from funding, account-data, unauthorized and questionable returns, so the claims are not drowned by R01s.
- Re-derive the code blind
The re-checker reads the core’s balance and status, or the customer’s statement, and picks a code before seeing the one sent.
- Score agreement per family, and count rate-crossing confusions apart
An R10 for an R07 is a different error from an R03 for an R04; only the first changes what the originator does.
- Read every override
Each change to a proposed code carries a reason code and text. A cluster of the same reason is a rule to fix.
- Check the statement behind every unauthorized code
Signed, dated on or after presentment, naming the entries, with the box that supports the code.
- Watch what originators do next
An R11 followed by a corrected entry within 60 days, or an R10 followed by a reinitiation, shows whether the message landed.
Every proposed code, change and re-check on one ACH Returns & NOC Management trail
How ACH Returns & NOC Management chooses a code, and when it refuses to
For a posting exception, the returns agent reads the entry, the account's balance and status from the core, stop payments and any claim, and proposes the code the evidence supports, citing each check. For a claim, the statement reader reads the signed statement and its attachments, notes the box ticked, the date signed and the entries named, and says which code the statement supports. Below 95% confidence the agent does not propose: it asks the specialist.
A routine code, with its four checks cited
The design keeps the hard choices where they belong. Code changes after a proposal need the ACH operations manager's check; R17 returns of suspected fraud go to the manager; and a referral that follows from an R17 appears only in the BSA officer's view, never in a notice. Which return tasks agents should take, and which they should not places code selection among the morning's other ten. The solution as a whole is at ACH Returns & NOC Management.
Questions people ask
What are the most common ACH return codes?
R01 insufficient funds is by far the most common for consumer debits, followed by account-data codes such as R02 account closed, R03 no account and R04 invalid account number. In the Federal Reserve's matched 2006 data, insufficient funds explained about 70% of returned consumer debits.
What is ACH return code R29?
R29 is the unauthorized code for business accounts: a corporate customer advises that a CCD or CTX debit was not authorized. It counts in the unauthorized return rate and must be sent within the ordinary two-banking-day window, not the consumer's 60 days.
What does R17 QUESTIONABLE mean?
It means the receiving bank believes the entry was initiated under questionable circumstances, typically a debit to an invalid account number or, since October 2024, any entry it thinks is fraudulent. The RDFI writes "QUESTIONABLE" in the return's addenda, uses the standard two-day timeframe, and the return is excluded from the administrative return rate.
Is R07 counted as an unauthorized return?
Yes. R07, authorization revoked by the customer, is one of the six codes Nacha counts in the unauthorized return rate, along with R05, R10, R11, R29 and R51. It needs the customer's signed statement like R10 and R11.
Where is the full list of ACH return codes?
In the licensed Nacha Operating Rules, which keep the complete table. Beyond the codes an RDFI uses, it includes codes the two banks use between themselves, such as R61 misrouted return, R67 duplicate return and R68 untimely return, which the U.S. Treasury's Green Book lists for dishonored returns. The table still grows: R90, for returns made to meet sanctions obligations, is approved for March 2028.