What Are ACH Return Codes? The Complete List

ACH return codes are standardized two-character codes (preceded by “R”) used in the Automated Clearing House (ACH) network to explain why an ACH payment was returned or failed. These codes allow banks and businesses to quickly identify the reason for a payment rejection and take appropriate action. 

In this comprehensive guide, we’ll explain what ACH return codes are, how they work, and provide the complete list of ACH return codes (R01–R85) with their meanings. We’ll also cover common codes, NACHA rules, tips to avoid returns, and answer frequently asked questions. 

This guide is designed for general consumers, small business owners, and financial professionals, with a professional and informative tone.

In 2024 alone, the ACH network processed 33.6 billion payments totaling $86.2 trillion, underscoring how widely ACH is used for direct deposits, bill payments, and more. On average, a small percentage of these transactions fail and get returned – in some industries, 8–12% of electronic payments are returned. 

Each returned payment comes with an ACH return code that indicates the specific reason (e.g., insufficient funds, invalid account, unauthorized transaction). Understanding these return codes is essential for businesses (to manage payment failures and maintain compliance) and for consumers (to know why a payment might not have gone through).

Let’s dive into ACH return codes and what each one means, along with practical guidance on handling and preventing ACH returns.

Understanding ACH Return Codes

ACH (Automated Clearing House) is an electronic network for financial transactions, commonly used in the United States to move money between bank accounts (for things like payroll direct deposits, bill payments, and tax refunds). 

An ACH return occurs when a payment cannot be completed and the funds are sent back (or “returned”) to the sender’s bank. ACH return codes are the standardized reasons given for these returns, helping all parties understand what went wrong.

Each ACH return code starts with the letter “R” followed by a two-digit number (for example, R01, R02, etc.). There are currently 85 distinct ACH return codes standardized by NACHA (the National Automated Clearing House Association), which governs the ACH network. 

These codes cover everything from common issues like insufficient funds to administrative errors and even international payment problems. By using standard return codes, receiving banks (RDFIs) and originating banks (ODFIs) can communicate payment failures in a consistent way across the network.

• How ACH return codes are used: When a receiving bank cannot post an ACH transaction (for any reason defined by NACHA rules), it will generate a return entry with the appropriate code and send it back to the originating bank.
  
  The originating bank then informs the originator (the company or person who initiated the payment) so they can address the issue. This process happens quickly – often within 1–2 banking days for common errors – but certain return situations (like unauthorized debits) allow a longer window.
  
  Each code has specific rules and timeframes set by NACHA for how and when the return must be processed.
  
• Example: If you attempt to debit a customer’s account for a payment but the account doesn’t have enough funds, the receiving bank will return the payment with code R01 (Insufficient Funds).
  
  This return must be sent within 2 banking days of the original transaction. On the other hand, if a consumer finds an unauthorized charge on their account, their bank can return it with code R05 (Unauthorized Debit), and they have up to 60 days to do so.
  
  The different timeframes reflect the nature of the issue – simple errors are caught quickly, while disputes over authorization allow more time for investigation.
  
• NACHA’s role: NACHA maintains the list of return codes and updates the rules as needed. ACH return codes evolve over time, with NACHA occasionally adding new codes or changing definitions to address emerging scenarios.
  
  For instance, NACHA recently repurposed code R11: it is now used when a payment was authorized but not in accordance with the terms (for example, wrong amount or date). By staying updated on NACHA rule changes, businesses can ensure they handle returns correctly and remain compliant.

In summary, ACH return codes are a crucial part of the ACH system’s plumbing – a “common language” that banks use to explain payment issues. Next, we will explore how these codes work in practice, and then provide the full list of codes and their meanings.

How ACH Return Codes Work in Practice

When an ACH payment fails, the return code workflow is as follows:

• Receiving Bank (RDFI) detects an issue: The RDFI checks the incoming ACH transaction. If there’s a problem (insufficient funds, invalid account details, etc.), the RDFI stops the payment from posting to the receiver’s account.
  
• RDFI generates a return with code: The RDFI sends the transaction back through the ACH network, accompanied by the appropriate return code that indicates why it’s being returned. NACHA rules require using the correct code and doing so within the allowed timeframe for that code.
  
• Originating Bank (ODFI) receives the return: The ODFI gets the return entry and code, and passes this information to the originator (the business or individual who initiated the payment).
  
• Originator takes action: Depending on the code, the originator might retry the payment, contact the customer for updated information, fix any data errors, or cease debiting (especially in cases of unauthorized returns).

Each ACH return code comes with a specific required timeframe in which the return must be processed. For many errors (like invalid account numbers or insufficient funds), the RDFI must return the item within 2 banking days. 

For certain consumer-initiated disputes (like unauthorized debits), the timeframe extends up to 60 calendar days. Banks must adhere to these timelines; if a bank fails to return a problematic entry within the allowed window, it typically assumes liability for the funds.

It’s important to note the distinction between different types of return scenarios:

