ACH return codes explained: R01 to R85

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:

• 2 banking days: The RDFI must process standard returns such as R01, R02, R03, and R04 within 2 banking days of the settlement date
• 60 calendar days: Returns for unauthorized or revoked authorization transactions, such as R05, R07, R10, and R11 can occur up to 60 calendar days after the original transaction

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.

The regulatory body Nacha oversees this process, ensuring consistency in return codes across the ACH network. They also standardize 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 understanding ACH return codes is important for your business

Understanding common ACH return codes helps you diagnose payment failures faster and spot systemic issues. Here's what that looks like in practice:

1. Identify payment issues: These codes provide a standardized reason for failed transactions so you can address problems quickly
2. Enhance communication: Return codes create transparency between banks and your business, helping resolve issues efficiently and reducing delays
3. Improve transaction success rates: By analyzing return codes, you can detect recurring issues, adjust payment methods, and take proactive steps to reduce failures
4. Ensure Nacha compliance: Monitoring return codes helps you stay within Nacha's 15% return rate threshold, avoiding penalties and maintaining uninterrupted ACH services

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

There are 85 ACH return codes, broken into logical groupings so you can quickly find the code you're looking for.

R01 to R10 Nacha return codes

These are the most frequently encountered ACH return codes. The first four, R01, R02, R03, and R04, may be worth memorizing.

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. Understanding what triggered them and the immediate next steps is crucial for resolving payment issues quickly.

R01 ACH return code — 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: Wait 1–2 business days and resubmit the payment. Contact the account holder if the issue recurs.
Retry eligible? Yes. R01 is one of only two retry-eligible codes (along with R09).
Initiated by: RDFI

R02 ACH return code — Account closed

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

R03 ACH return code — 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

R04 ACH return code — 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

R05 ACH return code — Unauthorized debit to consumer account

A debit was made to a consumer account without proper authorization. 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 cannot retry without obtaining proper authorization.
Initiated by: RDFI

R07 ACH return code — 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

R08 ACH return code — Payment stopped

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

R09 ACH return code — 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: Wait 2–3 business days for the funds to clear, then retry.
Retry eligible? Yes. This is typically a timing issue that resolves itself.
Initiated by: RDFI

R10 ACH return code — Customer advises originator is not known/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.

Note: Nacha narrowed R10's definition in 2020. It used to be a catch-all for anything unauthorized, including simple errors like the wrong amount or date. Now those billing-error cases go through R11 instead. R10 is reserved specifically for cases where the customer doesn't know the originator, has no relationship with them, or never authorized them to debit the account.

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

R11 ACH return code — Entry not in accordance with the terms of 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.

Note: Nacha changed what R11 means back in 2020. It used to stand for "Check Truncation Entry Return" (used when a converted paper check was rejected) and had a quick 2-banking-day return window. It now means "Entry Not in Accordance with the Terms of the Authorization" and gives banks up to 60 calendar days to return it. This longer window gives originators time to fix genuine billing errors without needing a new authorization from the customer.

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

R16 ACH return code — Account frozen

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. Do not 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

R29 ACH return code — 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

Nacha return rate thresholds and compliance

Nacha enforces three return rate thresholds measured on a rolling 60-day basis. Exceeding these can result in fines, increased monitoring, or loss of ACH origination privileges. If you process a high volume of ACH transactions, understanding these thresholds is critical to maintaining your origination privileges.

Unauthorized return threshold (0.5%)

• Applies to codes R05, R07, R10, R11, and R29
• These indicate the account holder disputes authorizing the transaction
• Exceeding 0.5% triggers Nacha's enforcement process, which can include formal warnings, corrective action plans, and financial penalties
• 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 threshold can result in suspension of ACH origination privileges

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.

Codes that indicate unauthorized activity

• 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)
• R29 (Corporate Customer Advises Not Authorized)

These four codes are subject to Nacha's 0.5% unauthorized return threshold. Exceeding that threshold triggers graduated enforcement actions.

The difference between R07, R10, R11, and R29

• R07: 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 may require a Written Statement of Unauthorized Debit (WSUD) before processing the return. This is a sworn statement from the account holder confirming they did not authorize the transaction.

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

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.

How to handle ACH returns

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

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.

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.

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), for unauthorized transactions (R07, R10, R11), or with invalid account numbers (R04).

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) 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.

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 1–2 business 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.

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 can prevent a surprising number of returns.

Prenotes take 3–4 business days to validate, 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.

Maintain clear authorization records

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

• 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

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.

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. With Ramp Bill Pay, error alerts surface return codes directly in your workflow, eliminating the manual lookup that slows resolution.

Automate your AP with Ramp

With manual AP processes, data entry mistakes can lead to returned ACH payments or the need for an ACH reversal. You can avoid these errors and more by automating your AP process.

Ramp Bill Pay lets you scan or upload documents such as invoices, purchase orders, vendor onboarding docs, and receipts instead of entering all that information manually.

And with the ability to automate the payment process with features such as automated workflows, 2-way and 3-way matching, and error alerts, you'll have complete visibility into your cash flow, too.

What else could Ramp do to simplify your AP process? Try an interactive demo.