ACH Return Codes Explained: What Each Code Means

Last updated: October 2026

An ACH return code is the reason a receiving bank gives when it sends an ACH entry back to the bank that originated it. The code classifies what the account holder or the bank reported. It is not a finding about what happened. Three families matter most to an originator: insufficient funds, account status and administrative problems, and unauthorized debits, and each one calls for a different response.

TL;DR

• An ACH return code records why the receiving bank (the RDFI) sent an entry back to the originating bank (the ODFI). It classifies a claim; it does not prove fraud.

• R01 Insufficient Funds is usually a credit and collections problem. Account-status codes such as R02, R03 and R04 are validation problems that can often be caught before the first debit.

• Unauthorized codes (R05, R07, R10, R11 and R29) are authorization and fraud signals, and they count toward Nacha's 0.5% unauthorized return rate threshold.

• Nacha describes a "standard 2-day return period". Unauthorized consumer debits, such as R10 and R11, can be returned up to the banking day following the 60th calendar day after settlement.

• Record every return against the decision that allowed the payment, so the next decision learns from it.

The short answer

A return code records the reason the receiving bank gave for sending an ACH entry back. It is a classification, not a finding. An R10 says the account holder disputed authorization, not that a fraudster originated the debit, and an R01 can be a genuine customer having a bad week.

Three families of codes matter most to a business that collects or sends ACH payments:

• Insufficient funds (R01). The money was not there when the debit posted. This is mostly a credit and collections problem.

• Account status and administrative returns (R02, R03, R04, R16, R20). The account is closed, cannot be found, is malformed, is frozen, or cannot take the transaction. These are validation problems, and many can be caught before the first debit.

• Unauthorized returns (R05, R07, R10, R11, R29). The account holder says the debit was not authorized, or that permission was withdrawn or exceeded. These are the codes most closely tied to fraud, and Nacha tracks them against a separate return rate threshold.

What an ACH return is, and who sends it

An ACH return is an entry that the account holder's bank sends back, unpaid, to the bank that sent it, with a code that says why. Four parties are involved, and the return travels back along the same path the payment came:

• Originator. The business or platform that started the payment, such as a lender collecting a repayment.

• ODFI (originating depository financial institution). The originator's bank, which sends the entry into the ACH network and receives the return.

• RDFI (receiving depository financial institution). The account holder's bank. It decides whether to return the entry and picks the code.

• Receiver. The account holder whose account was debited or credited.

Nacha, which writes the operating rules for the ACH network, describes a "standard 2-day return period". In that period the RDFI makes the return available to the ODFI no later than the opening of business on the second banking day after settlement. Unauthorized debits to consumer accounts get a much longer window, covered under return time frames below.

ACH return codes by family

The table below groups the codes this guide covers. Code titles throughout are as Nacha publishes them.

Read the family before the individual code: it tells you which team should look at the return and which rate it moves.

Insufficient funds: R01

An R01 can be a genuine customer who was short that day, not a fraudster, so treat it first as a credit problem. It becomes an operations problem quickly, because a business that collects frequently can send the next debit before the first return arrives.

A technology and operations lead at a small-business lender that collects repayments daily described exactly that: by the time the first return arrives, further debits have already gone out. The lender wanted to see account status before debiting, without requiring the borrower to link the account. A director at the same lender framed the goal as being able to "prevent an NSF tailspin from occurring" before failed debits start to pile up.

R01 also creates work downstream. An associate director of risk and underwriting at a merchant payments provider said a failed debit for insufficient funds automatically opens an internal ticket and a notice to the merchant, which then becomes collections work. Treat a run of R01s as a signal to change the schedule or the credit decision, not only as a queue to clear.

Account status and administrative returns: R02, R03, R04, R16, R20

These codes say the payment could not land, not that anyone objected to it. R02, R03 and R04 together make up Nacha's administrative return rate, so a pattern of them points at how account details are collected and checked at enrollment.

Many of these returns can be caught by validating the account before the first debit rather than learning about it from the return. Validation that depends on one data source has limits: the technology lead at the small-business lender said monitoring that depends on a linked bank account stops working when the borrower disconnects it. Check the account at enrollment, and again before debits that follow a long gap.

One change is already scheduled. From 17 March 2028, Nacha's new code R90, "Entry Returned Due to RDFI's Sanctions Compliance Obligations", will be used for returns made because of the receiving bank's sanctions obligations, and R16 will revert to "Account Frozen".

Unauthorized returns: R05, R07, R10, R11, R29

The difference between R10 and R11 is whether any authorization existed. With R10 the account holder says they do not know the originator or never authorized it. With R11 they accept the relationship but dispute this entry.

These codes, together with R51, make up Nacha's unauthorized return rate. Unauthorized consumer debits, such as R10 and R11, can come back up to the banking day following the 60th calendar day after settlement. R29 covers business accounts, where an unauthorized debit must be returned no later than the opening of business on the second banking day after settlement.

Return time frames

The long consumer window is the one that catches originators out. A debit that cleared its first two banking days without a problem can still come back as unauthorized about two months later.

That window sits alongside the consumer's own protection under Regulation E. Under 12 CFR 1005.11, a consumer's notice of an error must be received no later than 60 days after the institution sends the periodic statement on which it first appears. Until Nacha's extended window has passed, treat a consumer debit as open to return and keep the authorization evidence for it.

Return rate thresholds and what they mean for an originator

Nacha publishes figures for three return rates, and it uses different words for them.

The difference in wording matters. Nacha "establishes the unauthorized return rate threshold at 0.5%", and exceeding it can bring Nacha's enforcement process. The administrative and overall figures are levels: crossing one triggers an inquiry into the originator's returns rather than counting as a threshold violation.