• Administrative returns: These are returns for correctable errors or account issues – for example, invalid account numbers (R04) or closed accounts (R02). They usually occur quickly after the payment is sent.
  
• Insufficient funds: The most common return reason (R01) – occurs when the account lacks funds. These returns also happen within 2 days.
  
• Authorization-related returns: These include cases where the transaction was not authorized or was revoked by the customer (codes like R05, R07, R10, R11). Because consumers have protections, these returns can occur up to 60 days after settlement.
  
• Other specialized returns: Some codes cover duplicate payments, bank mergers (account sold to another bank, R12), international transaction issues (R80s series), and so on. We will cover all codes in the list section.

Real-world example: Imagine a small business debits a customer’s account for a monthly subscription. If the debit is returned with R01 (Insufficient Funds), the business might wait a few days and attempt the debit again or contact the customer for a different payment method. 

If instead the return code is R03 (No Account/Unable to Locate Account), it means the account details were wrong – the business should reach out to the customer to get correct banking info before trying again. 

However, if a return comes back as R07 (Customer Revoked Authorization) or R10 (Unauthorized), the business should not simply retry the debit – those codes indicate the customer does not approve the transaction. 

In such cases, the originator should halt debits and resolve the authorization issue (possibly obtaining a new authorization) to comply with NACHA rules.

In all cases, reading the return code tells the originator exactly what step to take next. This minimizes guesswork and ensures that issues (like incorrect data or lack of funds) are addressed promptly. Next, we’ll discuss the compliance considerations around return codes before diving into the list of codes.

NACHA Rules and Return Code Compliance

NACHA (National Automated Clearing House Association) not only defines the return codes but also sets rules and risk limits regarding ACH returns. This is to ensure the ACH network remains efficient and that originators don’t abuse the system (for example, by sending too many bad debits). Key compliance points include:

• Return rate thresholds: NACHA monitors the percentage of an originator’s transactions that are returned. There are three critical thresholds:
  
  • Unauthorized return rate: Must be 0.5% or lower for debit entries that are returned as unauthorized (codes R05, R07, R10, R11, R29, R51). In other words, no more than 0.5% of your debits should be returned due to lack of proper authorization.
    
  • Administrative return rate: Must be 3.0% or lower for returns due to administrative/account errors (codes like R02, R03, R04). These are things like bad account numbers or closed accounts.
    
  • Overall return rate: Must be 15% or lower for all ACH debit returns combined.
    
• Consequences of high return rates: If an originator exceeds these thresholds, NACHA may issue warnings, impose fines, or even suspend the originator from the network.
  
  Banks (ODFIs) are required to monitor their customers’ return rates and work with those approaching the limits to implement corrective action. Excessive returns are seen as a risk factor for fraud and operational issues.
  
• Timely handling: NACHA rules specify the timeframes for each return code (as we discussed earlier). Originating banks and receiving banks must process returns within these windows.
  
  For example, an unauthorized debit (R10) returned after the 60-day window would not be compliant (and the RDFI would generally lose the ability to return it, barring special cases).
  
• Accurate coding: Banks are expected to use the correct return code that matches the situation. Using the wrong code (whether accidentally or to game the system) is against the rules.
  
  For instance, R11 was redefined to specifically cover authorized payments returned for error; banks should not use R10 (unauthorized) when R11 is the accurate reason.

For businesses, staying within NACHA return rate limits is crucial. If you’re a payment originator (say a company debiting customers), you should monitor your return ratios. 

Frequent returns can indicate issues such as poor customer authorization practices or data errors, which you need to fix. Additionally, maintaining low return rates demonstrates compliance and reliability to your bank and payment processors.

NACHA periodically updates its rules. A recent example is the update to Return Code R11 (mentioned above) to better differentiate between truly unauthorized debits and those that had an authorization error. By keeping up with such changes, originators can avoid misclassifying returns and handle customer disputes properly.

In summary, NACHA’s compliance framework around ACH return codes means originators must minimize avoidable returns, address problems promptly, and ensure every return reason is properly categorized. Now, let’s look at the most common ACH return codes and what they mean for everyday transactions.

Most Common ACH Return Codes (and What They Mean)

There are dozens of ACH return codes, but a handful make up the majority of returned transactions. Here are some of the most frequently encountered ACH return codes, explained in plain language:

R01 – Insufficient Funds

This code indicates the receiver’s account did not have enough money to cover the ACH debit. It’s the number one most common return reason, often representing around 40–50% of all ACH returns. Essentially, it’s a “bounced” electronic payment due to non-sufficient funds (NSF).

• Timeframe: 2 banking days
  
• Account Type: Consumer or Business (both)
  
• Resolution: The originator may retry the payment after a short period or contact the customer. Customers should ensure funds are available on the payment date to avoid R01.

R02 – Account Closed

The account the ACH was trying to debit or credit has been closed. This often happens if a customer forgot to update payment info after switching banks.

• Timeframe: 2 banking days
  
• Account Type: Consumer or Business
  
