ACH return codes explained: R01, R02, R03, R04, R10 and R29

What an ACH return code actually is

When you originate an ACH debit, your bank (the ODFI) sends it through the network to the customer's bank (the RDFI). If the RDFI can't or won't post it, it sends the entry back with a return reason code — "R" plus two digits, defined in the Nacha Operating Rules. The code is the RDFI's explanation. Your job is to read it, fix the underlying cause, and — critically — not re-present entries you're not allowed to.

Return codes matter beyond the individual payment because Nacha and your ODFI track your return rates. Exceed the thresholds and you'll get a call from your bank's ACH risk team, a remediation plan, and possibly the loss of origination privileges. We cover the math in How to reduce ACH return rates.

The ACH return codes you'll actually see

Return windows are the Nacha standard timeframes; the RDFI must transmit the return so it is available to the ODFI by the deadline. Always confirm against the current Nacha Operating Rules.

Funds problems: R01 and R09

R01 — Insufficient funds is the most common return code in the network. The account exists and the debit was authorized; the customer just didn't have the money. R09 — Uncollected funds is its cousin: the balance shows enough, but part of it is a recent deposit that hasn't finished clearing.

You can't validate a balance before origination, but you can score the risk. A payer with a brand-new account, a history of returns, or an amount out of pattern is more likely to bounce. Both R01 and R09 may be re-presented up to two more times within 180 days of the original settlement — which is why many originators automatically retry a few days after payday.

Account data problems: R02, R03, R04, R13, R20

These are the returns that should make you wince, because almost all of them were preventable before the file went out.

• R04 — Invalid account number structure. The account number is the wrong length or format for that bank. This is pure data-entry error or fraud, and a format check would have caught it.
• R03 — No account / unable to locate. The number is structurally fine, but the bank has no such account, or the name on the entry doesn't match. Typos, transposed digits, or a made-up account.
• R02 — Account closed. The account used to exist. Common with recurring debits when the customer changes banks and forgets to update you.
• R13 — Invalid routing number. The routing number doesn't correspond to a participating institution. There is no excuse for this one; routing validation against the FedACH directory is instant.
• R20 — Non-transaction account. The account exists but can't accept ACH debits (some savings or loan accounts).

Nacha counts R02, R03 and R04 as administrative returns with a threshold of 3%. Since March 2021, Nacha's WEB Debit Account Validation Rule also requires originators of internet-initiated debits to use a "commercially reasonable" method to validate the account number the first time it's used — which is exactly the check that prevents R03 and R04.

Authorization problems: R05, R07, R10, R11, R29

These are the returns regulators and your ODFI care about most, because they mean a customer says you took money you weren't entitled to. Nacha's unauthorized return rate threshold is just 0.5%, and consumers have 60 calendar days to dispute.

• R10 — Customer advises originator not known / not authorized. Since the 2021 rule change, R10 means the customer says they have no relationship with you or never authorized any debit. This is the code you see with identity fraud and account takeover.
• R11 — Entry not in accordance with terms of authorization. The customer did authorize you, but the amount, date or frequency is wrong. Unlike R10, an R11 can be corrected and re-presented within 60 days.
• R07 — Authorization revoked. The customer cancelled a recurring authorization and you debited anyway. Honor cancellations the day you receive them.
• R05 — Unauthorized debit to a consumer account using a corporate SEC code. You coded a consumer debit as CCD or CTX. Get your SEC codes right.
• R29 — Corporate customer advises not authorized. The business version of R10, with a two-banking-day window instead of 60 days.

Preventing authorization returns is about two things: verifying the identity of the person giving you authorization (so a fraudster can't sign up with someone else's account), and keeping clean, retrievable authorization records so you can respond to disputes.

Other codes worth knowing

• R08 — Payment stopped. The customer placed a stop payment on the specific entry. Contact them before doing anything else.
• R16 — Account frozen. The account is frozen by legal action or, notably, an OFAC match. If you're seeing R16s tied to sanctions, you should be screening payers against OFAC before origination — it's a compliance obligation, not just a returns issue.
• R23 — Credit entry refused by receiver. Only applies to credits; the receiver declined the payment.
• R24 — Duplicate entry. You sent the same entry twice. Fix your file generation.

Which returns you can stop before the file goes out

Look at the "preventable" column above. Every administrative return and most unauthorized returns trace back to something you could have checked at enrollment: is this a real routing number, is the account number structurally valid, does this person exist and are they who they say they are, and are they on a sanctions list. That's the job of pre-submission verification — the same routing validation, fraud scoring, OFAC screening and ID matching that catches bad paper checks, applied to your ACH file before origination.

Frequently asked questions

Check EFI TeamWe build AI check and ACH verification software for check cashing stores, ACH originators and payment processors. Talk to us about your workflow.