ACH return codes: Full R01 to R85 list and what to do

ACH return codes are three-character codes, an "R" plus two digits, that the receiving bank sends back to explain why an ACH payment failed. Each one also tells you what to do next.

For example, an R01 means the account didn't have enough funds, and the bank has 2 banking days after settlement to send it back. You can retry an R01, but an R02 (closed account) needs new bank details first.

ACH return codes are standardized error messages that explain exactly why an ACH payment failed, whether due to insufficient funds, a closed account, or invalid account details. Understanding these codes helps your accounts payable team identify patterns, resolve failures faster, and improve transaction success rates.

What are ACH return codes?

ACH return codes, also called ACH return reason codes, are three-character error messages generated when an ACH transaction fails.

Each code begins with the letter "R" followed by a 2-digit number. For example, R01 is the ACH return code for insufficient funds, and R04 is the code for an invalid account number.

These codes apply to both ACH withdrawal and ACH credit transactions. They provide a clear explanation for the failure, making it easier for you to diagnose and resolve payment issues.

ACH return codes are used by banks, financial institutions, businesses, and finance professionals. Understanding what they're for helps you remain compliant with the rules around ACH payments and keep payment processing efficient.

How do ACH return codes work?

When an ACH payment fails, the receiving depository financial institution (RDFI) assigns a return code explaining the reason. This code is sent to the originating depository financial institution (ODFI), which then relays the information to you.

The RDFI is the bank or financial institution receiving the ACH payment. It can assign an ACH return reason code if the payment doesn't meet certain criteria or there's some other issue that prevents it from accepting the payment.

The ODFI is the bank or financial institution sending the ACH payment. If it feels a payment return was improper, it can assign dishonored return codes to challenge it.

There are two key timeframes to know, and both run on top of how long ACH transfers take to settle:

• Two banking days: The RDFI must process standard returns such as R01, R02, R03, and R04 within 2 banking days of the settlement date.
• Sixty calendar days: Unauthorized returns to consumer accounts, such as R05, R07, R10, and R11, can come back up to 60 calendar days after the settlement date.

When a payment receives an ACH return code, resolve it quickly. Delays affect your cash flow and can push you closer to Nacha's enforcement thresholds.

How are ACH return codes assigned?

Banks assign ACH return reason codes based on specific criteria, such as a sending account having insufficient funds to complete the transaction, or the receiving account having been closed. Incorrect payment information, from the account number to the dollar amount, may also trigger ACH return codes.

Nacha, the organization that writes the rules for the ACH Network, oversees this process, ensuring consistency in return codes across the ACH network. It also standardizes codes, which makes it easier to both issue and respond to them. Some codes are more common for consumer transactions, while others pertain to business transactions.

Why ACH payments get returned

ACH payments can be returned for several reasons, which generally fall into five main categories:

Insufficient funds and financial issues

These returns happen due to ACH NSF (non-sufficient funds) situations, uncollected funds, or other account balance problems. They're often temporary, and you may be able to retry the payment after a few days. Codes like R01 and R09 fall into this category.

Account problems and closures

These returns occur because of closed accounts, invalid account numbers, incorrect DFI account number errors, or accounts that have been sold to another financial institution. Codes like R02, R03, R04, and R12 are common examples.

Authorization and fraud concerns

This category includes unauthorized debits, revoked authorizations, and customer disputes. There's an important distinction between consumer authorization issues (like R10) and corporate authorization issues (like R29), which have different rules and timeframes. Proper ACH authorization forms help prevent these returns.

Administrative and formatting errors

These returns are caused by technical mistakes such as invalid routing numbers, duplicate entries, mandatory field errors in the payment file, or issues with file record edit criteria. Codes like R13, R17, R24, and R26 fall here.

Timing and processing constraints

These returns relate to processing rules, such as improper effective entry dates, untimely returns by the RDFI, or attempts to transact with a non-transaction account. Codes like R18 and R20 are typical examples.

Complete ACH return codes list from R01 to R85

Return codes run from R01 to R85, though not every number is assigned. These tables group Nacha return codes by number so you can scan to yours, with return windows drawn from CBS Bank's quick reference guide to Nacha return reason codes and time frames. Unassigned numbers, such as R48, R49, R54–R60, R63–R66, R78, and R79, are left out.

Some codes never come from the receiving bank. The ACH Operator uses codes like R13 and R25 to reject entries it can't process, federal agencies use R40–R47 for enrollment entries, and banks use R61–R77 to dishonor or contest a return.

R01 to R10 Nacha return codes

R11 to R20 return reason codes

R21 to R30 ACH reject codes

R31 to R40 return codes

R41 to R50 return codes

R51 to R69 return codes

R70 to R85 return codes

Most common ACH return codes explained

Finance teams most frequently encounter a specific set of codes. Here's what triggers each one, how long the bank has to send it back, and what to do next.

R01 ACH return code for insufficient funds

The account lacks adequate funds to cover the debit. This is the ACH equivalent of a declined transaction and is often a temporary issue. You may be able to retry the payment after a few days once the account holder has replenished their balance.

• What to do: Confirm with the account holder that funds are available, then reinitiate. Contact the account holder if the issue recurs.
• Retry eligible? Yes. Nacha lets you reinitiate an R01 or R09 return up to two times within 180 days of the original settlement date, labeled "RETRY PYMT"
• Initiated by: RDFI
• Return window: 2 banking days

R02 ACH return code for a closed account

The account no longer exists. Contact the customer or vendor immediately to get updated banking information. Don't retry the payment to this account; it will fail again.

• What to do: Contact the payee to collect new bank account details. Update your records before resubmitting.
• Retry eligible? No. The account is permanently closed.
• Initiated by: RDFI
• Return window: 2 banking days

R03 ACH return code for no account or unable to locate account

The account number provided doesn't match the records at the receiving bank. Verify the account and routing numbers with the account holder before attempting the payment again. This is one of the most common ACH return codes and typically indicates a data entry error during account setup.

• What to do: Verify routing and account numbers with the account holder. Check for transposed digits or outdated information.
• Retry eligible? No. Retrying with the same incorrect details will produce the same result.
• Initiated by: RDFI
• Return window: 2 banking days

R04 ACH return code for an invalid account number

The account number's structure is incorrect. It may have the wrong number of digits or an invalid format. Collect the corrected account details from the customer before resubmitting the payment.

• What to do: Request corrected account information from the payee. Validate the format before resubmitting.
• Retry eligible? No. The account number format itself is invalid.
• Initiated by: RDFI
• Return window: 2 banking days

R05 ACH return code for an unauthorized debit to a consumer account

A debit was made to a consumer account without proper authorization. R05 specifically means a business entry type, a corporate Standard Entry Class (SEC) code such as CCD, was used to debit a consumer account. This is a serious compliance issue that can trigger Nacha enforcement if your unauthorized return rate exceeds 0.5%. Review your authorization process immediately.

• What to do: Cease all debits to this account and investigate your authorization records. If authorization documentation is insufficient, update your process.
• Retry eligible? No. You can't retry without obtaining proper authorization.
• Initiated by: RDFI
• Return window: 60 calendar days

R07 ACH return code for authorization revoked by customer

The customer has officially canceled their authorization for this specific recurring debit. You must stop all future debits and contact the customer to discuss the cancellation. Retrying this payment without new authorization violates Nacha rules.

• What to do: Stop all future debits to this account immediately. Contact the customer to discuss alternatives or obtain new authorization.
• Retry eligible? No. Retrying without new authorization is a Nacha violation.
• Initiated by: RDFI
• Return window: 60 calendar days

R08 ACH return code for a stopped payment

The account holder has instructed their bank to place a stop payment on this specific transaction. Reach out to the customer to understand why and resolve the underlying issue before attempting another payment.

• What to do: Contact the account holder to understand the reason for the stop payment. Resolve the underlying dispute before initiating a new transaction.
• Retry eligible? No. The stop payment is a deliberate action by the account holder.
• Initiated by: RDFI
• Return window: 2 banking days

R09 ACH return code for uncollected funds

Funds exist in the account but aren't yet available for withdrawal (e.g., a recent deposit hasn't cleared). This is similar to R01 but specifically relates to uncollected rather than insufficient funds.

• What to do: Confirm with the account holder that funds are available, then reinitiate.
• Retry eligible? Yes. Like R01, you can reinitiate up to two times within 180 days of the original settlement date.
• Initiated by: RDFI
• Return window: 2 banking days

R10 ACH return code for originator not known or not authorized

The customer says they don't recognize the company taking the payment, or never gave them permission to debit their account at all. This is different from a billing mistake. It means no valid authorization exists. Investigate immediately and have your authorization records ready.

• What to do: Pull your authorization records for this customer and prepare documentation. If authorization is missing, cease all debits and update your process.
• Retry eligible? No. Retrying without valid authorization is a serious Nacha violation.
• Initiated by: RDFI
• Return window: 60 calendar days for consumer accounts

R11 ACH return code for an entry not in accordance with the authorization

The customer authorized this payment, but something about it didn't match what they agreed to, usually the wrong amount or the wrong date. Review the original authorization and the entry details, then contact the payer to sort out the discrepancy.

• What to do: Compare the entry against the original authorization to confirm what went wrong, then contact the payer to resolve it.
• Retry eligible? Yes. Once the error is corrected (e.g., the right amount or date), you can submit a new entry within 60 days of the return without getting a new authorization.
• Initiated by: RDFI
• Return window: 60 calendar days

R16 ACH return code for a frozen account

The account has been frozen by the bank or a legal order, preventing any transactions. Contact the account holder to understand the situation and obtain an alternative payment method or account details.

• What to do: Reach out to the account holder for alternative payment details. Don't attempt further transactions to this account until the freeze is resolved.
• Retry eligible? No. The freeze must be lifted by the bank or court before the account can transact.
• Initiated by: RDFI
• Return window: 2 banking days

R20 ACH return code for a non-transaction account

The entry went to a non-transaction account, an account where Regulation D or the bank's policies prohibit or limit transactions. Ask the payee for a checking account or another account that accepts ACH.

• What to do: Collect a different account that accepts ACH entries.
• Retry eligible? No. The same account will reject the entry again.
• Initiated by: RDFI
• Return window: 2 banking days

R23 ACH return code for a credit entry refused by the receiver

The receiver declined an ACH credit, for example because it was an overpayment, the wrong amount, or from an originator they don't recognize. Confirm the amount and account details with the payee before sending the payment again.

• What to do: Confirm the correct amount and destination with the payee.
• Retry eligible? Only after you resolve the reason for the refusal.
• Initiated by: RDFI
• Return window: 2 banking days after the RDFI learns of the refusal

R29 ACH return code for corporate customer advises not authorized

This is similar to an R10 return but applies specifically to corporate accounts. The company is claiming the debit was not authorized. Review your service agreements and contact their accounts payable team to resolve the dispute.

