ACH Payment Return Codes and What Each Means for AR Teams

ACH payment return codes tell accounts receivable teams what to do next when a payment fails. The useful split is into three buckets, which are funding failures, account-data errors, and authorization disputes. Each has a different recovery path and different compliance stakes.

Why ACH return codes are an operational problem, not just a payment error notification

A return lands in the queue, and an invoice that was supposed to close reopens. DSO climbs, and someone must decide whether to retry the debit, request new banking details, or pull authorization records. The code determines which path is available. Treating it as a generic failure notice skips the decision that governs everything afterward.

Retrying a prohibited entry can break compliance rules, while treating a data error as a dispute holds up a payment that could go through with the right information.

The work also extends beyond the bank’s return fee. Collections teams spend hours getting updated bank details and logging exceptions, often while other payments wait in the queue for the same account. A workflow that logs the return but does not resolve its cause leaves that work unfinished. The team must therefore first determine what failed and what must change before another debit can proceed.

How the ACH return mechanism works and what the three-letter code actually represents

The Receiving Depository Financial Institution, or RDFI, is the customer’s bank and assigns the return code. It routes the code back to the Originating Depository Financial Institution, or ODFI, which relays it to the originator. The assigning bank’s reason for returning the payment directs the follow-up.

Before that happens, the originator submits the payment, the ODFI batches and validates it, the ACH operator routes it, and the RDFI posts it. A return is a separate exception process after settlement, typically within two banking days for most codes. The ODFI also bears warranty obligations under NACHA rules, including responsibility when incorrect account details came from the submitter.

There are 85 distinct codes, from R01 through R85, but most AR teams encounter fewer than ten in everyday B2B collections. Each is an R followed by two digits. The first bucket is for a valid account that has too little money available.

Funding failures: R01 and R09, the retryable codes that still carry hard limits

Funding failures are the most frequent return category in B2B collections. R01, Insufficient Funds, means the account was open and valid, but its available balance could not cover the debit when processed. Its standard return window is two banking days from settlement.

R01 permits up to two retries within 180 days of the original return date. A third retry violates NACHA operating rules even if the customer now has enough money. That is the trap. A recovered balance does not replenish the retry allowance, and “perhaps this time” is not a compliance policy.

The recommended response is to wait three to five business days before retrying, allowing time for the customer to fund the account. When R01 returns keep coming from the same account, the team should contact the customer before trying again. They can also precede R02, Account Closed, so exhausting the retry allowance is no substitute for finding out what changed. R01 does not count toward the unauthorized return rate because insufficient funds are not an authorization dispute.

R09, Uncollected Funds, makes a narrower distinction. The book balance is sufficient, but payment holds leave too little available for the debit. Its standard return window is also two banking days. Retry is appropriate once the hold clears, typically in one to two business days.

Account-data errors: R02, R03, R04, R13, and why these are preventable at onboarding

R02 means the customer or the RDFI has closed the account, commonly because the customer switched banks without updating payment details. Its standard return window is two banking days. The response is to collect new banking information immediately, because every pending payment to that account will also bounce. Waiting will not reopen it.

R03, No Account / Unable to Locate Account, means the account number is structurally valid but does not match an account at the receiving bank, or the entry’s name does not match the account. Transposed digits, missing digits, and old information from a prior system are common causes. R04, Invalid Account Number, fails an earlier test. Its number has the wrong structure, such as an invalid length or failed check-digit validation, so matching cannot begin.

Both codes have a standard two-banking-day return window. For R03, the team should confirm the routing number, account number, and account holder name with the customer and request a voided check. For R04, the team also needs the correct account number and a voided check before it sends a corrected entry.

R13, Invalid ACH Routing Number, means the routing number does not identify a valid, ACH-participating institution. Its return window is the next file delivery time following processing. The remedy is to verify the number against the ABA routing directory, confirm it with the customer, and submit corrected information.

R02, R03, and R04 count toward NACHA’s administrative return rate. A rising rate signals an upstream validation problem. NACHA’s 2021 account validation rule for WEB debits requires pre-origination validation to reduce R03 and R04 returns. Better onboarding addresses this bucket, but the next one asks a different question entirely, namely whether the debit was authorized.

Authorization disputes: R07, R10, R11, R29, and the codes that prohibit retry entirely

When authorization-related returns arrive, the team must stop trying to collect the payment. The first task is to secure the authorization records and distinguish a genuine dispute from a mismatch in payment terms. Where a corrected or future debit is possible, the underlying authorization problem must first be resolved.

R07, Authorization Revoked by Customer, means a consumer has taken back permission they gave before. The return window extends to 60 calendar days from settlement. A new agreement must establish authorization before any future debit. R10, Customer Advises Not Authorized, also has a window of up to 60 calendar days, but means the account owner has signed a Written Statement of Unauthorized Debit. It is a leading fraud indicator in high-volume origination and requires immediate internal escalation for authorization documentation.