A rate is an aggregate, and it moves late. A director of an AML program at a pay-by-bank payments company described a fraud team that looks at "the return rates on the merchants", and added, "like they're not actually doing what I call fraud." A cluster of R10s on newly enrolled accounts can be a fraud pattern long before it moves a rate, so read the returns themselves as well as the totals.

Since 2026, Nacha's risk management rules have also required fraud monitoring from parties that previously had no such obligation; our guide to the 2026 Nacha rule changes covers what changed.

What ACH return codes reveal about fraud

The unauthorized family is the one most closely tied to fraud, but each code is still a claim. An R10 can mean a criminal used stolen account details. It can also mean the real account holder disputed a payment they made. The code alone does not say which.

R17 lets the receiving bank act on its own suspicion. Nacha allows an RDFI to return an entry as R17 when it suspects the entry is fraudulent or was originated under false pretenses, within the standard two-banking-day period. Nacha's definition of false pretenses covers a person misrepresenting their identity, their authority to act for someone else, or the ownership of the account to be credited, which includes business email compromise, vendor impersonation and payroll impersonation.

Fraud tends to show up in returns as a pattern rather than a single code:

• Account takeover and mule accounts show up as unauthorized returns spread across linked accounts, devices or recent enrollments, not as one isolated R10.

• First-party "that wasn't me" claims show up as R10s on debits the account holder actually made. These are first-party disputes, and they need a different response from third-party fraud.

• Repeat debits carry their own risk. A head of product at another pay-by-bank payments company said a repeat debit carries more risk than the first, because the customer does not go back into the banking app to authorize it, and described a rule that checks the balance between the payment request and its execution, to stop a payment that would be returned when deliberate fraud is suspected.

Returns tell you about fraud after the fact. For catching it before the money moves, see our guide to how ACH fraud detection works.

What to record when a return comes back

A return is only useful if it reaches the decision that allowed the payment. For each return, record:

1. The code and the date the return arrived, so you can see how long after settlement it came back.

2. The original entry: amount, entry type, effective date, and whether it was a first or a repeat debit.

3. The account and the customer: when the account was enrolled, how it was validated, and its earlier returns.

4. The originator or merchant, where you process payments for others.

5. The decision that let the payment through: the rule, the model score, any reviewer, and the reasoning recorded at the time.

6. Linked returns: other returns on the same account, device, customer or originator.

The last two items are the easiest to lose. A director of technical product management at a digital banking platform provider put the gap plainly: "Actually, we know what has been flagged for review, what has been accepted and rejected. But we don't necessarily get ach returns directly from them or other fraud events." Without the return, the system that approved the payment never learns that it was wrong.

Return codes also decide who carries the loss. The same head of product at the pay-by-bank payments company said the company was deciding which payments it would fully guarantee for its merchants, and that return codes were part of how it drew that line. A code recorded against the right decision is evidence for that kind of call.

Mistakes that make returns worse

• Treating every R10 as fraud. Some are first-party disputes of genuine debits. Read the customer's history before closing the account.

• Re-debiting after an R01 without checking the account. Each failed debit adds another return to the overall rate.

• Retrying R02, R03 or R04 with the same details. The account will not have changed; get new details or validate first.

• Watching only the rate. A rate below a Nacha figure can still hide a cluster of unauthorized returns on new accounts.

• Leaving returns in an operations queue. If the outcome never reaches the team or system that approved the payment, the same decision will be made again.

Where Oscilar fits

Oscilar is a Nacha Preferred Partner for Account Validation, Fraud Monitoring, and Risk and Fraud Prevention. On the payment side, Oscilar's ACH transaction fraud capability is built to "Detect unusual ACH transaction patterns, such as rapid debits and credits across multiple accounts, indicating potential fraud or kiting schemes."

The platform is specified for sub-100ms decisions, so checks can run inside the payment flow rather than after the fact. Governance is built in: a full audit trail per decision with stored reasoning, and human-in-the-loop by design. Oscilar has auto model monitoring covering data drift, feature drift and concept drift, plus outcome KPIs measured by segment.

Frequently asked questions

What are ACH return codes?

ACH return codes are the codes a receiving bank attaches when it sends an ACH entry back unpaid to the originating bank. Each code gives the reason, such as R01 Insufficient Funds or R10 for a debit the account holder says they did not authorize. The code classifies the reported reason; it does not prove what happened.

What is the difference between R10 and R11?

R10 means the account holder says they do not know the originator or never authorized it to debit their account. R11 means the account holder did authorize the originator, but says this particular entry was not in accordance with the terms of that authorization. Both are unauthorized returns that count toward Nacha's unauthorized return rate, and on consumer accounts both can be returned up to the banking day following the 60th calendar day after settlement.

What is an R17 return?

R17 is a code a receiving bank can use to return an entry when it suspects the entry is fraudulent or was originated under false pretenses. Nacha's standard two-banking-day return period applies when R17 is used. It lets the receiving bank act on its own suspicion, rather than waiting for the account holder to report a problem.

Does crossing a return rate level mean an originator is cut off?

Nacha's public pages do not describe crossing a level as an automatic cut-off. The 3.0% administrative and 15.0% overall figures are levels that trigger an inquiry, not threshold violations. The 0.5% unauthorized figure is different: Nacha calls it a threshold, and exceeding it can bring Nacha's enforcement process.

Is every R10 return fraud?

No. An R10 records that the account holder said they did not know or did not authorize the originator. That can be third-party fraud, such as a criminal using stolen account details, but it can also be the account holder disputing a debit they made. Check the customer's history and the authorization evidence before treating it as fraud.

ACH return codes are short, but each one tells you which team should act and what to fix: the credit decision, the account details, or the authorization. Record every return against the decision that let the payment through, and the next decision gets better. To see how Oscilar approaches ACH payment risk, visit our transaction fraud solution.