ACH Return CodesWhat Each Code Actually Means, Why NACHA Enforces Them as Strictly as it Does, & How to Keep Your Return Rate Where it Ought to be

What ACH Return Codes Are & Why They Exist

ACH is one of those bits of payments infrastructure that quietly underpins a remarkable amount of day-to-day economic activity while remaining mostly invisible to the people relying on it. The direct deposit of a paycheck; the utility bill paid from a checking account; the subscription debit that lands on the same date each month — all of it moves through the Automated Clearing House network. It is, broadly speaking, a system that works.

Until, on occasion, it doesn’t.

An ACH transfer is, in essence, a coordinated handshake between two banks. The originating bank — called the “originating depository financial institution” or “ODFI” — initiates the transfer on the merchant’s behalf. The receiving depository financial institution (“RDFI”) accepts or declines the transfer for the customer’s account. When the RDFI cannot complete the transfer, for whatever reason, it sends a return back through the network, accompanied by an ACH return code that explains why the transfer failed.

The codes themselves aren’t arbitrary. NACHA, which governs the ACH network and writes the rules, designed the taxonomy so that every party in the chain — the merchant, the ODFI, the processor — can identify quickly what went wrong, and what (if anything) can be done about it. Some returns reflect customer-side issues the merchant could never have prevented. Others are entirely the merchant’s own doing. The point of the code, in practice, is to make that distinction visible.

What is an ACH Return Code?

ACH Return Codes

[noun]/ā • cē • eɪCH • rə • tərn • kōd/

An ACH return code is a 3-digit alphanumeric indicator attached to a returned ACH transaction. The code is meant to explain why an ACH transfer could not be processed.

Each return includes a three-character ACH return reason code that can point the recipient to additional details, and help explain why the return happened. There are over 80 unique return codes, and each one represents a different type of return.

ACH return codes are a type of shorthand for specific information concerning the return, much like the card decline codes or dispute reason codes used by credit card networks. All ACH return reason codes consist of the letter “R” followed by two numbers (R01, R12, R22, etc.). There are also specific return time frames, which can differ between codes.

ACH Return Code Limits

The number of ACH return codes you receive is limited. The general threshold is set at 15% of total ACH debits over a rolling 60 days. Exceeding this threshold doesn’t warrant a polite letter. It leads to mandatory monitoring, increased scrutiny from your bank, fines in some cases, and if matters don’t improve, suspension of your ACH origination privileges altogether.

Now, there is also a select subset of ACH return codes which have much stricter limits. Specifically, those related to unauthorized returns and data errors.

The Most Common ACH Return Codes Merchants See

There are more than 80 ACH return codes in the NACHA rulebook, but most merchants encounter the same handful repeatedly. The ones most worth knowing in detail are as follows:

R01  |  Insufficient Funds

The customer’s account hasn’t the money to cover the debit. This is, by some distance, the most common ACH return code, and one of the few that can be reinitiated; this is allowed up to two times after the original return.

For recurring billing, R01 returns often resolve themselves with a brief delay, giving the customer time to deposit funds. Balance-checking services, which confirm available funds before the debit is initiated, are worth considering for merchants seeing R01 volumes in any quantity.

R02  |  Account Closed

The account is no longer active. This one cannot be reinitiated to the same account; new payment information from the customer is required.

In recurring billing relationships, R02s often turn up because the customer switched banks without thinking to update their payment method. Periodic re-validation of accounts for long-tenured customers can catch these before they generate returns.

R03  |  No Account / Unable to Locate Account

The account number is structurally valid but doesn’t correspond to an open account at the named bank. This cannot be reinitiated without corrected information.

In practice, R03 almost always points to a data entry problem — a transposed digit, an outdated record. Account verification at enrolment catches the bulk of these before the first transaction is ever attempted.

R04  |  Invalid Account Number

The account number itself is malformed — wrong number of digits, invalid format. Not reinitiable without corrected information.

Validation at the point of data entry, including check-digit verification, prevents most R04s outright. Seeing them in any volume is generally a sign that the payment form is doing too little of the work it ought to be doing.

R05  |  Unauthorized Debit to Consumer Account

The consumer claims the debit wasn’t authorised. This one counts toward the 0.5% unauthorised threshold, so it carries weight even when it happens rarely.

R05s often trace back to unclear billing descriptors, forgotten subscriptions, or, occasionally, genuinely unauthorised activity. A review of authorisation practices is the appropriate response.

R07  |  Authorization Revoked by Customer

The customer authorised recurring debits at some point and has now revoked that authorisation. This also counts toward the unauthorised threshold.

The correct response is to stop debiting immediately. Continuing to attempt collection after an R07 doesn’t just create further returns; it creates compliance exposure. If you suspect the revocation was unintentional, contact the customer.

R08  |  Payment Stopped

The customer has placed a stop payment specifically on this transaction. Reinitiation requires fresh authorisation from the customer.

An R08 is, more often than not, a customer service signal in disguise. The customer stopped the payment for a reason; finding out what it was before attempting to collect again is generally time well spent.

R10  |  Customer Advises Not Authorized

The customer is saying they have no relationship with the originator or didn’t authorise the debit. Counts toward the unauthorised threshold, and warrants a careful look at your authorisation records.

