ACH Recovery Framework
A practical guide to recovering failed ACH payments and staying within NACHA limits.
When an ACH payment fails, many teams don’t retry or retry it once and move on. Some of those payments are recoverable and some are not. Treating them the same way leaves money on the table and can create compliance problems. This guide is the framework I use to work through them.
What this guide covers
This guide is about recurring consumer ACH debits: the payments you collect on a schedule that sometimes fail. It does not cover one-off transfers, person-to-person payments like Zelle or Venmo, or cards, which are a separate rail. B2B and corporate debits follow the same logic with a few different codes, and I note those where they matter.
Request your numbers
If you want to see where your money is going and what you can win back, reach out for an audit:
The framework
There are six steps, and they run in order. The first two prevent failures, the next three recover the money when failures happen, and the last one keeps the whole thing under control.
Authorize transaction. Get clean, provable consent.
Verify bank account. Validate the bank account before you debit it.
Classify refusal codes. Read the return code to understand what happened.
Retry payments. Re-collect the failures that can be recovered.
Adjust billing logic. Act on what the codes are telling you.
Monitor results. Watch your return rates over time.
1. Authorize transaction
Authorization is where most ACH problems are either prevented or created. Authorization is when customer gives a permission to charge their bank account. A weak authorization usually comes back later as an R10 (the customer says they did not authorize the payment). This is the return you most want to avoid, because it counts against the 0.5% unauthorized threshold from NACHA and signals a compliance or fraud problem.
Clean authorization means a few things:
Clear consent. The customer takes an explicit action.
The right terms. You capture the amount or how it is calculated, the frequency, and how to cancel.
A recognizable payment descriptor. The customer should recognize the charge on their statement.
A record on file. NACHA expects you to be able to store the authorization action for audit purposes.
Following these authorization practices help preventing most of the disputes on a first place.
2. Verify bank account
A large share of payment failures usually come from bad account details captured at signup. These show up as R02 (account closed), R03 (no account), and R04 (invalid number). NACHA’s rules already require a reasonable account-validation method for first use, so this is worth doing regardless.
Here are the common options, from strongest to weakest:
Instant verification (Plaid-style verification). Confirms the account is real and owned, often with a balance signal. Often it is the best experience and the lowest failure rate, for a small cost per check.
Validation services (Early Warning). Check account status and ownership. A good fit for manual pf flows with sales assisted flows.
Micro-deposits. Confirms the account is active, this process often take a couple of days.
On Plaid-style versus raw account entry: a linked account fails much less than a hand-keyed routing and account number. There are no typos, the account is confirmed open, and the balance signal helps avoid R01. If you collect raw numbers with no check, your return rate will be usually higher.
3. Classify refusal codes
Classify means sorting each failed payment by its return code, so you know what to do with it. When a debit fails, the bank sends back a return code that explains why. That code is the difference between a payment you can recover and one you should stop chasing, so it is worth capturing and reading every one.
To do this well, make sure you record the return code for every failed payment. The codes come back in the ACH return files from your processor or bank. Group them into a few buckets and watch the mix over time. A lot of one code usually points to a specific problem. For example, a lot large number of R01 is about timing or affordability. Codes R03 and R04 is about bad data captured at signup. R10 is about authorization.
Here are the codes that come up most often, grouped by what they mean.
Funds usually recoverable
R01 insufficient funds. The account is open but does not have enough money right now. This is the most common return.
R09 uncollected funds. The money is in the account but not yet available, often because a recent deposit has not cleared.
Incorrect Account Number
R03 no account or unable to locate. The account number does not match an open account.
R04 invalid account number. The number is structurally wrong, usually a typo.
R20 non-transaction account. The account is not set up to be debited, for example a savings or loan account with restrictions.
Account closed or blocked, no longer usable
R02 account closed. The account no longer exists.
R16 account frozen. There is a hold or block on the account.
Stopped by the customer
R08 payment stopped. The customer placed a stop payment on the debit.
Authorization, the ones that count against the 0.5% limit
R10 not authorized. The customer says they never authorized the payment.
R07 authorization revoked. The customer authorized it before but has since cancelled.
R05 unauthorized, wrong code used. A consumer account was debited with a corporate code.
R11 not in line with the terms. There was an authorization, but something did not match it, such as the amount or the date. This one is usually fixable.
R29 corporate not authorized. The corporate version of R10.
If you want to see decline codes classified for your business – request an audit
4. Retry payments
For insufficient or uncollected funds (R01 and R09), NACHA lets you reinitiate a returned debit up to two times within 180 days of the original settlement. That is three attempts in total.
Other return reasons are not really retries. They need a fix first, such as a corrected account or fresh authorization, and then a new entry. Unauthorized returns should never be retried.
Most recoverable failures are about timing, so retry when money is likely to be in the account:
Line up with pay cycles. The 1st, the 15th, and the end of the month are good targets when customer receive their pay check.
Use escalating gaps. Wait a few days, then a bit longer, instead of hitting the account repeatedly. Think about retry and timing logic that works for your business vertical.
Do not retry the same day. It wastes one of your two attempts.
If done well, around one in four of these failures will come back.
5. Adjust billing logic
Retrying only recovers the funds returns. Everything else needs a different action, and the return code tells you which one. This is where you adjust how you collect based on what came back.
Account not found (R03, R04, R20). The account details are wrong, so there is nothing to retry. Go back to the customer and ask them to re-enter or re-link their bank account. The important part is to send the new details through account verification this time, the same Plaid-style check or validation service, so you confirm the account is real before you debit it again.
Closed or blocked account (R02, R16). The account is gone or frozen and will not come back. Ask the customer for a different account, or move them to another method such as a card on file.
Unauthorized (R10, R07, R05, R29). Stop charging that account right away and do not retry. These are the most damaging returns, because they count against the 0.5% limit and can point to fraud. Reach out to the customer, find out what happened, and get a fresh authorization before charging again.
Stopped payment (R08). The customer told their bank to stop the debit. Contact them to understand why before doing anything else. Retrying around a stop payment is a quick way to lose the customer and raise your return rate.
6. Monitor results
NACHA sets return-rate levels that get your payment provider or bank attention. You want to stay under the thresholds:
Unauthorized: 0.5%. Covers R05, R07, R10, R11, and R29. This is the one that causes trouble fastest.
Administrative: 3%. Covers R02, R03, and R04.
Overall: 15%. Covers all returns.
If you cross these, your payment provider is obligated to look into it, and a sustained problem can cost you the ability to originate ACH at all. It helps to track rates by code and by customer segment, so you can see where they are coming from, and to watch the trend rather than a single number.
Bottom line
Most failed ACH payments fall into a small number of categories, and each one has a clear next step. If you authorize cleanly, verify accounts up front, read the return codes, retry the ones worth retrying, act on the rest, and keep an eye on your rates, you will recover more revenue and stay well inside NACHA’s limits.
If you want this run on your own data, I can do a free ACH recovery audit and show you where your money is going, what is recoverable, and where your return rates sit. You can book a short call, or just reply.
If you want to see your numbers, request an audit: