ACH return codes: what each one means and what to do next

What an ACH return is

An ACH return is an entry that the receiving bank, the receiving depository financial institution (RDFI), sends back through the ACH Network. For a debit, that is the payer’s bank. It goes to the bank that sent the original entry, the originating depository financial institution (ODFI), with a return reason code such as R01 or R10. The code is how your platform learns what went wrong.

Returns follow the Nacha Operating Rules, the rules that govern the ACH Network. Nacha writes those rules; it is not a government regulator. Each code comes with a return window, which tells you how long a payment can still come back for that reason.

A return is not a chargeback. A chargeback is a card dispute that follows card network rules: Visa cardholders, for example, can generally dispute a transaction for up to 120 days, and up to 540 days in some cases. ACH returns follow Nacha rules and have their own, mostly shorter windows. Our guide to how chargebacks and ACH returns differ compares the two side by side.

A debit that has already settled between banks can still be returned, so the status your software shows for an ACH payment should allow for a return that arrives after settlement. If you need the basics first, start with how ACH payments move between bank accounts. If you are looking up a single code, the table of common ACH return codes comes next.

Common ACH return codes

The table lists 15 common codes, with the usual return window and a next step for each. Codes, titles and windows are as of October 2026; confirm them with your provider before you build return handling around them. A WSUD is a Written Statement of Unauthorized Debit from the account holder. The sections after the table explain the windows, retry limits and rate thresholds behind each step.

ACH return timeframes

As of October 2026, the Nacha rules set two main return windows, two banking days and 60 calendar days, and the code and the type of account decide which one applies.

• Two banking days for most returns. Most returns must reach the ODFI by the opening of business on the second banking day after the settlement date of the original entry. That covers codes such as R01, R02, R03, R04, R08, R16 and R20.
• 60 calendar days for unauthorized consumer debits. A debit to a consumer account can be returned as unauthorized for 60 calendar days after the settlement date, using R05, R07, R10 or R11 with a Written Statement of Unauthorized Debit (WSUD) from the account holder. The return must be made available to the ODFI by the opening of business on the banking day after the 60th calendar day.
• Two banking days for unauthorized business debits. When a business account holder says a debit was not authorized, its bank uses R29, and the two-banking-day window applies. The 60-day window does not extend to business accounts.

The consumer unauthorized codes are not interchangeable. The R10 return code means the consumer does not know the Originator or never authorized it. R11 means an authorization exists but the entry did not match it, for example a wrong amount or date. R07 means the consumer revoked the authorization, and R05 means a consumer account was debited using a business (corporate) SEC code.

Since October 1, 2024, a consumer may sign the WSUD on or after the date the entry is presented. The receiving bank must then send the return by the opening of the sixth banking day after it finishes reviewing the signed statement.

Do not mix up the 60 calendar days with Regulation E. Regulation E, a separate federal consumer rule, has its own 60-day period for reporting errors, counted from when the bank sends the statement. Nacha’s 60 days are counted from the entry’s settlement date. They are different clocks under different rules.

Funding and account codes: R01 to R04

Four codes cover money and account-data problems, and all four use the two-banking-day window:

• R01 Insufficient Funds: the account did not hold enough money to cover the debit.
• R02 Account Closed: the account existed but has been closed.
• R03 No Account/Unable to Locate Account: the receiving bank could not find the account.
• R04 Invalid Account Number Structure: the account number is not in a valid form.

They call for different responses. The R01 return code, like R09 (Uncollected Funds), is about money, so the same account may be debited again within the reinitiation limits described below. R02, R03 and R04 are about the account itself. Sending the same details again would only fail the same way, so your platform should ask the payer for corrected bank details. Nacha also counts R02, R03 and R04 toward the administrative return rate.

Take a monthly rent debit. Returned R01, it can be sent again within the limits; returned R02, it means the resident needs to add a new bank account before next month’s debit. See how this plays out in rent payments in property management software.

Proof of authorization

When a payer questions a debit, proof of authorization can be requested. Under the Nacha rules, the ODFI has 10 banking days to provide it. Since the Meaningful Modernization rules took effect on September 17, 2021, the ODFI may instead agree to accept the return.

That is why Originators must be able to produce proof of authorization quickly. If your software captures authorizations for your customers, store each one so it can be found and sent within days, not weeks.

The same rules set minimum standards for consumer debit authorizations: they must be readily identifiable and use clear and readily understandable terms. Our guide to ACH authorization requirements covers what to collect before you debit.

ACH return rate thresholds

Nacha also measures how often an Originator’s debits come back. As of October 2026, it sets one threshold and two review levels for debit returns:

• Unauthorized return rate, 0.5% threshold. It counts debits returned R05, R07, R10, R11, R29 and R51, measured over the preceding 60 days or two calendar months.
• Administrative return rate, 3.0% level. It counts returns coded R02, R03 and R04.
• Overall debit return rate, 15.0% level. It counts all debit returns, excluding RCK (re-presented check) entries.

The difference between a threshold and a level matters. Going over the 0.5% unauthorized threshold can trigger Nacha enforcement against the ODFI, which passes the obligation on to the Originator or Third-Party Sender. The 3.0% and 15.0% figures are not automatic violations. Going over one triggers a preliminary inquiry into the Originator’s or Third-Party Sender’s practices, which can lead to a directive to bring the rate down.

Two codes are easy to miss. An R29 return code from a business payer’s bank moves the unauthorized rate just as a consumer’s R10 does, and R11 counts too, even though the payer did authorize the debit.

The Unauthorized Entry Fee

