ACH return codes are the standardized two-character labels (an “R” followed by two digits) that a receiving bank sends back when an ACH payment fails, and each one tells you exactly why the transaction bounced and whether you’re allowed to try again. The codes are set by Nacha, the organization that governs the ACH network. Only two of them — R01 and R09 — let you resubmit without getting fresh authorization from the customer. Every other code requires you to either collect corrected information, obtain new written authorization, or stop attempting the payment entirely.
Treating a return code as a generic “payment failed” message is how businesses end up violating Nacha rules and getting flagged by their originating bank. The code dictates the response.
The Only Two Codes You Can Retry
R01 means insufficient funds. The account exists and is in good standing, but the balance wasn’t enough to cover the debit when the bank processed it. This is the most common return code, and it often reflects timing rather than inability to pay — the customer may have been caught between paychecks or before a deposit cleared.
R09 means uncollected funds. The ledger balance looked sufficient, but part of it was tied up in items like recently deposited checks that hadn’t fully cleared. The bank won’t release those funds until collection is complete.
For both codes, Nacha allows up to two additional attempts after the original failed entry, and both retries must occur within 180 calendar days of the original settlement date. No new authorization from the customer is needed. If possible, align the retry with the customer’s known pay schedule so you don’t burn an attempt on another bounce.
Account and Data Error Codes
R02 means the account is closed. The bank has deactivated it and will not process any credits or debits on that number. You need the customer’s new banking details before you can collect.
R03 means the bank couldn’t locate the account. The account number or routing number doesn’t match anything in the receiving bank’s system. This often results from a typo, though it can also happen when an account has been purged from the bank’s records.
R04 means the account number is invalid — the digit string doesn’t conform to the bank’s numbering format or fails its internal check-digit verification. The distinction between R03 and R04 is subtle: R03 means the number is structurally valid but points to nothing, while R04 means the number itself is malformed.
None of these three can be retried as-is. You need corrected banking information from the customer, confirmed through a voided check or a bank-issued verification letter, and then you re-originate the transaction as a new entry rather than a retry.
Unauthorized Transaction Codes
These are the most serious codes in the system. Receiving too many of them can get your business flagged or terminated by your bank, and resubmitting any of them without fresh written authorization is itself a Nacha rule violation.
R05 means a business debited a consumer’s personal account using a corporate (CCD) transaction format without proper authorization. The consumer never agreed to have funds pulled under that transaction type, so the receiving bank rejects it as unauthorized.
R07 means the customer has permanently revoked their authorization. Unlike a one-time stop payment, R07 terminates the underlying payment agreement. Any further debit attempts without new signed authorization would violate Nacha rules.
R10 is the broader unauthorized code: the account holder has told their bank that the originator either isn’t known to them or was never authorized to debit the account. Nacha defines this as covering situations where the receiver has no relationship with the originator, doesn’t recognize who initiated the transaction, or disputes the authenticity of a signature on the source document.1Nacha. Differentiating Unauthorized Return Reasons
R29 is the corporate counterpart to R10. Same meaning — the account holder says the transaction wasn’t authorized — but applied to business accounts rather than consumer accounts. Stop any recurring transactions for that company immediately and contact them directly.
For all four of these codes, do not resubmit. Contact the customer, understand why the authorization was disputed, and obtain new written authorization before originating anything new. If the customer genuinely didn’t authorize the original transaction, the matter needs further investigation on your end.
Stop Payments and Restricted Accounts
R08 is a stop payment on a specific transaction. The account holder contacted their bank and asked it to block that particular payment. Under Regulation E, consumers can stop a preauthorized electronic transfer by notifying their bank at least three business days before the scheduled payment date, and the bank may require written confirmation within 14 days of an oral request.2eCFR. 12 CFR 1005.10 – Preauthorized Transfers R08 applies to one transaction and doesn’t automatically mean the customer wants to end the whole payment relationship, but confirm before sending another debit.
R16 means the account is frozen, usually because of a court order, tax levy, or the bank’s own fraud investigation. The bank legally cannot release funds until the restriction is lifted. There’s nothing for you to fix; wait or arrange an alternative payment method.
R20 identifies a non-transaction account, such as certain savings vehicles that federal regulations restrict from routine third-party debits. The account exists and may have funds, but its type prohibits the transfer you attempted. Ask the customer for a different account, typically a checking account.
What Counts as a Retry, and What Counts as a New Entry
A retry under Nacha rules is a resubmission of the original failed transaction, permitted only for R01 and R09, capped at two additional attempts, and bounded by the 180-day window from the original settlement date. No new authorization is required because the original authorization still stands.
Everything else is a new origination. When you collect corrected banking information after an R02, R03, or R04, the next debit isn’t a retry — it’s a fresh entry, and you’ll want the customer’s authorization on file to cover the new account information. When you obtain renewed written authorization after an R07 or R10, same thing: the next debit is a new transaction built on new authorization, not a resubmission of the old one.
The reason this distinction matters: a true retry on a code that doesn’t allow one counts toward your unauthorized return rate, and that number is tracked.
Return Rate Thresholds That Can End Your ACH Access
Nacha monitors two return rate metrics. The unauthorized return rate threshold is 0.5%, and the overall return rate threshold is 15%.3Nacha. NACHA Operating Rules Improving ACH Network Quality
If your unauthorized return rate crosses 0.5%, your originating bank is required to contact you, investigate the cause, work with you to bring the rate down, and — if you don’t improve — terminate your ability to originate ACH entries. That cuts off your access to the network. The overall return rate threshold carries similar contact-and-remediation obligations, though termination isn’t explicitly required at 15%.
Even a small number of unauthorized returns can push a low-volume originator over the 0.5% line. If you run recurring billing, track return rates monthly and treat any unauthorized return as an immediate flag.
How to Correct and Resubmit a Failed ACH Payment
Pull the return notification from your payment processor or banking portal and confirm the exact code. The code determines everything that follows.
For R01 or R09, resubmit through your processing software without collecting new information. The system creates a new entry with a fresh trace number, linked to the original for audit purposes. Watch your retry count and your 180-day window.
For R02, R03, or R04, request updated banking information directly from the customer. A voided check or a bank-issued account verification letter confirms the correct routing and account numbers. Enter the corrected transaction as a new origination with authorization covering the new account.
For R05, R07, R10, or R29, do not resubmit. Reach out to the customer, resolve the dispute, and get new written authorization before originating anything further. For R08, confirm with the customer whether the stop applied only to that one payment or signals a broader change. For R16 and R20, you’re waiting on the customer or the account situation; there’s no data fix on your side.
Most processors charge a fee per return, typically in the range of $2 to $15. These add up with poor account data, which is another reason to validate banking information upfront. Once a corrected or new transaction is submitted, settlement generally takes one to three business days. Flag any transaction that fails a second time for manual review rather than letting your software burn the last retry attempt automatically.