ACH Return Codes Explained: Every R-Code & How to Fix Failed Bank Debits (2026)

An ACH return code is a two-character label — like R01, R08, or R10 — that a bank attaches when it sends a debit back unpaid through the ACH Network. This guide covers every return code that matters for a subscription business, which ones are safe to retry, and which ones you are legally required to stop and get a fresh authorization for.

Unlike a card decline, which comes back from the network in seconds, an ACH return usually arrives one to two days after the debit looked like it had gone through. By the time you see the R-code, the customer may already believe the payment succeeded — so reading the code correctly, and reacting the right way, matters even more than it does for cards.

What is an ACH return code?

When a business debits a customer's bank account over the ACH Network — for a subscription, an invoice, or a one-time charge — the Originator sends the request through its bank (the ODFI, or Originating Depository Financial Institution). That request travels across the ACH Network — operated by the Federal Reserve's FedACH service or the private-sector EPN(Electronic Payments Network) — to the customer's bank, the RDFi (Receiving Depository Financial Institution). If the RDFi cannot pay the debit, it sends it back with a return code explaining why.

Every return code follows the NACHA Operating Rules — the rulebook that governs the entire ACH Network in the United States. That standardization is what makes the codes reliable:R01 means the same thing whether the customer banks with a national bank or a small local credit union.

SEC codes: why the same dispute can return under a different code

Every ACH entry carries more than a routing number and an amount — it also carries a three-letter Standard Entry Class (SEC) code, defined and maintained by NACHA, that records how the originator obtained authorization for that specific debit. The SEC code is not cosmetic. It determines which authorization rules apply to an entry, and in a few specific cases it determines which return codes the RDFi is even allowed to use.

• PPD (Prearranged Payment and Deposit) — consumer bank accounts, backed by a signed or otherwise-authenticated written authorization. The traditional default for recurring subscription billing collected on paper or through an offline mandate.
• CCD (Corporate Credit or Debit Entry) — business bank accounts, business-to-business. This is the code that quietly changes an authorization dispute from R10 into R29 — same underlying disagreement, different return code, because the receiver is a company, not a consumer.
• WEB (Internet-Initiated/Mobile Entry) — consumer debits authorized online. Stripe defaults to WEB for a consumer bank account unless told otherwise, and most checkout-collected ACH mandates for subscription products fall under this code.
• TEL (Telephone-Initiated Entry) — consumer debits authorized by phone, under its own strict rules: it only applies with an existing customer relationship or an inbound call from the customer, and NACHA requires either an audio recording of the authorization or written notice sent before the first debit.
• ARC (Accounts Receivable Entry) — a single debit created by converting a paper check received by mail, in person, or from a dropbox into an electronic entry.

For most subscription businesses this narrows down to two codes in practice: WEB for consumer self-serve checkout, CCD for company-billed accounts. Getting the SEC code wrong on file is not just a paperwork detail — a misclassified entry can itself trigger a return, and it decides whether a future authorization dispute on that account comes back as R10 or R29.

A few narrower SEC codes round out the list. BOC (Back Office Conversion) and POP (Point of Purchase) convert a paper check into an ACH debit much like ARC does, but at a staffed point-of-sale counter or a back-office scanning station instead of a mailed-in check. XCK(Destroyed Check Entry) applies when a bank has already received a paper check that is then lost or destroyed before it can be processed — it's the SEC code behind the rare R33 return covered later in this guide. CTX (Corporate Trade Exchange) is a business-to-business code built to carry detailed remittance data — structured ANSI X12 or EDIFACT information — alongside the payment itself, a step up in complexity from the simpler CCD format. None of these five are likely to show up in a typical subscription-billing dashboard, but they explain why NACHA maintains more SEC codes than most originators will ever personally use.

How an ACH return actually reaches you

A return is not instant. The debit settles first, and only afterward — if the RDFi cannot honor it — does the return travel back the same path in reverse: RDFi to the ACH Network, ACH Network to your ODFI, and your ODFI to you (usually surfaced by your payment processor as a webhook or dashboard event). For most return reasons, the RDFi has to send that return within a tight window.

Part of why that delay exists at all is structural: ACH was built as a batch, file-based system, not a real-time one. Entries are collected into files and exchanged between institutions on a schedule — Same Day ACH added same-business-day settlement windows on top of the original overnight batches, but it accelerated processing without turning ACH into an instant, transaction-by-transaction rail the way a card authorization is. A return still has to travel through that same batch-oriented plumbing, in reverse, which is why it can take days rather than milliseconds to find out a debit failed.

ACH return codes quick reference

The most common codes a subscription business will actually see, grouped by what to do next:

Funds return codes (retry these)

These mean the account itself is fine — there just wasn't enough available money to cover the debit at the moment it settled. A well-timed retry, especially right after a typical payday, frequently succeeds.

Account-detail return codes (fix, then resubmit)