• Resolution: No retry should be made to the closed account. The originator should obtain updated bank account details from the customer before attempting the transaction again.

R03 – No Account / Unable to Locate Account

The account number specified in the payment instruction does not correspond to an open account at the receiving bank. In other words, the bank can’t find an account matching the info provided.

• Timeframe: 2 banking days
  
• Account Type: Consumer or Business
  
• Resolution: The originator should double-check and correct the routing/account numbers. This often results from data entry errors or outdated information.

R04 – Invalid Account Number Structure

The account number is in an invalid format or fails the checks specific to the bank (for example, too many digits, or invalid sequence). The number structure is wrong for that bank.

• Timeframe: 2 banking days
  
• Account Type: Consumer or Business
  
• Resolution: Validate the account number and format. The originator might need to confirm the correct account details with the customer or verify the number against a validation service.

R05 – Unauthorized Debit to Consumer Account (Using Corporate SEC Code)

This code means a debit was made to a consumer account but was submitted with a corporate transaction code (SEC code) or was otherwise not authorized by the consumer. Essentially, the consumer claims they did not authorize this specific transfer. R05 is often used when a corporate payment entry was mistakenly used on a personal account without proper authorization.

• Timeframe: 60 calendar days
  
• Account Type: Consumer only
  
• Resolution: The originator should immediately investigate the authorization. Usually, this return will require the originator to stop any further debits until proper authorization is in place. It may also involve working with the consumer to clarify the mistake or obtain correct authorization under the proper SEC code.

R07 – Customer Revoked Authorization

The account holder previously authorized an ACH debit (typically a recurring payment) but has since revoked that authorization. For example, a customer who had auto-pay set up for a subscription might have canceled it, yet a charge still came through – they then tell their bank it was revoked.

• Timeframe: 60 calendar days
  
• Account Type: Consumer (usually for consumer debits)
  
• Resolution: The originator must cease further debits to that account for that authorization. Do not retry the transaction. Contact the customer to resolve – if the customer is willing to continue payments, get a new authorization in writing.

R08 – Payment Stopped (Stop Payment)

The account holder placed a stop payment order on this transaction or all transactions from a certain originator. This is similar to how one might stop a check – the customer instructed their bank not to allow the ACH debit.

• Timeframe: 2 banking days
  
• Account Type: Consumer or Business
  
• Resolution: The originator should not retry the payment. Contact the customer to understand why the payment was stopped. If it was a single instance (maybe the customer needed to delay a payment), you might reschedule with their permission. If the customer no longer wants the service or product, you’ll need to halt future payments.

R09 – Uncollected Funds

This means the funds in the account were uncollected – the account’s balance was not yet available due to pending items (for instance, deposited checks on hold). It’s similar to insufficient funds, but specifically that the money is on hold or in transit.

• Timeframe: 2 banking days
  
• Account Type: Consumer or Business
  
• Resolution: The originator may retry the debit after a few days, allowing time for the funds to become available. It may also indicate the need for the customer to ensure their deposits are clear before the debit date.

R10 – Customer Advises Unauthorized (Not Authorized to Debit)

The receiver (customer) claims that the originator is not authorized to debit their account. This is a broad “unauthorized” return for consumer accounts – for example, if a person says, “I never agreed to this payment,” their bank returns it as R10. 

(In certain transaction types like ARC, BOC, POP – which are conversion of checks – businesses or even non-consumers can use R10 as well.)

• Timeframe: 60 calendar days
  
• Account Type: Consumer (and Non-consumer only in limited cases for certain entry types)
  
• Resolution: This is a serious return reason. The originator should not attempt the payment again. They should review their authorization records.
  
  Often, an R10 will count against the originator’s unauthorized return rate, so the business may need to reach out to the customer to resolve any misunderstanding or obtain proper authorization if it was a mistake.

R11 – Customer Advises Entry Not in Accordance with the Terms (Error)

R11 is used when a transaction was indeed authorized by the customer, but the payment does not conform to the agreed terms. For example, the amount was wrong, the date was earlier than agreed, or it was a duplicate payment. This code was recently repurposed by NACHA to differentiate these cases from outright unauthorized debits.

• Timeframe: 60 calendar days
  
• Account Type: Consumer (and Non-consumer for certain entry types like ARC, BOC, POP, IAT)
  
• Resolution: The originator should investigate the error – was it a wrong amount, wrong date, or other issue? The originator may need to refund any incorrect amount and then initiate a correct transaction.
  
  Importantly, this return reason tells the business that their processes need adjustment (e.g., ensure the correct payment schedule or amounts).

These common codes cover the majority of everyday ACH return scenarios. In particular, R01 through R04 (funds/account issues) and R05, R07, R10, R11 (authorization issues) are critical for businesses to understand and address appropriately. 

Next, we’ll provide the complete list of ACH return codes (R01–R85) in a convenient table, along with their standard descriptions, account applicability, and return timeframes.

Complete List of ACH Return Codes (R01–R85)

