ACH return codes are the two-character "R" reason codes a receiving bank attaches when it sends an ACH entry back unpaid, telling the originator why the payment failed. The published list runs from R01 (Insufficient Funds) to R85 (Incorrectly Coded Outbound International Payment), and each code carries its own deadline and its own rule about whether the payment can be tried again.
​

The codes matter beyond a single failed payment. Nacha, the organization that writes the ACH Network rules, tracks every originator's return rates against a 0.5 percent unauthorized threshold, a 3.0 percent administrative level, and a 15.0 percent overall level. A payments team that reads return codes carefully can fix bad account data, stop retrying payments it is not allowed to retry, and stay clear of those limits.
​

This guide groups all the codes by what actually went wrong, then covers time frames, re-presentment, return-rate math, and practical fixes for the codes that show up most often.
​

ACH return codes are standardized reason codes defined in the Nacha Operating Rules. When a receiving bank cannot or will not post an ACH debit or credit, it returns the entry with one code that explains the failure, such as insufficient funds, a closed account, or a customer saying the debit was never authorized.
​

Every ACH payment involves an originator (the business sending the entry), an Originating Depository Financial Institution or ODFI (the originator's bank), and a Receiving Depository Financial Institution or RDFI (the receiver's bank). The RDFI generates almost all returns. As East West Bank's August 2024 return guide puts it, the code is determined in part by the Standard Entry Class (SEC) code, with consumer entries usually coded PPD and corporate entries coded CCD.
​

Returns are different from a Notification of Change (NOC). A return means the money moved back. An NOC means the payment posted but some detail, like an account number, should be updated before the next entry. For how ACH compares with other rails on timing and finality, see payment rails explained and ACH vs wire transfer.
​

Most ACH returns must reach the originator's bank within two banking days of settlement. The main exception is unauthorized debits to consumer accounts, which the receiving bank can return for up to sixty calendar days. A handful of formatting codes must go back by the next file delivery time.
​

The two-day window covers the most common operational codes. R01, R02, R03, and R04 all carry a two-banking-day time frame, which is why failed payments from bad data or low balances usually surface within the same week. Increase's ACH documentation states that debits to commercial accounts can be returned within two business days, while consumer accounts get sixty calendar days.
​

The long window applies to what Nacha calls extended returns. Nacha confirms that R10 and R11 returns both use a 60-day timeframe, and East West Bank lists R05, R07, R10, and R11 as extended returns that require a Written Statement of Unauthorized Debit signed by the account holder. That written statement is what lets a consumer dispute a debit weeks after it posted.
​

Corporate customers do not get the long window. The same East West Bank guide explains that a non-consumer ACH debit can be returned as unauthorized only until midnight of the business day after the bank posts it, which is why R29 (Corporate Customer Advises Not Authorized) sits in the two-day group. Businesses that receive debits need daily account review to catch unauthorized pulls in time.
​

The ACH return code list is easier to work with when codes are grouped by root cause rather than number. Funds codes point to balance problems, account codes point to bad or stale data, authorization codes point to disputes, and formatting codes point to file errors the originator or its bank must fix.
​

The tables below cover every active code in the published reference. Code titles and time frames follow Modern Treasury's R01 to R85 reference; originator actions for the common codes follow East West Bank's return processing guide. "Varies" means the time frame is set by the specific return or dishonor procedure rather than a single deadline. Gaps in the numbering (R48, R49, R54 to R60, R63 to R66, R78, R79) are codes that are not in the current list.
​

Only a few ACH return codes allow the originator to send the same payment again. Insufficient and uncollected funds returns can be reinitiated a limited number of times within a fixed window, stopped payments need fresh authorization first, and most authorization and account returns mean the originator must stop.
​

The core rule is narrow. Increase documents that a debit returned R01 or R09 can be reinitiated a maximum of two times, and that all reinitiation must happen within 180 days of the original settlement date. Past 180 days, collection has to happen outside the ACH Network. A stopped payment (R08) can be reinitiated only if the originator gets a valid new authorization from the receiver.
​

Reinitiated entries also have to be labeled. Nacha's risk and quality rules fact sheet states that the rules require RETRY PYMT in the Company Entry Description, and Increase notes the retry must carry identical information to the original except where a change corrects an error or enables processing. That label tells the receiver and the RDFI the entry is a permitted retry, not a new charge.
​

