I’ve recently been dissecting where payments break down at scale in my latest blog posts. Next I’m focusing on ACH returns.
Even if you’re a business that only processes credit and debit card payments, you may still need to pay out merchants, vendors, or customers via ACH. Understanding ACH returns can help you improve margins, maintain a good customer experience, and run your business more efficiently.
If you’re a fintech or payment company that processes ACH payments on your customers’ behalf, understanding ACH returns and having a plan to manage them is table stakes for running your business, reducing fraud, and managing payment risk.
ACH returns can quickly become an operational problem as transaction volume increases. A return may be caused by insufficient funds, incorrect account information, an unauthorized debit, or an issue with the account itself. The right response depends on the return code, and automatically retrying every returned transaction can create additional costs, customer friction, and in some cases, compliance issues.
Here are some of the areas I recommend focusing on when building an ACH return management process.
Understand ACH return codes and what to do about them
One of the first things I look at when reviewing an ACH program is whether the business is actually using the return code to determine what happens next.
Not every ACH return should be handled the same way. The return reason provides important information about what happened and whether the transaction can be reprocessed.
Unauthorized returns: R05, R07, R10, R11, R29 and R51
Unauthorized returns require particular attention because they can affect your fraud exposure, customer experience, and Nacha return-rate monitoring.
If you receive an ACH return related to an unauthorized transaction, you should not simply retry the payment. You need to understand why the transaction was returned and, where appropriate, obtain a new authorization before originating another debit. Nacha specifically prohibits reinitiating an unauthorized debit unless a new authorization is obtained after the return.
Some of the more common unauthorized return codes include:
R05: Unauthorized debit to a consumer account
This generally means the transaction was not authorized by the account owner. It also provides additional context that you attempted to debit a business account, but the account is actually a consumer account.
This should raise a flag if your merchant is an LLC or corporation. It could indicate that you are actually debiting the business owner’s personal account rather than the account of the business with which you have an agreement.
Pay close attention to this if your customer says the account information is correct and you plan to send additional debits or credits to the account. Consumer accounts have different return timeframes for unauthorized transactions, so you can inadvertently expose yourself to a longer return window than expected. Unauthorized consumer debits can generally be returned for up to 60 calendar days.
R07: Authorization revoked by consumer
You’ll see this return code when the account owner acknowledges that they had a relationship with you or your merchant but states that they terminated that relationship and the charge is no longer authorized.
R10: Customer advises Originator is not known or not authorized
You’ll see this type of return when the customer does not recognize the business debiting their account or says they did not authorize the debit.
Make sure your customers know how the charge will appear on their bank statement. Providing the correct company name can help reduce confusion and unnecessary unauthorized returns.
R11: Customer advises Entry not in accordance with the terms of the authorization
R11 is important because it is different from a customer saying they have no relationship with the Originator. It can apply when an authorization exists but the transaction does not comply with its terms, such as an incorrect amount or incorrect date.
This can be a useful signal that there is a problem with your payment logic or how your system is applying customer authorization.
R29: Corporate customer advises not authorized
This is used when a business account owner says the debit was not authorized. It can also be associated with a debit block.
If the return happens very quickly, it is worth investigating whether a debit block or other bank-level control is involved. Providing your ACH Company ID to your customers in advance can help them authorize your company to debit their account.
Nacha currently sets the unauthorized return rate threshold at 0.5% and includes R05, R07, R10, R11, R29, and R51 in the calculation. Nacha provides two methods for calculating the rate based on returns and originated debits over the preceding 60 days or two calendar months.
Read Nacha’s guidance on calculating the unauthorized ACH return rate.
Insufficient funds: R01 and R09
R01 means insufficient funds and R09 means uncollected funds.
These returns generally mean the funds were not available when the transaction was presented.
Nacha allows a returned debit for insufficient or uncollected funds to be reinitiated a maximum of two times, and the reinitiation must occur within 180 days of the original settlement date.
Even when you are allowed to retry the payment, I recommend reaching out to the customer first when possible. Getting a commitment on when funds will be available can reduce the chance of another return and provide a better customer experience.
If you have an automated retry process and have limited ability to contact your customer, you may want to consider the timing of your retries based on your customer base and when they typically receive funds. For example, payroll-driven businesses may have different funding patterns than businesses that receive customer payments throughout the month.
Administrative returns: R02, R03 and R04
These returns generally indicate that the account is closed or that there is an issue with the account information provided.
It is usually better to confirm the correct account information with your customer before reprocessing the transaction. Otherwise, you are likely to generate another return and incur another fee.
Nacha also uses R02, R03 and R04 when monitoring the administrative return rate, with a 3.0% return rate level that can trigger a preliminary inquiry.
Work with external partners to validate account information
If you are not validating account information before processing certain ACH transactions, you should understand exactly what your Nacha obligations are and what additional risk you are taking on.
For example, Nacha’s WEB debit rules require a commercially reasonable fraud detection system that includes account validation when a consumer account is used for the first time or when the account number changes. Nacha does not require a specific validation method. Options can include prenotification, micro-entry verification, or a third-party account validation service.
There are also many situations where account validation can make sense even when it is not specifically required.
Depending on your business model, you may want to validate that the account is open and able to receive ACH transactions. For higher-risk customers, it may also be beneficial to perform additional checks, such as confirming that the account belongs to the intended customer.
The right level of validation depends on your customer, payment flow, risk profile, and the type of ACH transaction you are originating.
Prevent repeat ACH returns
Every return costs money, and at scale those costs can eat into your margin if repeat returns are not managed properly.
After an ACH return, it is worth understanding why the payment failed before automatically trying again. In some cases, you may be violating a Nacha rule by reinitiating the transaction. In others, you may simply be creating another return and a poor customer experience.
Your system should use the return reason code to determine what happens next rather than treating every return as another opportunity to retry the same transaction.
Capture good authorization data
When you are responding to a proof-of-authorization request, it is important to show the exact agreement the account owner accepted and demonstrate that it applies to the transaction in question.
You’ll need supporting evidence that helps the bank connect the transaction to the customer authorization.
Depending on your payment flow, it can be helpful to retain information such as:
- The authorization language presented to the customer
- The date and time of authorization
- The transaction amount and date
- Login information
- IP address
- Relevant customer actions taken during the authorization process
- Previous successful payments
- The account information associated with the authorization
The more information you can provide to support your narrative, the easier it is for your bank or payments partner to understand what happened and respond to the request.
This is one of those areas that is easy to overlook when a payment product is being launched and much harder to fix after you have millions of transactions flowing through the system.
Give customers help articles that explain why the return happened
Many companies have help articles explaining how to make a payment but very little information about what to do after a payment fails.
Your customers rely on your platform to help them understand what happened.
A useful return help article should provide a brief explanation of the return reason and tell the customer what they need to do to fix the problem within your ecosystem.
For example, if an account is closed, tell the customer what information they need to update.
If the return is related to insufficient funds, explain when they can retry the payment.
If the customer does not recognize the debit, explain how the charge appears on their bank statement and how they can contact support.
Good return messaging can reduce support volume while also improving the customer experience.
Understand what ACH returns cost you
There usually isn’t a lot of scrutiny over the cost of ACH returns when payment contracts are being negotiated, and return fees can often be buried deep within those agreements.
There can also be multiple fees associated with an ACH return depending on your bank, processor, or other payment partners.
When building your payments reporting, make sure you understand how returns are actually being charged under your contracts.
It is often helpful to review your statements alongside your transaction-level reporting so you can identify exactly what you are paying for returns and other payment exceptions.
At scale, this becomes more important because a few dollars per return can become a meaningful expense when multiplied across thousands or millions of transactions.
Check for problematic accounts across your entire platform
If you encounter an ACH return and know that you will not be able to successfully process another transaction to that account, make sure the account is blocked across your entire platform where appropriate.
As companies scale, I often see issues addressed within one business unit while the same account or customer is still allowed to transact through another part of the business.
Your risk controls should be connected across the areas of your platform where the same customer or bank account can be used.
Work with your financial institution to identify return patterns
Your banking partners are held to many of the same ACH Network standards that you are, and they can be a valuable source of information when you are trying to reduce returns.
Ask your relationship manager whether they are seeing patterns across similar customers or industries.
Depending on the information available to them, it can be useful to look for patterns related to bank account information, account types, transaction characteristics, or other attributes associated with higher return rates.
Larger financial institutions may also have other customers in your industry and may be able to point you toward products, controls, or processes that have worked elsewhere.
The relationship should not only be about processing payments. Your bank can also be a source of operational and risk-management insight.
Know who your worst offenders are
ACH returns should be tracked across your business and at the customer level.
It is important to understand whether your return rate is being driven by a handful of customers or whether you have a systemic issue across your platform.
That distinction can completely change how you approach the problem.
If a small number of customers are responsible for a disproportionate share of your returns, you can investigate those relationships individually and work with them to understand the underlying cause.
If returns are distributed across your entire customer base, you may have a problem with your onboarding, account validation, payment experience, product design, or payment operations.
If you have customers with consistently high returns and they are not willing or able to reduce them, it may be time to reconsider the relationship.
Understand NOCs and how to handle them
A Notification of Change, or NOC, occurs when the information provided in an ACH entry needs to be corrected and the RDFI provides updated information rather than simply returning the payment.
When you receive an NOC, you need to update the corrected account information before sending another applicable entry to the account, subject to the specific Nacha requirements. Nacha’s rules require Originators to make the specified changes within the applicable timeframe.
This is one of the useful features of the ACH system. The receiving bank has provided corrected information without necessarily disrupting the payment flow.
Make sure your systems actually capture and apply NOCs rather than simply storing them somewhere that Operations has to manually review later.
Don’t let problematic accounts and customers back onto your platform
Be sure to maintain a “do not process” list where appropriate. Before paying a vendor to validate an account, check your own records. You may have already seen that account or customer before.
If you have terminated a relationship or denied an application because of high returns, fraud, or other payment-risk issues, make sure that customer cannot simply create another account and start processing again.
As your business grows, this becomes increasingly important. A risk decision is only useful if it follows the customer across the platform.
ACH returns should be an operating metric, not just a payment exception
ACH returns can tell you a lot about how well your payment program is operating.
They can identify problems with customer onboarding, account validation, authorization, fraud controls, payment timing, customer communication, pricing, and even individual customer relationships.
The companies that manage returns well generally have visibility into the problem at several levels:
- Return rate by return code
- Return rate by customer
- Return rate by product
- Return rate by Company ID
- Return rate by payment partner
- Cost per return
- Repeat return rate
- Time to resolution
- Unauthorized return rate
- Administrative return rate
- Overall return rate
The goal is not simply to have fewer returns. It is to understand why returns are happening and build the operational processes and product controls to prevent them from happening again.
If you’ve noticed an uptick in ACH returns, seen your margins decline, or realized you’re not properly protecting your business, schedule a free consultation. I can help you review your ACH return process, identify the biggest sources of risk and cost, and build a plan to improve the program.