An ACH debit does not fail at the moment you submit it. It fails days later, as a return file, and by then you have probably already shipped the goods or released the funds. That delay is the whole problem with building on ACH, and the return code is the only thing that tells you what went wrong and whether you can do anything about it. Treat R01 and R10 as the same "payment bounced" event and you will eventually credit a customer who filed a fraud claim, or re-debit an account you were never authorised to touch.
Return codes are not interchangeable. They run on different clocks, some count against limits that can get your origination privileges revoked, and the rights attached to them depend on whether the account is a consumer or a business. Here is what the ones that matter actually mean, how the return windows work, and how Stripe, Dwolla and Modern Treasury surface them.
What Is an ACH Return Code?
When you originate an ACH entry, it flows through your bank (the ODFI, the Originating Depository Financial Institution) to an ACH Operator (the Federal Reserve's FedACH or The Clearing House) and on to the receiver's bank (the RDFI). If the RDFI cannot or will not post the entry, it sends it back as a return, carrying a three-character reason code in the form Rnn. The code is set by the RDFI, not by you and not by your processor. Your processor just relays it.
This is the structural difference from card payments. A card authorisation gives you a yes or no in roughly a second, with a decline code you can act on at checkout. ACH gives you provisional acceptance and a return that can land four or more business days later, sometimes much later. The code is the entire signal, so reading it correctly is the job.
ACH Return Codes List: The Ones That Actually Matter
There are roughly 80 codes in the Nacha Operating Rules. In practice a handful account for nearly all volume. These are the ones worth handling explicitly.
| Code | Meaning | Window |
|---|---|---|
R01 | Insufficient funds | 2 banking days |
R02 | Account closed | 2 banking days |
R03 | No account / unable to locate account | 2 banking days |
R04 | Invalid account number structure | 2 banking days |
R05 | Unauthorised debit to consumer account using a corporate SEC code | 60 calendar days |
R07 | Authorisation revoked by customer | 60 calendar days |
R08 | Payment stopped | 2 banking days |
R09 | Uncollected funds (posted but not yet available) | 2 banking days |
R10 | Customer advises originator not known / not authorised | 60 calendar days |
R11 | Customer advises entry not in accordance with the terms of the authorisation | 60 calendar days |
R16 | Account frozen / returned per OFAC instruction | 2 banking days |
R20 | Non-transaction account (ACH not permitted) | 2 banking days |
R29 | Corporate customer advises not authorised | 2 banking days |
The split that trips people up is R01 versus R10. R01 is a balance problem: the account is fine, the money was not there. It is the one return you can reasonably retry, because funds may arrive later (payday, invoice settlement). R10 is an authorisation problem: the account holder says you had no right to debit them at all. Retrying an R10 is not a retry, it is a second unauthorised debit, and it counts against you twice.
R10 vs R11: What Changed in 2021
Before 2020, R10 was the catch-all for every "I didn't authorise this" complaint, whether the customer genuinely never authorised anything or simply disputed the amount or date of a debit they had agreed to. Nacha split those two cases.
R10now means no authorisation exists. The originator is unknown to the receiver, or the receiver never authorised that originator to debit the account. This is the true fraud or mistaken-identity bucket.R11means an authorisation exists but the entry breaks its terms: wrong amount, debited earlier than agreed, an incomplete transaction, or an improper reinitiation.
R11 was repurposed in Phase 1, effective 1 April 2020, and became subject to Nacha's Unauthorised Entry Fee in Phase 2, effective 1 April 2021. Its return window was also extended to 60 calendar days. The one practical bonus is that R11 uniquely lets the originator correct the defect and resubmit the entry within 60 days without obtaining a fresh authorisation, because the authorisation itself was never in dispute. An R10 gives you no such path.
R10 vs R29: Why Consumer and Corporate Returns Differ
R10 and R29 describe the same event, "this debit was not authorised", for two different account types, and the consequences diverge sharply.
R10 applies to consumer accounts. The consumer gets a 60 calendar-day window from the settlement date to dispute, and the dispute is backed by Regulation E and a Written Statement of Unauthorised Debit (WSUD). The return is final; you cannot contest it through the ACH network.
R29 applies to business accounts (typically CCD entries). A business receiver is not covered by Regulation E, so there is no 60-day consumer window. The RDFI's standard window to return applies: the entry must normally be made available to the ODFI by the opening of the second banking day following settlement. Plenty of secondary guides wrongly list R29 as a 60-day code. It is not. Two banking days is the figure that matters, and it is why B2B ACH feels so much less reversible than consumer debits once a day or two has passed.
That asymmetry should shape product decisions. If you debit businesses, your exposure window is short but your recovery options after it closes are essentially nil. If you debit consumers, you carry a 60-day tail on every single debit, which is the risk the rest of this guide is really about.
How Long Do You Have to Return an ACH Payment?
Two clocks, and the SEC code (Standard Entry Class) on the entry decides which one applies. The SEC code tells the network whether the receiver is a consumer or a business and how authorisation was obtained.
| SEC code | Receiver | Typical use |
|---|---|---|
PPD | Consumer | Payroll, recurring bills, subscriptions |
WEB | Consumer | Authorisation obtained online or in-app |
TEL | Consumer | Authorisation obtained by phone |
CCD | Corporate | Vendor payments, cash concentration |
IAT | Either | Cross-border; mandatory OFAC screening |
The rules then layer on:
- Standard window, 2 banking days. Administrative and funds-related returns (
R01,R02,R03,R04,R08,R09,R16,R20, andR29) must be made available to the ODFI by the opening of business on the second banking day after the settlement date. - Extended consumer window, 60 calendar days. Unauthorised or improper consumer debits (
R05,R07,R10,R11,R51) can be returned up to 60 calendar days after settlement, and require a signed WSUD from the consumer.
R10. If your system marks an ACH payment as irreversibly "paid" after a few days and tears down the ability to reconcile a late return against the original order, that late R10 becomes a manual incident every time instead of an automated reversal. This is the same late-notification trap as a card chargeback, and the same discipline applies as with chargeback reason codes: keep the dispute path alive long after the payment looks settled.
ACH Return Rates: The Nacha Thresholds That Get You Shut Off
This is the part that turns return handling from a reconciliation chore into an existential one. Nacha monitors originators against three return-rate thresholds, measured over a rolling 60-day period. The limits were set by a 2015 rule effective 18 September 2015.
| Rate | Limit | Codes counted | Consequence of breach |
|---|---|---|---|
| Unauthorised return rate | 0.5% | R05, R07, R10, R11, R29, R51 | Direct rules violation; corrective action |
| Administrative return rate | 3.0% | R02, R03, R04 | Opens a Nacha inquiry |
| Overall return rate | 15.0% | All codes, including R01/R09 | Opens a Nacha inquiry |
The unauthorised rate is the one that bites. At 0.5%, exceeding it is a direct violation of the rules, not merely a trigger for a conversation. Put it in context: one unauthorised return in every 200 debits puts you at the limit. A single bad onboarding flow that lets customers mistype account details, or a billing change that surprises people into disputing, can cross it inside one 60-day window. Breach it and the path runs through your ODFI to a Nacha inquiry, potential fines, and ultimately suspension or termination of your ability to originate at all.
The administrative rate (3%) is why account validation exists as a product category. R02, R03 and R04 are all "the account details are wrong" returns, and they are preventable before you ever originate by validating the account first. Nacha's own WEB-debit rules already require a reasonable method of account validation for the first use of an account, which is the regulatory reason services like Plaid's balance and identity checks, or micro-deposit verification, sit in front of ACH flows.
ACH Returns vs SEPA Direct Debit Returns
If you are building for both the US and Europe, do not assume the reversal model carries over. It does not.
SEPA Direct Debit Core gives the consumer an 8-week, no-questions-asked refund right on an authorised collection, and 13 months to claim back a collection made with no valid mandate. ACH has nothing equivalent to the 8-week right. An authorised ACH consumer debit is not refundable just because the customer changed their mind; to pull it back the customer must either place a stop payment (R08) before it clears or revoke the authorisation (R07). For the genuinely unauthorised case, ACH gives 60 calendar days against SEPA's 13 months.
The corporate side rhymes. SEPA B2B removes the debtor's refund right and is effectively irrevocable shortly after debit, which is the direct analogue of ACH's R29 with its 2-day window. The takeaway for a payments engineer: the US consumer window is far tighter than Europe's (60 days versus 13 months), but the US gives you no equivalent of SEPA's blanket 8-week refund, so your dispute logic genuinely has to fork by scheme. A single abstracted "return" handler that assumes one set of windows will be wrong on one side of the Atlantic.
How Stripe, Dwolla and Modern Treasury Expose ACH Returns
Three common platforms, three different shapes for the same underlying Nacha return. The abstraction leaks in each case, so know what you are getting.
Stripe (ACH debit viaus_bank_account) settles on a roughly T+4 business-day timeline, with faster T+2 available to eligible users. A failure before settlement arrives as charge.failed or, on Payment Intents, payment_intent.payment_failed. The important detail is the late return: if the entry had already reached succeeded and a return comes back afterwards, Stripe does not reverse the charge silently, it creates a dispute and fires charge.dispute.created, with a reason of insufficient_funds, incorrect_account_details or bank_cannot_process. Stripe collapses Nacha's ~80 codes into those three buckets, so if you need the exact R10-versus-R11 distinction, Stripe's API will not give it to you cleanly. It also enforces the 60-day-consumer versus 2-day-business split in its own documentation.
Dwolla reports failures through transfer_failed (or customer_bank_transfer_failed for Customer transfers). The return code is not inline on the webhook: the failed transfer carries a failure link, and you follow it with GET /transfers/{id}/failure to retrieve the actual ACH return code, its description and an explanation. One extra round trip, but you get the real Rnn value rather than a reduced enum.
Modern Treasury models it closest to the metal with a Return object. The literal field holding the code is code (value "R01", "R03", and so on), not return_reason_code, with reason carrying the human-readable text and type an enum (ach, ach_noc, sepa, wire). It exposes role (originating or receiving) and even a date_of_death field for the R14/R15 death-of-account-holder cases. If your business needs to reason about specific codes, this is the model that lets you.
The trade-off in one line: Stripe hides the codes behind three reasons and is simplest to integrate; Modern Treasury hands you the raw Nacha code and expects you to know what it means; Dwolla sits in between with an extra fetch. Pick based on how much your product logic actually branches on the specific return code.
What This Means for Developers Building ACH in 2026
Concrete steps, in priority order:
1. Branch on code class, not on "failed". At minimum separate retryable funds returns (R01, R09) from unauthorised returns (R05, R07, R10, R11, R29). Never auto-retry an unauthorised code; each retry is a fresh violation and feeds the 0.5% rate.
2. Validate accounts before you originate. Account validation knocks out most R02/R03/R04 administrative returns and keeps you clear of the 3% rate. It is also a Nacha requirement for first-use WEB debits, not an optional nicety.
3. Keep the 60-day tail alive. Store the originating entry and its SEC code, and keep a reconciliation path open for at least 60 calendar days so a late consumer return reverses automatically instead of becoming a support ticket.
4. Fork your dispute logic by scheme. ACH and SEPA do not share windows or refund rights. Do not abstract them into one handler.
5. Instrument your own return rates. Compute the three Nacha rates on a rolling 60-day basis in your own dashboards. By the time your ODFI calls, you want to have seen it coming.
My prediction, and this is opinion rather than rule: the return code will become a weaker signal over the next few years, not a stronger one. Nacha's new risk-management rules begin phasing in during 2026 and push fraud detection upstream, requiring larger ODFIs and RDFIs to run risk-based monitoring, including monitoring credit entries for credit-push fraud. The direction of travel is to catch bad entries before they settle rather than unwinding them afterwards through returns. For developers that means the cheapest place to handle an ACH problem is shifting from "parse the return" to "never originate it", and the teams that invest in pre-origination validation now will spend the back half of the decade well under every threshold while everyone else is still writing return-code switch statements.
If you are wiring ACH into a product and want a second pair of eyes on the reversal model, that is the kind of thing I spend my days on. You can find more of my writing on payments infrastructure via Tom Wang.