R10s can indicate fraud, but they can equally indicate a billing descriptor that fails to identify your business in any recognisable way. Worth checking which one you’re dealing with before assuming the worst.

Everything You Need To Know A Beginner’s Guide to Chargebacks

Chargebacks can wreak havoc on your cash flow and profitability. This FREE paperback book is your guide for preventing chargebacks and, when they happen, fighting them more effectively.

Send Me My Free Paperback Book!

The Complete List of ACH Return Codes

The table below lists every ACH return code, its meaning, and the timeframe within which the return must be processed.

Payment card chargebacks can destroy your bottom line.

Talk to our experts and see how we can help.

Request a Demo

When You Can Retry a Failed ACH Payment (& When You Cannot)

Not every return can be retried. NACHA’s rules specify which codes permit reinitiation and how many attempts are allowed, and the rules are there for a reason: indiscriminate retries are exactly what the network is trying to discourage.

Returns That Can be Reinitiated

• R01 (Insufficient Funds): Up to two times after the original return. A short wait between attempts gives the customer’s account time to be funded.
• R09 (Uncollected Funds): Also reinitiable up to two times. The account has funds, but they aren’t yet cleared; a brief delay tends to resolve it.
• R08 (Payment Stopped): Only with new authorization from the customer. The previous authorization no longer holds.

Returns That Cannot be Reinitiated

• R02, R03, R04 (Account Issues): These require corrected account data. Retrying without it will produce the same result.
• R05, R07, R10 (Unauthorized): Do not retry. The customer is disputing the authorisation, and reinitiating will compound your unauthorised return rate and your compliance risk in roughly equal measure.

With most other ACH return codes, you need corrective action specific to the issue rather than a simple retry. In the case of code R16 (Account Frozen), for example, this can be retried only if the account in question is no longer frozen.

For R01s specifically, waiting at least three business days between attempts is sensible practice; contacting the customer directly to confirm funding, where feasible, is better still. For authorisation returns, the right move is not a retry but a conversation. For account data errors, get the corrected information first, then try again.

ACH Return Fees & the Real Cost of Failed Payments

The direct fees are the most visible cost of an ACH return, but they are rarely the most consequential one.

Direct Costs

Most processors charge $2 to $5 per return, though some sit closer to $10 to $15. The fee applies regardless of whether the return was driven by an empty account on the customer’s side or an invalid account number on yours. The original processing fee is also lost, and reinitiation generally costs again.

Indirect Costs

Less easy to quantify is the operational drag: the payment you’d planned on hasn’t arrived, your cash flow forecast is wrong by however much, and someone on the team is now investigating the return rather than doing something more productive. For recurring billing relationships, repeated failures strain the customer relationship in ways that don’t show up on any ledger.

The fee on any single return is, in the grand scheme of things, manageable. The threshold position is not. If the return rate drifts above NACHA’s limits, the merchant faces investigation, possible fines, and the genuine prospect of losing ACH origination privileges altogether. The ODFI carries the network’s risk for its sponsored merchants and will act accordingly when one of them becomes a liability. That is the cost worth taking seriously.

How ACH Returns Differ From Credit Card Chargebacks

Merchants sometimes treat ACH returns and credit card chargebacks as variations on the same theme. They are not; the two mechanisms sit on different networks, operate to different timelines, and offer the merchant very different forms of recourse.

ACH returns are faster and cheaper than chargebacks, which is the good news. The less good news is that there is no formal representment process to speak of. If the return stands, the merchant’s options for recovering the money are essentially outside the rails — collection from the customer through other channels.

Merchants can “dishonour” a return when the return itself was untimely, incorrect, misrouted, or a duplicate. Dishonouring is for returns that were procedurally improper, not for returns the merchant simply disagrees with. This must be done within five banking days of the return settlement date, though.

One further point worth making: ACH returns don’t feed into the card network monitoring programs — VAMP, SMMP, and the like — because ACH is a different network entirely. That isn’t, however, a free pass. NACHA’s own thresholds carry consequences that can be every bit as serious as the card networks’, and the merchant who treats ACH returns as the lesser cousin of chargebacks tends to find that out the hard way.

50 Insider Tips for Preventing More Chargebacks

In this exclusive guide, we outline the 50 most effective tools and strategies to reduce the overall number of chargebacks you receive.

Get the FREE guide

How to Prevent ACH Returns & Stay Below NACHA Thresholds

A meaningful proportion of ACH returns are preventable with reasonable verification, clear communication, and a degree of proactive account management. The work isn’t glamorous, but it does pay dividends. I recommend that you:

Patterns are worth investigating: returns concentrated in particular customer segments, transaction types, or time periods often point to a root cause that can actually be fixed.

ACH transfers can be a low-hassle way to send or receive money. For merchants, it is a viable alternative payment option that could make customers happy. Even with precautions in place, however, sometimes ACH payments will fail to go through.

As a merchant, you need to have a plan in place to accept payments when ACH transfers are not available. You also need to have a way of recovering funds lost if an ACH transfer goes wrong.

Talk to one of our experts today about developing a broader, more comprehensive solution for payments and risk mitigation.