Unauthorized returns also cost money. For each unauthorized return (the same six codes that count toward the 0.5% threshold), the ODFI pays the RDFI an Unauthorized Entry Fee, and the ODFI usually passes it on to the Originator or platform.

Nacha set the fee at $4.50 per return for returns settling on or after October 3, 2016, and added R11 returns on April 1, 2021. Confirm the current amount in the Nacha Operating Rules, and ask your provider whether it also charges its own return fee. Our guide to what ACH payments cost explains how return costs add up.

When you may send a returned debit again

Sending a returned debit again is called reinitiation, and the rules limit it closely. As of October 2026:

• Only R01 and R09 may be retried as they are. A debit returned for Insufficient Funds (R01) or Uncollected Funds (R09) may be reinitiated at most two times, within 180 days of the original settlement date.
• Mark the retry. A reinitiated entry carries RETRY PYMT in the Company Entry Description, and its Company Name, Company ID and Amount must stay the same as the original.
• Unauthorized returns need a new authorization. A debit returned as unauthorized may not be reinitiated unless the Originator gets a new authorization after the return.
• Stopped payments need one too. A debit returned R08 (Payment Stopped) needs a new authorization before it is sent again.

R11 has its own path. The payer did authorize the debit and only the entry was wrong, so the Originator may correct the error and send a corrected entry within 60 days of the settlement date of the R11 return, without a new authorization.

Tuition plans show why the same-amount rule matters. If a family’s monthly tuition debit comes back R01, your school software may retry the same amount up to twice, but it cannot add a late fee to the retried amount. If the family revoked the authorization instead (R07), the plan stops until they sign a new one. See how this works for tuition payments in school software.

R17 and suspected fraud

Since October 1, 2024, a receiving bank may use R17 with the descriptor QUESTIONABLE to return any entry it believes is fraudulent. Since January 1, 2026, it may do so before or after the entry posts. Using R17 this way is optional for the bank, and the return follows the two-banking-day window.

The same October 2024 rules let an ODFI ask the receiving bank to return an entry for any reason (R06). If your platform needs an entry pulled back, ask your provider; since April 1, 2025, the receiving bank must report the status of that request within 10 banking days.

Treat an R17 QUESTIONABLE return as a fraud signal, not a routine failure: pause further debits to that account and review how the payer and the account were added. For the wider picture, read what Nacha’s 2026 fraud monitoring rules ask of platforms.

R16 today, R90 from March 2028

As of October 2026, R16 is titled Account Frozen/Entry Returned per OFAC Instruction, so it covers both frozen accounts and sanctions returns. That changes on March 17, 2028.

From that date, sanctions-related returns get their own R90 return code (Entry Returned Due to RDFI’s Sanctions Compliance Obligations), and R16 goes back to meaning only Account Frozen. An R90 return must reach the ODFI by the opening of business on the second banking day after the receiving bank’s sanctions compliance determination.

If your software maps return codes to messages or next steps, add R90 before March 17, 2028, and stop treating R16 as a possible sanctions return after that date. Until then, R16 can mean either.

Preventing returns before they happen

Many returns can be headed off with checks before and between debits. Three rules shape that work:

• Account validation for WEB debits. WEB is the SEC code for consumer debits authorized over the internet or a wireless network. Since March 19, 2021, Originators of WEB debits must validate the account the first time they use an account number and whenever the account number changes. The method is up to the Originator, from prenotes and micro-entries to third-party validation services. The minimum is confirming that the account is open and can accept ACH entries; checking who owns it is not required.
• Prenotes, if you use them. A prenote is an optional zero-dollar entry. After sending one, an Originator may send live entries starting on the third banking day after the prenote’s settlement date, as long as no return or Notification of Change came back. Since June 21, 2024, prenotes may be sent at any time, for example to check an account that has been inactive.
• Notifications of Change. A receiving bank sends a Notification of Change (NOC) when details in an entry, such as the account number, need correcting. For recurring entries, an Originator must apply the correction within six banking days of receiving the NOC or before its next entry, whichever is later.

Validation targets the account problems behind codes like R02, R03 and R04, and applying NOCs keeps a payer’s details current between debits.

How to keep return rates low

• Validate accounts on first WEB use, and again whenever the account number changes.
• Get clear authorizations and keep copies, so proof can be produced within the 10-banking-day window.
• Use a company name payers recognize, so a familiar debit on a bank statement is not mistaken for an unknown one and returned R10.
• Apply Notifications of Change to recurring entries, within six banking days or before the next entry, whichever is later.
• Stop debiting after R02, R03, R07, R08 or R10, until you have new account details or a new authorization.
• Track your return rates every month, unauthorized, administrative and overall, against the 0.5%, 3.0% and 15.0% figures, so you can act on a rising rate early.

Sources

1. Nacha, ACH Network risk and enforcement topics
2. Nacha, Risk and quality rules fact sheet
3. Nacha, Risk management topics (October 1, 2024)
4. Nacha, Reversals and enforcement
5. Nacha, Differentiating unauthorized return reasons
6. Nacha, Improving ACH Network quality: Unauthorized Entry Fee
7. Nacha, New return reason code for sanctions compliance obligations
8. Nacha, New rules
9. Nacha, Risk management topic (April 1, 2025)
10. Nacha, Minor topics rule changes (January 1, 2026)
11. Nacha, Meaningful Modernization
12. Nacha, Supplementing fraud detection standards for WEB debits
13. Nacha, Minor rules topics (June 21, 2024)
14. Visa, Dispute management guidelines for merchants
15. Visa, Visa Core Rules and Visa Product and Service Rules