Below is a comprehensive table of all ACH return codes as defined by NACHA, including their standard description, applicable account type, and the typical timeframe within which the return must be initiated. This list is up to date as of 2025 and covers 85 return codes in total.

Code	Description (Return Reason)	Account Type	Required Return Timeframe
R01	Insufficient Funds – Not enough funds in the account.	Consumer or Non-Consumer	2 Banking Days
R02	Account Closed – The account is closed.	Consumer or Non-Consumer	2 Banking Days
R03	No Account/Unable to Locate Account – Invalid account number.	Consumer or Non-Consumer	2 Banking Days
R04	Invalid Account Number Structure – Number fails format check.	Consumer or Non-Consumer	2 Banking Days
R05	Unauthorized Debit to consumer (Corporate SEC code used)	Consumer (Personal)	60 Calendar Days
R06	ODFI Requested Return – Return requested by originating bank.	Consumer or Non-Consumer	Undefined (varies, case-by-case)
R07	Authorization Revoked by Customer – Previously authorized but later revoked.	Consumer	60 Calendar Days
R08	Payment Stopped – Stop payment on item.	Consumer or Non-Consumer	2 Banking Days
R09	Uncollected Funds – Account has uncollected deposits.	Consumer or Non-Consumer	2 Banking Days
R10	Customer Advises Unauthorized Debit – No authorization from customer.	Consumer (and certain Non-Consumer)	60 Calendar Days
R11	Customer Advises Entry Not in Accordance with Terms – Authorized but error (wrong amount/date).	Consumer (and certain Non-Consumer)	60 Calendar Days
R12	Account Sold to Another DFI – Account moved to different bank.	Consumer or Non-Consumer	2 Banking Days
R13	Invalid ACH Routing Number – Routing transit number is invalid.	Consumer or Non-Consumer	Next business day (next file delivery)
R14	Representative Payee Deceased or Unable to Continue – Beneficiary’s representative (for government payments) is deceased.	Consumer or Non-Consumer	2 Banking Days
R15	Beneficiary or Account Holder Deceased – Account owner passed away (used for government payments).	Consumer	2 Banking Days
R16	Account Frozen/Blocked (e.g., OFAC sanction) – Funds unavailable due to legal action or account freeze.	Consumer or Non-Consumer	2 Banking Days
R17	File Record Edit Criteria / Invalid Account Number (Name mismatch or suspicious, or reversal not processed) – Used for certain error conditions or flagged fraud.	Consumer or Non-Consumer	2 Banking Days
R18	Improper Effective Date – Payment effective date is invalid (e.g., too far in past/future).	Consumer or Non-Consumer	Next business day (next file delivery)
R19	Amount Field Error – Transaction amount invalid (e.g., non-numeric or out of allowed range).	Consumer or Non-Consumer	Next business day
R20	Non-Transaction Account – Entry attempted on an account that cannot process ACH (e.g., savings passbook or loan-only account).	Consumer or Non-Consumer	2 Banking Days
R21	Invalid Company Identification – The Company ID in the entry (for business transactions) is invalid.	Non-Consumer (Corporate)	2 Banking Days
R22	Invalid Individual ID Number – Individual ID used in entry detail is invalid (e.g., format or not known).	Consumer or Non-Consumer	2 Banking Days
R23	Credit Entry Refused by Receiver – Receiver doesn’t want the funds (for example, refuses a credit refund).	Consumer or Non-Consumer	Upon receipt (immediate upon refusal)
R24	Duplicate Entry – The entry appears to be a duplicate of one already processed.	Consumer or Non-Consumer	2 Banking Days
R25	Addenda Error – Improper formatting or info in the addenda record of the entry.	Consumer or Non-Consumer	Next business day
R26	Mandatory Field Error – A required field in the entry is missing or invalid.	Consumer or Non-Consumer	Next business day
R27	Trace Number Error – The trace number is missing or inconsistent.	Consumer or Non-Consumer	Next business day
R28	Routing Number Check Digit Error – The routing number fails the check digit verification.	Consumer or Non-Consumer	Next business day
R29	Corporate Customer Advises Not Authorized – A non-consumer (business) account says the debit was not authorized.	Non-Consumer (Corporate)	2 Banking Days
R30	RDFI Not Participant in Check Truncation Program – The bank cannot process check image (XCK) entries.	Consumer or Non-Consumer	Next business day
R31	Permissible Return (CCD/CTX Only) – Return of a legitimate entry within the allowed time (for corporate payments).	Non-Consumer (Corporate)	Undefined (per rules)
R32	RDFI Non-Settlement – The RDFI couldn’t settle the entry (perhaps due to bank closure or error).	Consumer or Non-Consumer	Next business day
R33	Return of XCK Entry – Returning a destroyed check (XCK) entry.	Consumer or Non-Consumer	60 Calendar Days
R34	Limited Participation DFI – The RDFI participation is limited and doesn’t allow this entry.	Consumer or Non-Consumer	Next business day
R35	Improper Debit Entry – Debit not allowed for this type of account or situation.	Consumer or Non-Consumer	Next business day
R36	Improper Credit Entry – Credit not allowed for this account (e.g., trying to credit where only debits allowed).	Consumer or Non-Consumer	Next business day
R37	Source Document Presented (SEC Code RCK) – The source check has been presented for payment (used in RCK).	Consumer or Non-Consumer	60 Calendar Days
R38	Stop Payment on Source Document (RCK) – Stop payment was placed on the original check.	Consumer or Non-Consumer	60 Calendar Days
R39	Improper Source Document (RCK) – The check used for an RCK entry was ineligible (e.g., not a personal check).	Consumer or Non-Consumer	2 Banking Days
R40	Return of ENR Entry – A return of an ACH enrollment entry (ENR) for federal government payments.	Consumer or Non-Consumer	2 Banking Days
R41	Invalid Transaction Code (ENR) – The transaction code in an ENR (Automated Enrollment) entry is invalid.	N/A	N/A
R42	Routing Number/Check Digit Error (ENR) – The routing number in the ENR is incorrect.	N/A	N/A
R43	Invalid DFI Account Number (ENR) – Account number in the ENR is invalid.	N/A	N/A
R44	Invalid Individual ID Number (ENR) – Individual ID (e.g., SSN or identification) in the ENR is invalid.	N/A	N/A
R45	Invalid Individual/Company Name (ENR) – The name in the enrollment is not valid/matches records.	N/A	N/A
R46	Invalid Representative Payee Indicator (ENR) – The rep payee indicator in the ENR (for government benefit) is invalid.	N/A	N/A
R47	Duplicate Enrollment (ENR) – The enrollment entry is a duplicate of one already on file.	N/A	N/A
R50	State Law Affecting RCK Acceptance – The receiver’s state law does not allow the electronic representment (RCK).	N/A	N/A
R51	Item Related to RCK Not Eligible or Improper – The item (check) cannot be represented as RCK (wrong type or already settled).	Consumer or Non-Consumer	60 Banking Days
R52	Stop Payment on Item Related to RCK – A stop payment was placed on the check that was to be represented (RCK).	Consumer	60 Banking Days
R53	Item and RCK Presented for Payment – Both the original check and RCK entry were presented (duplicate presentment).	Consumer	60 Calendar Days
R61	Misrouted Return – The return was sent to the wrong destination bank. (Dishonored return code)	Consumer	60 Calendar Days
R62	Return of Erroneous or Reversing Debit – The return is a correction for an erroneous or reversed debit entry.	Consumer	5 Banking Days (from original entry)
R67	Duplicate Return – A duplicate return was submitted for the same entry (not allowed). (Dishonored return code)	Consumer or Non-Consumer	Varies (dishonored return timeline)
R68	Untimely Return – The return was not sent within the specified timeframe. (Dishonored return code)	Consumer or Non-Consumer	Must be within 5 Banking Days (for ODFI to dishonor)
R69	Field Error – A required field in the return entry is incorrect or malformed. (Dishonored return code)	Consumer or Non-Consumer	Must be within 5 Banking Days (ODFI action)
R70	Permissible Return Not Accepted/Not Requested – The RDFI returned an entry that was not authorized or requested by the ODFI (for returns that require ODFI permission).	Consumer or Non-Consumer	Must be within 5 Banking Days
R71	Misrouted Dishonored Return – A dishonored return (ODFI’s return of RDFI’s return) was sent to the wrong place.	Consumer or Non-Consumer	5 Banking Days (to contest)
R72	Untimely Dishonored Return – The dishonored return wasn’t sent in time.	Consumer or Non-Consumer	5 Banking Days (to contest)
R73	Timely Original Return – Used by ODFI to contest an RDFI’s dishonor, claiming the original return was on time.	Consumer or Non-Consumer	5 Banking Days (ODFI response)
R74	Corrected Return – The RDFI is correcting a return entry (for example, a coding error on the original return).	Consumer or Non-Consumer	Varies (depends on situation)
R75	Return Not a Duplicate – ODFI’s response to RDFI’s dishonor, indicating the return wasn’t a duplicate.	Consumer or Non-Consumer	5 Banking Days
R76	No Errors Found (Original Return was valid) – ODFI’s response indicating the original return was valid (no errors).	Consumer or Non-Consumer	2 Banking Days (to contest R62 dishonor)
R77	Non-Acceptance of R62 Dishonored Return – RDFI’s code indicating it will not accept an R62 return (perhaps dispute resolution).	Consumer or Non-Consumer	2 Banking Days
R80	IAT Coding Error – International ACH Transaction coding error (e.g., invalid formatting in IAT specific fields).	Consumer or Non-Consumer	2 Banking Days (contested return window)
R81	Non-Participant in IAT Program – The RDFI or intermediary is not part of the international ACH program, so it cannot process the IAT entry.	Consumer or Non-Consumer	2 Banking Days
R82	Invalid Foreign RDFI Identification – Information to identify foreign receiving bank is invalid (for IAT).	Consumer or Non-Consumer	2 Banking Days
R83	Foreign RDFI Unable to Settle – The foreign bank couldn’t settle the payment (currency or regulatory issue).	Consumer or Non-Consumer	2 Banking Days
R84	Entry Not Processed by Gateway – The gateway operator did not process the entry (typically a Gateway use for cross-border).	Consumer or Non-Consumer	Varies (as specified)
R85	Incorrectly Coded Outbound International Payment – The IAT payment was miscoded (perhaps wrong format/country code) and is being returned.	Consumer or Non-Consumer	2 Banking Days

