An ACH payment you sent — or one someone sent you — bounced back with a code like R01 attached,
and now you need to know what it means and whether it's fixable. Return codes are a separate
system from the transaction codes inside an outbound NACHA file (covered in
What is a NACHA file?): they're assigned by the receiving
bank (the RDFI) when it sends an entry back instead of posting it, and they show up as an addenda
record on a return entry in the file your bank sends you back.
How a return works
When an RDFI can't or won't post an entry, it originates a return entry back through the ACH
network, generally within two banking days for most reasons. That return entry carries an
addenda record (type code 99) whose payment-related information starts with the three-character
return reason code — R01, R02, and so on — followed by the original trace number so you can
match it back to the entry you sent.
Common return codes
- R01 — Insufficient Funds. The account didn't have enough money to cover a debit at the time of settlement. The most common return by far for consumer debits; often resolved by retrying once (NACHA rules allow up to two retries for R01/R09 within 180 days).
- R02 — Account Closed. The account existed but has since been closed. Update your records — retrying won't help.
- R03 — No Account / Unable to Locate Account. The account number doesn't match any account at that routing number, or the name doesn't match closely enough. Verify the account and routing number with the receiver directly.
- R04 — Invalid Account Number Structure. The account number fails the RDFI's own format check (wrong length, invalid characters). A data-entry error on origination, not a bank-side problem.
- R05 — Unauthorized Debit to Consumer Account Using Corporate SEC Code. A consumer account was debited with a business-oriented SEC code (like CCD) instead of a consumer one (like PPD or WEB) without proper authorization. Fix the SEC code and re-authorize.
- R06 — Returned per ODFI's Request. Your own bank (the originating bank) asked for the entry to be returned — usually because it was sent in error on your side.
- R07 — Authorization Revoked by Customer. The receiver told their bank they'd previously authorized this debit but have since revoked that authorization. Stop originating further debits to this account until you get a new authorization.
- R08 — Payment Stopped. The receiver placed a stop payment on this specific entry.
- R09 — Uncollected Funds. Similar to R01, but the account has sufficient available balance that isn't yet collected (e.g. a large deposit still clearing).
- R10 — Customer Advises Not Authorized. The account holder says they never authorized this debit at all — distinct from R07 (which acknowledges a prior authorization existed). This one carries compliance weight: repeated R10s against the same originator can trigger network monitoring.
- R16 — Account Frozen. The account is frozen by court order, the bank itself, or another legal restriction.
- R20 — Non-Transaction Account. The account can't accept ACH transactions at all (some savings, loan, or investment account types).
- R23 — Credit Entry Refused by Receiver. Less common: the receiver's bank actively refused an incoming credit — for example, the account holder doesn't want the deposit for a specific reason.
- R24 — Duplicate Entry. The RDFI detected this exact entry was already posted once (same amount, same trace number pattern), and returned the duplicate.
- R29 — Corporate Customer Advises Not Authorized. The business version of R10 — a corporate/CCD-type account holder disputes authorization.
What to actually do with one
- Match the trace number in the return's addenda back to your original entry detail record to identify exactly which payment bounced.
- Check whether it's retryable. R01 and R09 explicitly allow limited retries; most other codes (R02, R03, R04, R16, R20) mean the account/routing data itself is wrong and retrying the same entry will just bounce again.
- Treat R07, R10, and R29 as compliance signals, not just failed payments — they mean the account holder is actively disputing authorization, and continuing to debit that account without a fresh authorization risks a NACHA rules violation.
- Update your records for anything indicating the account is gone or invalid (R02, R03, R04, R16, R20) before you originate against it again.
If you're staring at the raw returned file rather than a summary someone gave you, the free NACHA Viewer parses the whole batch structure — including the addenda records that carry these return codes — and exports it to a spreadsheet you can actually filter and sort.