• What to do: Review your service agreement and authorization documentation with this corporate customer. Contact their AP team to resolve the dispute.
• Retry eligible? No. Retrying without resolving the authorization dispute risks Nacha enforcement.
• Initiated by: RDFI
• Return window: 2 banking days (R29 applies to business accounts, so it doesn't get the 60-day consumer window)

Nacha return rate thresholds and compliance

Nacha sets three return rate thresholds measured on a rolling 60-day basis. Crossing the 3% administrative or 15% overall level triggers a Nacha review of your origination practices. Crossing the 0.5% unauthorized threshold puts you in Nacha's enforcement process, which can lead to fines.

If you process a high volume of ACH transactions, understanding these thresholds is critical to maintaining your origination privileges. For the full rule set behind these numbers, see Ramp's guide to Nacha operating rules.

Here's how the math works for the unauthorized rate:

Unauthorized return rate = Unauthorized debit returns / Total ACH debits originated

For example, say you originate 10,000 ACH debits over 60 days and 40 come back as unauthorized returns:

Unauthorized return rate = 40 / 10,000 = 0.4%

That's under the 0.5% threshold, but close enough to investigate.

Unauthorized return threshold (0.5%)

• Applies to codes R05, R07, R10, R11, R29, and R51
• These indicate the account holder disputes authorizing the transaction.
• Exceeding 0.5% triggers Nacha's enforcement process, which can lead to fines.
• Most serious threshold; signals potential fraud or poor authorization practices

Administrative return threshold (3%)

• Applies to codes R02, R03, and R04
• Indicates data quality issues: wrong account numbers, closed accounts, or unlocatable accounts
• Exceeding 3% signals poor data hygiene in your payment operations.
• Often fixable through better account verification during onboarding

Overall return rate threshold (15%)

• Applies to all ACH debit return codes combined
• Broadest threshold covering every return reason
• Typically only triggered by businesses with systemic payment processing issues
• Exceeding this level triggers a Nacha review of your origination practices.

How to monitor your return rates

• Calculation: Total returns divided by total originations over a rolling 60-day window
• Dashboards: Most payment processors provide real-time return rate monitoring.
• Segmentation: Track rates by return code category (unauthorized vs. administrative vs. other) to pinpoint problem areas.
• Internal alerts: Set warning thresholds below Nacha's limits (e.g., alert at 0.3% unauthorized, 2% administrative) so you can course-correct before triggering enforcement.

Which ACH return codes indicate fraud?

Some ACH return codes indicate routine errors, while others signal potential fraud or unauthorized activity requiring different handling and compliance steps. Knowing which codes are which is the first step in preventing ACH fraud.

Codes that indicate unauthorized activity

Four codes signal a disputed authorization: R07 (Authorization Revoked by Customer), R10 (Customer Advises Originator Is Not Known/Not Authorized), R11 (Entry Not In Accordance with the Terms of the Authorization), and R29 (Corporate Customer Advises Not Authorized).

These codes, along with R05 and R51, count toward Nacha's 0.5% unauthorized return rate threshold. Exceeding that threshold triggers Nacha's enforcement process.

The difference between R07, R10, R11, and R29

• R07: The consumer previously authorized the debit but has since revoked authorization (e.g., canceled subscription). Prior authorization existed at some point.
• R10: The customer says they don't recognize the company taking the payment, or never gave them permission to debit their account at all. This is the strongest dispute type and a potential fraud indicator.
• R11: The customer says the payment doesn't match the original authorization. This is also a potential fraud indicator.
• R29: Same as R10 but for corporate/business accounts. The company claims no authorization was ever given.

The key distinction: R07 implies prior authorization that was later revoked. R11 also implies prior authorization. However, R10 and R29 imply no authorization ever existed, making them more serious from a compliance perspective.

Written Statement of Unauthorized Debit

When a consumer disputes an ACH debit as unauthorized (R10, R11), the RDFI must obtain a Written Statement of Unauthorized Debit (WSUD) before processing the return. This is a signed statement from the account holder confirming they did not authorize the transaction.

For businesses receiving WSUDs: Treat each one as a serious compliance signal requiring investigation. Multiple WSUDs may indicate a process failure in how you capture and store customer authorizations.

How Nacha's 2026 fraud monitoring rules affect returns

Nacha's 2026 rules require every non-consumer originator, regardless of volume, to run documented, risk-based processes to identify ACH entries initiated due to fraud. Phase 1 took effect Mar 20, 2026, and Phase 2 followed on Jun 22, 2026.

Unauthorized return codes are one of the clearest signals your fraud monitoring should watch. For the phase-by-phase requirements, see Ramp's breakdown of the 2026 Nacha rule changes.

What happens when an ACH payment is returned?

When a payment is returned, the RDFI sends an ACH return file back to the ODFI, which then notifies you. This notification explains why the payment failed via the return code.

This process is distinct from an ACH reversal, which is initiated by the originator to correct an error. Depending on your payment processor, you may also be charged a fee for each returned transaction.

If you regularly experience failed ACH payments, the return codes tell you exactly why. Resolving failed ACH payments costs time, puts you at risk of paying invoices late, and costs money. When troubleshooting payment issues, your bank can use the ACH trace number to locate and investigate the transaction within the ACH network.

ACH returns vs. ACH reversals

ACH returns and ACH reversals are similar-sounding terms with very different meanings. Understanding the difference helps you manage transactions more effectively and avoid confusion.

For example, if you make an ACH payment by mistake and want to reverse it, reading about ACH returns won't be helpful. Likewise, if you experience an ACH payment failure, researching ACH reversals will only cause confusion.

Notifications of change vs. ACH return codes

A notification of change (NOC) isn't a failed payment. The payment posted, but the receiving bank is telling you that a detail, like the account or routing number, needs updating before your next entry.

NOC codes start with "C," while return codes start with "R." Common examples include C01 (incorrect DFI account number), C02 (incorrect routing number), and C03 (incorrect routing number and DFI account number), all listed in CBS Bank's Nacha code reference. Under Nacha rules, you must make the requested change within 6 banking days of receiving the NOC or before your next entry, whichever is later.

How to handle ACH returns

Responding to returns requires quick, practical action. Most require resolution within 2 banking days, so speed matters.

1. Verify bank account information

Cross-check the routing number, account number, and account type against the information provided by the customer or vendor. Look for common errors such as typos or transposed digits.

2. Contact the customer or vendor

Reach out promptly to explain that the payment was returned. Be specific about the return code and what you need to resolve it, such as a new account number or confirmation of authorization.

3. Retry the payment when appropriate

Only certain return codes are appropriate for a retry. Codes like R01 (insufficient funds) or R09 (uncollected funds) may resolve themselves in a few days. Never retry payments to closed accounts (R02), with invalid account numbers (R04), or after unauthorized returns (R05, R07, R10, R29). An R11 can be resubmitted only after you correct the error that caused it.

4. Document and track return patterns

Keep detailed records of all returns, including the code, customer, and date. High return rates can negatively affect your ability to process ACH payments and may indicate deeper issues with your data collection or authorization processes.

Track your return rates by category. If unauthorized returns (R05, R07, R10, R11, R29, R51) exceed 0.5% or administrative returns (R02, R03, R04) exceed 3% over a 60-day window, you risk Nacha enforcement action.

How to prevent ACH returns

Taking proactive steps significantly reduces return rates and protects your ACH processing privileges.

1. Validate account details before sending payments

Use account verification services to confirm that routing and account numbers are valid and that the account is active before you initiate any transactions. This catches errors like R03 and R04 before they happen.

Micro-deposit verification (sending two small deposits for the account holder to confirm) is one option, though it takes a few days. Instant account verification services connect directly to the account holder's bank to confirm details in real time, making them a faster alternative for high-volume payment operations.

2. Use prenote transactions for new accounts

Send a zero-dollar test transaction (a "prenote") to verify new account information before processing actual payments. This confirms the account details are correct without moving any money, a simple step that helps prevent returns.

Nacha requires you to wait 3 banking days after a prenote before sending live entries, so build this timeline into your vendor onboarding process. For new vendors or customers, initiate the prenote as soon as you collect banking details rather than waiting until the first payment is due.

3. Maintain clear authorization records

Strong authorization documentation prevents the most damaging returns: R05, R07, R10, R11, R29, and R51.

• Store signed authorization forms or electronic consent records for every customer.
• Use Nacha-compliant authorization language that clearly states the amount, frequency, and terms of the debit.
• Build a process for handling revocation requests promptly; when a customer revokes authorization, stop debits immediately.
• Audit authorization records quarterly to ensure documentation exists for every active recurring debit.

4. Set up payment alerts and monitoring

Configure notifications for returns so your team can respond quickly. Monitor your return rates by code type to identify trends, such as a high number of R04s indicating a problem with your data entry process.

Beyond individual return alerts, track your aggregate return rates against Nacha's thresholds (0.5% unauthorized, 3% administrative, 15% overall). Set internal warning alerts below these limits so you can take corrective action before triggering enforcement.

5. Automate payment approval workflows

Implement internal controls and approval processes that catch errors before payments are sent. Automation reduces the manual entry mistakes that often lead to administrative returns like R13, R17, and R26. When you capture invoices with OCR instead of rekeying them, you remove the typos behind R03 and R04 returns; Ramp Bill Pay reads invoice headers and line items with 99% OCR accuracy.

Stop bad payment data from turning into ACH returns with Ramp

Many ACH returns start in AP: a vendor's account number gets rekeyed wrong, bank details change without anyone noticing, or a payment goes out before anyone checks it. You can stop those errors before they reach the ACH Network by taking manual steps out of your payables workflow with Ramp Bill Pay.

With Bill Pay, you process bills 2.4x faster with 86% fewer clicks than legacy software. AI invoice processing captures and auto-codes every bill, so you're not retyping the details behind R03 and R04 returns.

Approval workflows route each payment by your own custom rules, with AP Agent recommending approvals so the right people review vendor changes before money moves. When a bill is ready, you pay it by ACH, check, card, or wire from the same place.

Two-way ERP sync keeps your books aligned with what actually went out. Try an interactive demo to see how Ramp Bill Pay keeps payment errors out of your AP workflow.