Notes: The codes R41–R47 are specific to ENR (Electronic Payment Enrollment) entries, which are used for enrolling in federal government payment programs – these have specialized usage and typically “N/A” in the account type/timeframe because they are returns of enrollment data, not monetary transactions.

The codes R61–R77 are dishonored return and contested return codes, used when there are disputes or errors in the return process itself between banks. Most end users (businesses, consumers) will rarely encounter those directly, but they exist for ACH participants to resolve return issues.

The R80–R85 series apply to international ACH transactions (IAT), covering issues unique to cross-border ACH payments.

With this exhaustive list, you can lookup any ACH return code you encounter. Next, let’s discuss how to minimize ACH returns and how to handle them effectively when they occur.

Tips to Avoid or Reduce ACH Returns

Preventing ACH returns is beneficial for everyone: it means smoother transactions for businesses, fewer interruptions for consumers, and a healthier standing with NACHA for originators. Here are some strategies to avoid common ACH return scenarios:

• Verify account information upfront: One of the biggest causes of returns is incorrect account numbers (R03, R04).
  
  Use validation tools or micro-deposits to ensure the bank account and routing numbers provided by a customer are valid and active before initiating regular payments. Verifying account ownership and status can significantly reduce R02 and R03 returns.
  
• Use account validation services or prenotifications: Many businesses send a zero-dollar ACH transaction (prenote) or use banking APIs to verify that an account can receive ACH payments.
  
  This step can catch closed or invalid accounts (preventing R02, R03) and even detect if an account has a debit block (some business accounts block ACH debits).
  