R11, Entry Not in Accordance with the Terms of Authorization, is different. Permission exists, but the debit departs from its terms, perhaps through the wrong amount or date. The team should review the agreement, identify the discrepancy, and correct the entry under a corrected authorization. R11 is still part of the unauthorized return rate.

R29, Corporate Customer Advises Not Authorized, is the B2B equivalent of R10, with a shorter return window of two banking days. In B2B collections, it more often reflects a treasury debit block or a payment that differs from the contract’s amount or date than fraud. For example, a block on the corporate account can trigger R29 even where a written service agreement exists. The team should first contact the customer’s treasury function, check for a block, and compare the payment with the agreement. Authorization must be re-established before origination resumes.

R05 means a corporate CCD transaction went to a consumer account without authorization. Its return window is 60 calendar days, and the SEC code must be corrected before any resubmission. R08, Payment Stopped, instead applies to one transaction. It has a two-banking-day window and allows retry only after the stop is explicitly lifted. Unlike R05, R07, R10, R11, and R29, R08 does not count toward the unauthorized return rate.

R16, Account Frozen, also requires stopping. It has a two-banking-day return window and can reflect bank action, legal action, or an OFAC restriction. An OFAC-related freeze is a sanctions signal. In that context, the originator has an obligation to screen payers against OFAC before origination.

NACHA's three return rate thresholds and what each one requires when crossed

NACHA measures returns against three separate thresholds over a rolling 60-day window. The overall return rate is the broadest because it includes all the codes. Exceeding it opens a preliminary inquiry. It points to a portfolio-wide problem that cannot be understood from one returned invoice.

The administrative rate is the moderate limit and covers R02, R03, and R04. Crossing it also opens a preliminary inquiry, with account validation practices in focus. The unauthorized rate is the tightest limit. It includes R05, R07, R10, R11, R29, and R51, and is a hard threshold. In the most serious cases, NACHA can suspend a company’s ability to originate ACH entries.

Funding returns count toward the overall rate, administrative errors have their own measure, and the rules are strictest for the listed authorization codes. Each rate divides returns in the applicable category by total debits processed in the preceding period. A thin origination base reaches the limits faster than a larger one with the same return count.

Correcting payment terms does not make the original unauthorized return disappear from the measurement. Prevention is the route to reducing that rate. The June 2026 changes bring that approach to the stage before the next payment originates.

What NACHA's June 2026 fraud monitoring rule changes require AR teams to do differently

NACHA’s fraud monitoring amendments extend risk-based monitoring requirements to all non-consumer originators through a two-phase rollout. The June phase covers those not already included in the earlier large-volume phase. Its stated effective date falls on a federal holiday, so the next banking day is when compliance must be in place.

Rising R10 and R29 rates need prospective review before a threshold is breached, rather than attention only after another return arrives. Tracking code frequency and flagging upward trends in unauthorized returns therefore serves a compliance purpose. Teams still need to check an R29 pattern for debit blocks and contract mismatches before calling it fraud.

This shift builds on the WEB debit account validation rule, which moved checks to the pre-origination stage. NACHA made that rule effective in 2021, with enforcement extended into 2022 for entities working in good faith toward compliance. The June amendments add fraud monitoring to that upstream direction. A return is no longer only a problem to resolve after settlement. Its pattern also informs decisions about future originations.

The AR workflow that maps each code bucket to the right response before time runs out

The workflow must branch at the code immediately, rather than send every return through the same logging-and-email routine. For funding failures, the workflow needs a timer and a retry counter. When an R01 repeats, the team should contact the customer before using another retry and follow the recommended three-to-five-business-day wait before resubmission. A flag in the system should block a third retry. R09 instead depends on the hold clearing.

For account-data errors, the team should collect corrected information before touching the payment. That means confirming bank details with the customer, requesting a voided check where appropriate, and updating the ERP account record before creating a new transaction. Correcting the payment while leaving stale data in the record invites another return. Tracking administrative returns by customer and data source also helps expose an onboarding channel producing clusters of R03 and R04.

For authorization-related returns and freezes, the sequence is stop, document, and escalate. The team should pull authorization records within hours, log unauthorized returns as compliance events, and fix what caused the return before sending any future entry that the rules allow. R29 calls for checking the debit block and contract terms first. R11 calls for identifying the amount or date discrepancy, correcting it, and obtaining refreshed authorization.

Missing bank details, portal friction, and gaps in customer communication belong inside this workflow. Persistent follow-up is part of resolving the return. With many codes arriving within a two-banking-day return window, time spent routing an exception to the wrong response is time unavailable for fixing its cause.