R11 has its own path. Nacha allows an originator that receives an R11 to correct the error and resubmit within 60 days without a new authorization, because the customer did authorize the payment and only disputed a detail such as the amount or date. That exception does not apply to errors involving ineligible source documents or missing required notices.
​

Nacha monitors each originator's debit returns against three measures: an unauthorized return threshold, an administrative return level, and an overall return level. Crossing the unauthorized threshold can lead to enforcement, while crossing the other two levels starts an inquiry that can escalate if rates stay high.
​

The unauthorized threshold was tightened a decade ago. Nacha's enforcement page records the cut from 1.0 percent to 0.5 percent, and it applies to debits under any SEC code, not credits. R11 was folded in later: Nacha states R11 returns count toward the unauthorized entry return rate, with R11 usage effective April 1, 2020.
​

The administrative and overall levels work differently. Exceeding the 3.0 percent administrative level does not automatically trigger enforcement; it opens a preliminary inquiry. According to Nacha's fact sheet, the ODFI then has 30 days to bring the rate down and must keep it down for another 180 days, or the case moves to the National System of Fines.
​

Because the unauthorized threshold is measured in fractions of a percent, a merchant running a large recurring-debit program can cross it with a surprisingly small number of disputes. That is the practical reason to watch R10 and R07 counts weekly rather than waiting for a bank to call.
​

Most ACH returns trace back to a short list of causes: low balances, stale or mistyped account data, revoked or disputed authorizations, and file formatting errors. Each has a specific fix, and applying the right one keeps retries legal and return rates inside Nacha's limits.
​

These are balance problems, not data problems. The East West Bank guide says the originator may initiate a new entry within 180 days of the original settlement date. Common practice is to time the retry around the customer's likely pay date instead of retrying the next morning, and to cap retries at the two-retry limit. Every retry that fails again still counts toward the overall return rate.
​

All three count toward the 3.0 percent administrative level. The fix is upstream. Validate account and routing numbers when a customer enrolls, flag the account on file after the first return, and stop initiating entries until the receiver supplies corrected or new details. Sending the same entry to a closed account again only adds another administrative return.
​

These are the codes that threaten the 0.5 percent threshold. For R07, the originator must stop until a new consumer authorization is obtained. For R10, the same guide notes that a timely R10 leaves no further recovery path under Nacha rules, so the dispute moves to the originator and the customer directly. Clear billing descriptors, advance notice of debit amounts, and an easy cancellation path reduce these returns more than any back-office process.
​

R11 means the customer agreed to be debited but something about this debit was off, such as the amount or date. Nacha lets the originator correct and resubmit within 60 days without a new authorization. Root-cause it quickly, because R11 still counts toward the unauthorized return rate.
​

An R16 can signal an OFAC-related freeze and should go to compliance, not collections. An R20 usually means the customer supplied an account that does not allow ACH debits. In both cases East West Bank's guidance is to stop initiating entries.
​

Duplicates usually come from a file sent twice. The originator should accept the return, and can reverse an erroneous or duplicate entry up to five business days after settlement. Idempotency checks on file generation prevent the problem at the source.
​

Good return handling is a routing problem: each code should trigger a predefined action in the billing or treasury system. Balance codes go to a retry queue, data codes go to customer outreach, authorization codes stop the payment method, and formatting codes go to whoever builds the ACH file.
​

Speed matters because deadlines stack up. East West Bank asks business clients to report the common return reasons within 24 hours, and a bank that mishandles a return can have it dishonored with codes such as R68 (Untimely Return), R67 (Duplicate Return), or R62. Those dishonor and contested-dishonor codes (R61 to R77) are handled bank to bank, but the originator's records decide who wins.
​

Returns also have to be matched back to open invoices so receivables stay accurate. Teams that already automate remittance matching can extend the same rules to return files; see cash application automation for how that matching works. A weekly report of returns by code, as a share of total debits, gives an early read on whether the program is drifting toward any of the three Nacha limits.
​

Eco builds payment infrastructure for businesses moving money across rails, and the same discipline of mapping every failure reason to an action applies wherever funds settle.
​