• Maintain clear and up-to-date authorizations: Ensure you have proper written or electronic authorization from customers for ACH debits. Keep these records organized.
  
  If customers make changes (e.g., cancel a subscription or revoke consent), update your records immediately to avoid unauthorized or revoked debits (R05, R07, R10). Clearly inform customers of what they are authorizing (amount, frequency, timing) to avoid misunderstandings.
  
• Notify customers before debiting accounts: A simple but effective practice is to send a reminder (email or text) a few days before a scheduled ACH debit, especially for large or infrequent payments.
  
  This heads-up allows customers to ensure funds are available and reminds them of the upcoming charge, reducing the chance of NSFs (R01) or the customer disputing an unfamiliar charge. Many companies (utilities, lenders, etc.) do this to improve payment success rates.
  
• Time your debits wisely: Schedule ACH debits on days when customers are likely to have funds. For instance, avoid days right before payday for recurring charges if possible. If a payment fails for insufficient funds (R01), some businesses will retry once, often on a date that aligns with the customer’s pay cycle.
  
• Monitor ACH return reports: Regularly review the return codes you are receiving. If you notice a pattern (e.g., multiple R04 invalid account errors), it might indicate an issue in data collection or entry that you can fix proactively (like improving your online form validation).
  
  If you see unauthorized returns creeping up, that’s a red flag to examine your authorization process or customer communication.

By implementing these preventative measures, businesses can keep their return rates low, improve customer satisfaction (fewer payment issues to chase down), and stay well within NACHA compliance limits. 

Not all returns can be avoided (for example, unexpected NSFs can happen), but reducing avoidable errors goes a long way.

Handling ACH Returns Effectively

Even with good prevention, some ACH returns are inevitable. How you handle returns when they occur is important for operational efficiency and compliance. Here are best practices for managing ACH returns:

• Act quickly and systematically: When a return comes in, have a process to identify the return code and take the appropriate next step. Many banks or payment processors will provide a daily report of ACH returns. Make sure someone or an automated system reviews these reports promptly.
  
• Differentiate your response by return code: Not all return codes are equal – handle each according to its nature:
  
  • If it’s a data/account error (e.g., R03, R04), route it to your operations team to correct the information. You’ll likely need to contact the customer for updated details (like getting the right account number or finding out new routing info if their bank merged).
    
  • If it’s insufficient funds (R01 or R09), your procedure might be to retry the debit after a short interval (say, 3–5 days) or reach out to the customer to inform them and perhaps arrange a different payment method.
    
  • If it’s an authorization issue (R05, R07, R10, R11), do not retry without resolving the issue. These should be escalated to a compliance officer or management.
    
    You may need to contact the customer to clarify the dispute or stop further billing until a new authorization is in place. Keep documentation of any communications, as unauthorized return issues can be sensitive.
    
  • If it’s account is closed or stopped (R02, R08), stop any further attempts to that account. Contact the customer to get new payment instructions or find out the reason (for stop payments, the customer might need an alternate arrangement).
    