These mean the account information itself cannot accept the debit — closed, wrong, frozen, or the wrong account type. Retrying the same details will only fail again; you need corrected information from the customer first.

R03 and R04 usually mean one of those two numbers was mistyped, transposed, or copied from the wrong line of a check. R02 and R20 mean the numbers were correct at some point, but the account itself no longer accepts debits the way it used to — closed, or converted to an account type that was never eligible in the first place.

Authorization return codes (stop — this is a compliance issue)

This group is where ACH is fundamentally different from a card decline. These returns mean the customer, or their bank on the customer's behalf, is saying the debit should never have happened. Re-submitting the same authorization is not just bad practice — it can violate the NACHA Operating Rules and put your originator status with your bank at risk.

Less common — but real — return codes worth knowing

The nine codes above cover the large majority of ACH returns a subscription business will ever see. A handful of others show up rarely enough that many teams never encounter them, but they are real, current NACHA return reason codes — and knowing what they mean saves a confused afternoon the one time one lands in your dashboard.

NACHA writes and enforces the Operating Rules that define every return code in this guide, but it does not operate in isolation. The Federal Reserve Board oversees the broader U.S. banking system, including Regulation E, the federal rule that gives consumers the right to dispute an unauthorized electronic debit. Regulation E is a real part of why R10gets treated so seriously: an RDFi that mishandles a customer's unauthorized-debit claim risks a Regulation E problem, not just a NACHA rules infraction.

R10 vs R11: the mix-up worth avoiding

R10 and R11 are the pair most likely to get confused. Both are authorization-related, both carry the extended 60-calendar-day return window, and both can arrive weeks after a debit looked completely normal. But they describe two different problems, and — the part that actually matters — they call for two different responses.

R10, Customer Advises Not Authorized, means the account holder is telling their bank this exact debit should never have happened — no valid authorization exists at all, in their view. R11, Customer Advises Entry Not in Accordance with the Terms of the Authorization, means something narrower: an authorization does exist, but this specific entry did not match it — the amount was wrong, the date was wrong, or some other term of the authorized debit was not honored.

R11 has not always meant this. Before a NACHA rule change, the code was defined narrowly around check-truncation entries; NACHA later repurposed it to give RDFIs and originators a way to flag a term mismatch without escalating straight to the harshest unauthorized-debit code. If an older reference still calls R11 a check-truncation-only code, it is describing a definition NACHA has since replaced — one more reason to confirm any return code against a current source rather than an old bookmark.

The practical consequence is the one worth remembering. An R10 is a hard stop — you need a brand-new, freshly obtained authorization before you touch that account again, the same rule that applies to R05, R07, R08, and R29. An R11, by contrast, is a correction: fix whatever term was wrong — the amount, the date — and resubmit under the accurate terms, without needing to collect a new authorization from scratch. Treating an R11 like an R10 means asking a customer to re-authorize a payment method they never actually revoked — needless friction. Treating an R10 like an R11 means resubmitting a debit the customer says was never authorized at all — a real compliance problem, not just an awkward email.

How this compares to a card decline

A business running both ACH and card payments is really running two different failure models, not one. A card decline — do_not_honor, insufficient_funds, a hard expired_card — comes back from the card network in real time, at the moment of authorization, before the transaction ever settles. An ACH return comes back afterward: the debit settles first and looks successful, and the return — if one comes at all — arrives one to sixty days later depending on the code. That single difference reshapes almost everything about how you have to build recovery around each rail.

The instant nature of a card decline is also why card recovery leans so heavily on decline-reason routing at the moment of failure — see our breakdown of the Do Not Honor decline code and the difference between a soft decline and a hard decline for how that plays out on the card side. ACH recovery has to work the opposite way: because the failure signal shows up after the fact, your process has to watch for a return that might not arrive for weeks, not just react to an instant no.

A worked example: one subscription business's 90-day return mix

Numbers help make the categories concrete. The following is an illustrative example, not a benchmark to compare yourself against — the actual mix varies enormously by customer base, ticket size, and how carefully authorization is collected at checkout. Picture a subscription business running 40,000 ACH debits over a 90-day window, with a 1.6% overall return rate — 640 returns total.

Almost half of the 640 returns are R01 alone. That fact should drive where the recovery effort actually goes: a well-timed retry sequence on R01 and R09 — roughly 52% of the total in this example — recovers more revenue per hour of engineering or support time than almost anything else on the list. The account-detail bucket (R02, R03, R04, R16, R20) is the next-largest slice at roughly 28%, and it needs a completely different motion: a targeted message asking for corrected details, not a retry. Authorization returns are a smaller share — about 14% here — but they carry the highest compliance risk per incident, which is why they deserve a manual review step even though they are the least frequent category.

A simple internal runbook, built by category rather than treated as one undifferentiated "failed payment" bucket:

1. Funds returns (R01, R09): auto-queue a retry 3–5 days out, tuned toward common payday windows. No human review needed unless the same account returns R01 three times in a row.
2. Account-detail returns (R02, R03, R04, R16, R20): auto-generate a details-update request within 24 hours; escalate to a person only if the customer has not responded within 7 days.
3. Authorization returns (R05, R07, R08, R10, R29): route to a human queue immediately, never auto-retry, and log the date and the return code for your own compliance record.
4. R11 specifically: route to whoever owns billing accuracy. It usually means an amount or date got generated wrong upstream, which is worth fixing at the source, not just resubmitting once.
5. Everything else (R06, R23, R31, R33): low volume, manual triage. Log it and move on unless a pattern emerges.
6. Review the mix monthly. A rising share of authorization returns in particular is worth investigating on its own — it can signal a checkout flow that is not collecting a clear-enough authorization, not just unlucky customers.

Why your return rate matters beyond any single return

Every return code discussion so far has looked at individual entries — what one R01 or R10 means for one customer. NACHA also watches the aggregate picture, and originators who ignore it can find themselves flagged regardless of how well they handle each return one at a time.

NACHA calculates three separate return-rate levels for every originator, each over a rolling 60-day window, each measured as returns divided by total debit entries in that category:

• Unauthorized return rate — 0.5%. Counts R05, R07, R10, R11, R29, and R51. This is the strictest threshold by a wide margin, and crossing it is treated as a rules violation in its own right, not just grounds for a review.
• Administrative return rate — 3%. Counts R02, R03, and R04 — the account-detail codes. Crossing this level does not automatically violate the rules, but it opens the door to a preliminary inquiry into your origination practices.
• Overall return rate — 15%. Counts every return code combined, including R01. Also a trigger for inquiry rather than an automatic violation, but a rate this high is a sign something upstream — checkout copy, timing, targeting — needs attention regardless of the compliance angle.

The unauthorized-return threshold is the one worth building a process around, because it is made up of the exact authorization codes covered earlier in this guide. A business that is sloppy about collecting and documenting authorization — vague checkout language, no timestamped consent record, reusing an old authorization for a changed amount — will tend to accumulate R10 and R11 returns faster than one that treats authorization as a compliance artifact worth keeping. Once an ODFI sees an originator approaching 0.5%, expect questions about consent capture long before the number actually crosses the line.

How to recover failed ACH payments

1. Funds returns (R01, R09) → smart retries. Re-attempt a few days later, ideally timed to when the account is likely to have a fresh deposit.
2. Account-detail returns (R02, R03, R04, R16, R20) → ask for updated details. Send a personalized message naming the exact problem, with one link to re-enter bank details. See our dunning email templates for copy that works.
3. Authorization returns (R05, R07, R08, R10, R29) → stop and re-consent. Contact the customer, resolve the dispute, and collect a new authorization before you debit that account again.
4. Track every return by code, not just as a generic "failed payment" — the code is what tells you whether recovery is even appropriate.

R01 retries succeed more often when timed to when money actually lands, not on a fixed schedule:

• Weekly payroll: concentrate retries in the Friday-to-Monday window.
• Biweekly payroll: alternate Fridays; a retry mistimed by even a few days often fails again.
• Semi-monthly: the 1st/15th and 15th/last-day patterns common in salaried roles.
• Monthly and government benefits (Social Security, SSI): most land around the 1st–3rd of the month.
• No known pattern: default to a 3–5 day delay, which clears the majority of short-term insufficient-funds situations without guessing at a specific payday.

None of this requires knowing an individual customer's actual payday — it requires picking a sensible default and refining it against your own R01 retry-success data over time, which is exactly the kind of decline-code-aware logic a payment recovery tool like Revova applies automatically instead of retrying every failure on the same fixed schedule.

For the full recovery playbook across every processor and payment type, see our guide on how to recover failed payments, or compare tools that automate the whole process in our roundup of the best payment recovery tools. If involuntary churn from failed payments — card or ACH — is a recurring problem, our involuntary churn benchmarks by industry piece shows how your failure rate compares.

Where to find the return code in your processor

Processors that support ACH — Stripe, GoCardless, Braintree, and others — pass the raw R-code through with minimal translation, since it comes directly from the RDFi. In Stripe, check the failed charge or PaymentIntent's decline detail; in GoCardless, the payment's events feed carries a reason_code. NACHA publishes the authoritative list of return codes and their exact definitions in its Operating Rules.

If you ever work with a raw NACHA return file directly — rare, but it happens with some bank integrations — the code lives in an Addenda99 record attached to the returned entry, in a field literally called ReturnCode, alongside the original entry's trace number so you can match the return back to the debit that triggered it. Your processor is almost certainly doing that matching for you already, but it helps to know the code did not appear out of nowhere — it travelled inside a specific, standardized record the whole way back.

Frequently asked questions