This article was written by the payments nerds at Aeropay. Our goal is to provide you with solid insights to help your business operationalize more efficient, value-focused payments.
Recover a failed bank payment by reading its return code first, because the code decides whether you are allowed to try again. Under Nacha's rules for US ACH payments, a merchant may retry a debit returned for insufficient or uncollected funds (R01 or R09) up to two more times within 180 days of the original settlement. Closed accounts, wrong account numbers and disputed debits are not retried; they need new details, a corrected payment or a new authorization.
That split matters because most recovery work goes wrong in one of two ways. Merchants retry a payment that the rules do not allow them to retry, or they retry an allowed payment at a moment when the account is still empty.
Each return code points to one recovery step, so sort failed payments by code before anyone touches them. The bank that returns the payment attaches the code, and your provider passes it to you with the return.
| Return code | What it means | Can you retry it? | Recovery step |
|---|---|---|---|
| R01 | Insufficient funds | Yes, up to two more times within 180 days | Retry after the customer's next deposit lands |
| R09 | Uncollected funds (a deposit has not cleared) | Yes, same limit as R01 | Retry once the deposit clears |
| R02 | Account closed | No | Ask the customer for a new account and a new authorization |
| R03 | No account, or the bank can't locate it | No; send a corrected payment | Get the right details; the corrected payment counts as a first attempt |
| R04 | Invalid account number | No; send a corrected payment | Same as R03 |
| R10 | Customer says they never authorized the debit | No | Contact the customer and collect a new authorization before debiting again |
| R11 | Debit didn't match the authorization, such as the wrong amount or date | No; send a corrected payment | Fix the error and send a new payment within 60 days of the return, with no new authorization needed |
Code definitions come from EPCOR's return reason code resource and Nacha's rule on differentiating unauthorized return reasons. A corrected R03 or R04 payment counts as a new first presentment under a Nacha rules clarification, so it does not use up a retry.
Twice, and only for insufficient or uncollected funds. Nacha allows a debit returned as R01 or R09 to be reinitiated a maximum of two times within 180 days of the original settlement date, which gives a merchant three attempts in total.
A retry has to look like the original payment. The company name, company ID and amount stay identical, and the batch carries the description "RETRY PYMT" so the customer's bank can see it is a permitted resubmission, under Nacha's reinitiation rule. Splitting the amount into smaller debits or changing the description to get around the limit is an improper reinitiation, which the customer's bank can return as unauthorized (R11).
Three attempts sounds generous until you count them against a subscription cycle. A monthly biller that retries the day after a return, then again the day after that, burns both retries in one week while the account is still empty.
Retry after the customer's next deposit lands. A fixed one-day or three-day timer ignores whether the money is there, and an R01 return only tells you the balance was short on the day the debit posted.
Two inputs decide the right moment. The first is the customer's pay cycle: deposit history shows whether they are paid weekly, every two weeks or monthly, so the retry lands just after payday. The second is a live balance check right before the retry goes out, which confirms the funds are there before you spend an attempt.
We built smart retries into Aeropay Guard, our risk engine for bank payments, around that second input. Aeropay Guard retries a failed payment automatically once real-time signals show the funds are available, which separates a timing problem from a real decline. Every retry still counts against Nacha's two-attempt limit, so when it goes out matters more than how often.
Bill from a bank account and set every collection to the customer's payday. Linked bank accounts don't expire or get reissued like cards, so recurring payments keep running without new payment details, and the failures that remain are mostly insufficient funds.
Insufficient funds on a subscription is usually a calendar problem. A billing date that lands two days before payday fails every cycle, so move the billing date rather than the retry: deposit history shows whether each customer is paid weekly, every two weeks or monthly. Our guide to recurring ACH payments covers how the billing schedule itself is set up.
When an R01 comes back anyway, hold the retry until the next deposit lands instead of sending it on the billing timer. Each of the two attempts Nacha allows then lands on an account with money in it.
Go back to the customer, because no retry will reach an account that is closed or does not exist. R02, R03 and R04 returns all mean the payment details are bad, and only the customer can supply good ones.
For a closed account (R02), you need a new account and a new authorization, since the customer's permission was tied to the old account. For a wrong or invalid number (R03, R04), you need the corrected details, and the corrected payment goes out as a new first attempt.
These returns carry a cost beyond the lost payment. Nacha caps administrative returns (R02, R03 and R04 together) at 3.0% of a merchant's debits, and a merchant over that level faces a Nacha inquiry through its bank. The way to recover fewer of them is to stop them at signup by verifying the account when the customer connects it, which our guide to stopping failed bank payments covers.
Not by retrying it. The next step depends on whether the bank returned it as R10 or R11, because Nacha treats the two differently.
An R10 return means the customer says they never authorized the debit. Contact the customer, find out whether the dispute is a mistake, a misunderstanding about billing terms or real fraud, and collect a fresh authorization before you debit the account again.
An R11 return means the authorization stands but the debit broke its terms, such as the wrong amount or an earlier date than agreed. Nacha lets you correct the error and send a new payment within 60 days of the return's settlement date, without asking for a new authorization.
On consumer accounts, the customer's bank has 60 days from settlement to send either return back, so they arrive weeks after the money looked final. Both codes count toward Nacha's 0.5% unauthorized return threshold, far tighter than the 3.0% administrative limit, and a second debit that doesn't fix the cause adds another.
Move the return risk off your team before the return arrives. A provider guarantee means a covered return no longer costs you the payment, so your team only works the returns that fall outside it.
We cover eligible bank-initiated returns through Aeropay Guaranteed ACH, across 50+ return types including insufficient funds, up to the merchant's agreed coverage limit. Payments on Aeropay's Trusted User Program, which moves proven customers onto a lower-cost payment path, sit outside the guarantee, so the merchant carries their return risk. A recovery process built on the return codes above still earns its keep for those payments.
The other lever is the decline itself. Ask your provider for a specific reason code on every rejected payment, because a balance-related reason tells your team to wait for funds while a risk-related reason tells them to go back to the customer.
Shortlist providers that time retries to live balance signals instead of a fixed timer. Ask each one whether it retries only R01 and R09 returns, stays inside Nacha's two-retry limit and checks the balance before every attempt. Aeropay Guard is one example: it retries a failed payment once real-time signals show the funds are available.
A decline happens before any money moves, when the provider or its risk engine refuses the payment. A return happens after the debit is sent, when the customer's bank sends it back with a return code. Only returns count toward Nacha's return rate thresholds.
180 days from the original settlement date for an R01 or R09 retry. A corrected payment after an R11 return runs on a shorter clock: it must go out within 60 days of the return's settlement date. Nacha does not allow a retry after the 180-day window closes.
Yes. A retry that comes back is a new return, and every return counts toward Nacha's 15.0% overall return rate threshold. A retry sent while the account is still empty raises your return rate instead of recovering the payment.
See how Aeropay Guard times retries to when your customers' funds land. Talk with our team