• Automate where possible: If you handle large volumes of ACH transactions, consider using automation or ACH management software.
  
  These systems can automatically categorize returns by code, trigger email notifications to customers (for example, “Your payment was returned due to an account not found.
  
  Please update your billing info.”), and even re-initiate transactions when appropriate. Automation reduces manual errors and ensures consistency in response.
  
• Keep records of returns: Maintain a log of returns and reasons for each customer. This can help in resolving disputes and also in making decisions (for instance, if a customer frequently has R01 returns for NSF, you might require a different payment method or shorter billing interval).
  
• Monitor your return rates: As mentioned in the compliance section, keep an eye on your overall return percentages.
  
  If you see your unauthorized return rate approaching NACHA’s 0.5% threshold, take immediate action – review all recent R05/R07/R10 returns and see if there’s a common cause (maybe a flawed sales practice or a specific product causing disputes).
  
  Similarly, high administrative returns (R02–R04) might mean you need better data verification processes. Early detection can prevent problems with your bank or NACHA down the line.

By handling returns efficiently, you can reduce financial losses (e.g., recovering funds faster or avoiding repeat failed attempts) and maintain good customer relations. Remember that an ACH return often tells a story – use the code to understand why it happened and address the root cause, not just the symptom. 

For example, a spike in R01 returns might suggest sending reminders to customers about maintaining balances, while a cluster of R04 returns could mean there’s an issue with the way account info is collected on your signup form.

Now, let’s answer some frequently asked questions about ACH return codes to recap and clarify common points.

Frequently Asked Questions (FAQs)

Q1: What exactly are ACH return codes and why are they used?

A: ACH return codes are standardized 3-character codes (starting with “R”) that indicate the reason an ACH transaction was returned or failed. They are used by banks to communicate to each other and to the payment originator why a payment could not be processed (for example, R01 means insufficient funds). 

By using these codes, everyone involved can quickly understand the issue without ambiguity. This speeds up troubleshooting – the originator knows if they should retry the payment, contact the customer, or take other actions based on the code.

Q2: How many ACH return codes are there, and who maintains them?

A: As of 2025, there are 85 distinct ACH return codes defined in the NACHA Operating Rules. These codes are maintained and updated by NACHA, the organization that oversees the ACH network. NACHA periodically adds new codes or updates definitions to address new scenarios or improve clarity. 

For example, code R11 was recently repurposed by NACHA to cover errors in authorized payments (separating those from completely unauthorized returns). In general, the list ranges from R01 up to R85, covering a wide array of return reasons.

Q3: Which ACH return codes are the most common?

A: The most commonly encountered ACH return codes tend to be:

• R01 – Insufficient Funds: This is by far the most frequent return reason, accounting for roughly 40–50% of returns. It occurs when the payer’s account doesn’t have enough money for the debit.
  
• R02 – Account Closed: Common when people change banks and forget to update billing info.
  
• R03 – No Account/Unable to Locate Account: Happens often due to typos or incorrect account info.
  
• R04 – Invalid Account Number: Similar to R03, an issue with the account number’s format.
  
• Other notable ones include R07 (Authorization Revoked) and R10 (Unauthorized) for authorization-related problems, and R08 (Stop Payment) for instances where a customer actively stops a withdrawal.
  
  These are not as frequent as the account/funds issues, but they do occur regularly especially in subscription or billing contexts.
  In summary, insufficient funds and account data errors cause the majority of returns, while true authorization disputes are less common but critically important to resolve.

Q4: What should I do if I receive an ACH return code for a payment I initiated?

A: If you’re a business or individual who initiated an ACH payment and it comes back with a return code, you should:

• Read the return code and reason – this tells you what happened. (Use the list above as a reference.)
  
• Take action based on the code: For example, if it’s R01 (NSF), you might wait and retry the payment or ask for a different payment method. If it’s R02 (account closed) or R03/R04 (invalid info), you’ll need to contact the customer for updated account details.
  
  If it’s R07 or R10 (authorization issues), do not attempt again; instead, reach out to the customer to understand the situation, and get a proper authorization before any future payments.
  
• Do it promptly: ACH returns are usually received within a couple of days of your transaction. It’s good practice to address them as soon as possible – the sooner you resolve the issue (e.g., get correct info or talk to the customer), the sooner you can secure your payment. Prompt action also shows good faith and professionalism to your customer or vendor.
  
• Avoid repeat returns: Use the information from the return to prevent the same mistake. For instance, if an account was closed (R02), make sure to update your records so you’re not inadvertently sending another ACH to that closed account next cycle.
  
  For consumers who see an ACH return on their bank account (say a direct deposit returned), it often means you need to update information with whoever was trying to pay you or debit you, as something might be wrong with your account details.

Q5: Can ACH returns be prevented or reduced?

