What Is an ACH Return?
When you originate an ACH payment — whether it is a vendor payment, a contractor payment, or any other ACH debit or credit — the receiving bank has up to two banking days to return it if something is wrong. When that happens, you get back a return entry with a three-character code explaining why.
These codes follow a standard defined by NACHA, so they mean the same thing regardless of which bank processed the transaction. Learning what the most common codes mean (and what to do about each one) will save your AP team a lot of time and confusion.
How the Return Process Works
Here is the basic timeline:
- You originate a payment and send the NACHA file to your bank (the ODFI — Originating Depository Financial Institution).
- Your bank forwards the payment through the ACH network to the receiving bank (the RDFI — Receiving Depository Financial Institution).
- The receiving bank has two banking days to return the entry if there is a problem. For unauthorized debits, the window can be up to 60 calendar days.
- Your bank passes the return back to you as a return file, typically in the same NACHA format as your original submission.
- You review the return code, fix the underlying issue, and decide whether to re-originate.
Returns are not instant. If you sent a file on Monday, you may not see returns until Wednesday or Thursday. Build that lag into your reconciliation process.
The Most Common ACH Return Codes
R01 — Insufficient Funds
What it means: The receiver's account does not have enough money to cover the debit.
What to do: Wait and re-present the payment, or contact the receiver to arrange a different payment date. NACHA rules allow you to re-present an NSF return up to two additional times. If it returns a third time, stop re-presenting and contact the payee directly.
R02 — Account Closed
What it means: The account existed but has been closed by the account holder or the bank.
What to do: Contact the receiver and get updated banking information. Do not re-originate to a closed account — it will just return again. Update your records before sending the next payment.
R03 — No Account / Unable to Locate Account
What it means: The account number does not match any account at the receiving bank. This is usually a typo in the account number.
What to do: Double-check the account and routing numbers with the receiver. A single transposed digit causes this. Once you have confirmed the correct numbers, originate a new entry.
R04 — Invalid Account Number Structure
What it means: The account number is formatted incorrectly — the wrong length or contains invalid characters. The receiving bank did not even attempt to find a matching account.
What to do: Ask the receiver to confirm their exact account number. This is almost always a data entry issue. Validate account number formats before you submit the file.
R05 — Unauthorized Debit to Consumer Account Using Corporate SEC Code
What it means: You used a corporate ACH entry type (CCD or CTX) to debit a personal consumer account. NACHA requires consumer debits to use a consumer SEC code (PPD or WEB) and to have proper authorization.
What to do: Check whether the account is actually a consumer account, not a business account. If it is consumer, change the SEC code to PPD and ensure you have a signed ACH authorization on file before re-originating.
R06 — Returned Per ODFI Request
What it means: Your own bank (the ODFI) requested the return. This usually happens because you contacted your bank and asked them to reverse or recall a payment — for example, if you sent a duplicate or sent money to the wrong account.
What to do: This one is in your control. If your bank returned it on your request, confirm the situation is resolved and originate the correct payment if needed.
R07 — Authorization Revoked by Customer
What it means: The account holder previously authorized the debit but has since revoked that authorization, and the receiving bank acted on their request.
What to do: Stop debiting this account immediately. Continuing to debit after authorization has been revoked is a NACHA compliance violation. Reach out to the customer to understand why they revoked authorization and resolve the underlying issue.
R08 — Payment Stopped
What it means: The account holder placed a stop payment on the specific transaction. This is different from R07 (revoked authorization) — it is a one-time stop on a single payment rather than a revocation of the entire authorization.
What to do: Contact the receiver to understand why they stopped the payment. If it was a mistake on their end, they can lift the stop payment. If there is a dispute, resolve it before re-originating.
R10 — Customer Advises Not Authorized
What it means: The account holder told their bank they never authorized the debit at all. This is a serious return — it means your authorization is in question.
What to do: Pull your authorization documentation immediately. You may need to provide proof of authorization to your bank. If you cannot demonstrate that the debit was authorized, do not re-originate. Review your authorization processes to make sure you are capturing and retaining proper ACH authorizations.
R29 — Corporate Customer Advises Not Authorized
What it means: The business account holder (not a consumer) told their bank the debit was not authorized. The business equivalent of R10.
What to do: Same approach as R10 — pull your authorization records. For business-to-business ACH, make sure you have a signed ACH debit authorization agreement on file with the vendor or partner before originating debits.
A Few Things Worth Knowing About Returns
Returns affect your standing with your bank. If your return rate stays consistently high — especially for unauthorized returns (R05, R07, R10, R29) — your bank may restrict your ACH origination privileges. NACHA's published thresholds are 15% overall returns and 0.5% unauthorized returns. Staying well under those limits is good practice.
Not all returns are your fault. R01 (insufficient funds) and R08 (stop payment) are outside your control. R03 and R04 are usually fixable data problems. R10 and R29 are the ones that demand immediate attention.
Keep records. Maintain logs of return codes along with the corrective actions you took. If your bank ever asks you to explain a return spike, having clean records makes that conversation much easier.
How FiSTWorks Helps with Returns
When your bank sends back a return file, FiSTWorks can parse it and surface the return codes alongside the original transaction details — so you are not manually cross-referencing a raw NACHA file. You can see at a glance which payments came back, why they came back, and which ones need immediate action.
That said, no software eliminates returns entirely. The best defense is clean data going in: verified routing and account numbers, proper SEC codes, and solid authorization practices.
Next Steps
If your team is spending too much time hunting down return codes and manually managing ACH files, there is a better way. FiSTWorks handles the file creation, validation, and transmission — and brings returns into the same workflow so nothing slips through the cracks.