A: While it’s impossible to eliminate all returns, many can be prevented with proactive measures:

• Ensure accurate information: Double-check bank details when setting up payments – a lot of returns come from simple data entry errors.
  
• Use verification tools: As mentioned earlier, account verification services can catch invalid or closed accounts beforehand.
  
• Maintain good communication: Let customers know when to expect debits, and make sure they know what the charges are for (so they don’t mistake them as unauthorized).
  
• Monitor and fix issues: If you notice a particular cause recurring (like many NSF returns), consider adjusting your approach (perhaps smaller installments for payments, or aligning dates with paydays). If a certain segment of customers or a specific form is causing bad data, address that promptly.
  
• Stay compliant with authorizations: Always get proper authorization for ACH debits and honor any revocations or stop-payment requests immediately.
  
  By focusing on these steps, businesses have managed to keep average ACH return rates quite low (often just a couple percent or less of transactions). Reducing returns saves money on fees and improves overall efficiency.

Q6: Do ACH return codes come with any fees or penalties?

A: Yes, they can. There are a few cost aspects:

• Bank/processor return fees: Many banks or payment processors charge the originator a fee for each returned item. These ACH return fees typically range from $2 to $5 per return on average.
  
  It might not sound like much, but if you have many returns, it adds up. In some cases, particularly for chargebacks or disputes, fees can exceed $20 for a single return. Always check your bank or provider’s fee schedule for ACH returns.
  
• NSF fees to the receiver: If a consumer’s payment fails due to insufficient funds (R01), the consumer’s bank might charge them an NSF fee (often around $25–35, depending on the bank). So returns can cost the account holder money as well.
  
• NACHA compliance penalties: If an originator consistently exceeds NACHA’s return rate thresholds (especially the 0.5% unauthorized return rate), NACHA may impose fines or other sanctions.
  
  These fines can be significant, running into tens of thousands of dollars for severe or continued non-compliance.
  
• Indirect costs: There are also hidden costs – for example, the administrative time to track down payments, potential impact on cash flow (delayed funds), and customer dissatisfaction. If a payment is returned, you might have to invest resources to recover that money or resolve the situation.
  
  In short, it pays (literally) to keep return rates low – you’ll save on fees and avoid the risk of compliance penalties.

Q7: Are ACH return codes only used in the US, or do they apply internationally?

A: ACH return codes as listed are part of the U.S. ACH network (which is operated by NACHA within the United States). For international transactions, the ACH system has a specific format called IAT (International ACH Transaction). 

The return codes R80 through R85 are dedicated to international ACH return reasons (such as coding errors or issues with foreign bank identifiers). These codes come into play when a U.S. bank sends or receives an international ACH entry via a gateway. 

Outside of the ACH network, other countries have their own electronic payment systems and may not use this same “R-code” system. So, ACH return codes are primarily a U.S. concept, but the IAT mechanism extends their usage to cross-border payments that are processed through the U.S. ACH network.

Q8: What is the difference between an ACH return and an ACH rejection?

A: An ACH return refers to a transaction that was accepted into the ACH system and later returned by the RDFI with a return code (like the ones we’ve listed). A rejection typically refers to a payment that never enters the ACH system because it failed initial validation. 

For example, if you submit a batch file to your bank and it has an error (say an incorrect routing number format), the bank might reject the batch outright rather than processing it – that’s a rejection. 

Some people also casually call certain immediate returns “rejects.” In practice, if you get an R-code, that means the payment was processed and then returned (not just a file error). 

Conclusion

ACH return codes might seem like a slew of alphabet soup at first, but they are a vital mechanism that keeps the electronic payments system running smoothly. 

They provide clarity on why a payment didn’t go through and guide both banks and businesses on what to do next. From the common R01 insufficient funds to the less frequent codes in the R70s and R80s, each return code tells a story about a transaction’s fate.

For businesses and financial professionals, understanding ACH return codes isn’t just about bookkeeping – it’s about maintaining strong payment practices and compliance. Keeping return rates low by avoiding preventable errors, and handling any returns swiftly and correctly, protects your revenue and your standing in the ACH network. 

With ACH payment volume growing every year (the adoption of Same Day ACH and more electronic payments is rising fast, with Same Day ACH volume jumping 45% in 2024 alone), robust return handling is more important than ever for efficient operations.

For consumers and account holders, knowing about return codes can demystify what happened if a payment bounces back. 

Instead of a confusing situation (“my mortgage payment didn’t go through, what does this code on my statement mean?”), you can identify the issue (maybe your old account was closed or a typo in the account number) and fix it with the biller.

In summary, ACH return codes help maintain trust and order in electronic payments. By putting people first – communicating clearly and resolving issues indicated by return codes – all parties can achieve a smoother payment experience. 

We hope this complete guide to ACH return codes has been helpful, up-to-date, and easy to understand. Armed with this knowledge, you can confidently navigate any ACH return scenario that comes your way, ensuring payments get back on track quickly and correctly.