ACH Return Codes R01–R29 and NOCs: The Correction Playbook

An ACH debit promises the money is there, the account is open, and the customer still wants you to take it. An unauthorized consumer debit can come back sixty calendar days after settlement, long after you counted the money as yours. The rails are compared in the ACH vs FedNow vs wire vs RTP playbook; this article is the operation that runs on top of them.

The cast: who sends a return, and who pays for it

The originator asked for the money. The ODFI, the originator's bank, sends the entry and warrants the debit is authorized. The RDFI, the receiver's bank, posts the entry or sends it back with a code. When a return lands, the ODFI debits the originator, who holds the loss, the fee, and the follow-up. Nacha writes the rules but is not a regulator: they bind participants through bank agreements, and the ODFI answers for its originators.

The eight codes that run your returns desk

Windows run from the settlement date; a banking day excludes weekends and federal holidays. R05, R07 and R10 require a written statement of unauthorized debit from the receiver before the RDFI may return the entry. R29 is the corporate twin of R10, on the two-day clock. R04 counts with R02 and R03 toward the 3% administrative level; R09 shares R01's retry rights. R11, entry not in accordance with authorization terms, also counts as unauthorized since April 2020.

R01: insufficient funds — the only code you may retry

R01 is the most common return code on the network, and the most forgiving.

The account is real, open, and correctly identified; it simply did not hold enough available money when the debit was presented. Nothing about the authorization is in question, so Nacha lets you try again — at most twice, within 180 days of settlement. Each retry must carry the same company name, company ID and amount as the original, with RETRY PYMT in the company entry description field. Retrying the morning after usually fails the same way. Retry after a likely payday — the 1st or the 15th — and tell the customer first.

Suppose 1,000 debits of $85 return R01 in a month — an $85,000 hole — and assume 40% clear on the first retry and 25% of the rest on the second:

Run your own volume through the profit calculator first.

R02 and R03: your data is the defect

R02 says the account was open once and has since closed. R03 says the account number passed structural checks but matches no open account for the person named — a transposed digit, or a number typed from memory. Neither is a funding problem, and neither may be retried: stop originating to that account and contact the receiver for a different account and a fresh authorization. Every R02 and R03 is a data failure. With R04 they make up the administrative return rate, held to 3%. The fix is upstream: validate the account before the first debit. Nacha's guidance names the accepted methods — prenotes, micro-deposits, or a commercial verification system — and WEB entries require a commercially reasonable fraud-detection method.

R05, R07, R10, R29: the unauthorized family and the sixty-day clock

The unauthorized family is where returns stop being an operations problem and become a compliance problem. R05 is a corporate-format debit (CCD or CTX) posted to a consumer account without authorization. R07 is a customer who authorized you once and then revoked it. R10 is a customer who says you were never authorized at all. R29 is the same claim from a corporate receiver, on the short two-day clock. The three consumer codes carry a sixty-calendar-day return window, and the RDFI must hold a written statement of unauthorized debit before returning the entry. The burden of proof sits on the originator, and the authorization must be a writing signed or similarly authenticated by the consumer under Regulation E, 12 CFR 1005.10(b). Once a consumer tells the bank the authorization is no longer valid, the bank must block all future debits from that payee-originator, not just the next one. For the reconciliation work that follows any return, see the automated bank reconciliation playbook.

R08: the stop payment, and Regulation E's three-day rule

R08 is the receiver telling the bank to stop one specific debit — not a revocation, and not a claim the debit was unauthorized. The consumer's right sits in Regulation E, 12 CFR 1005.10(c): a consumer may stop payment of a preauthorized transfer by notifying the bank orally or in writing at least three business days before the scheduled date. An oral order may require written confirmation within 14 days; unconfirmed, it stops being binding after 14 days. For the originator, R08 has one lawful retry path: the debit may be reinitiated only if the receiver separately authorizes the reinitiation after the return, and the receiver should also tell the bank to lift the stop.

The three thresholds: 0.5%, 3%, 15%

Nacha measures three return rates per originator, over the preceding sixty days or two calendar months. The unauthorized rate counts R05, R07, R10, R11, R29 and R51, and the threshold is 0.5%. The administrative rate counts R02, R03 and R04, and the level is 3%. The overall rate counts every debit return except RCK entries, and the level is 15%. Breaching 0.5% unauthorized is a breach of the rules, and Nacha's enforcement process follows. Breaching 3% or 15% is not itself a violation; it opens a preliminary inquiry in which Nacha writes to the ODFI, the ODFI answers with evidence, and an industry panel decides whether to direct a reduction. When the rule took effect in September 2015, network averages were 0.03% unauthorized, 0.33% administrative and 1.42% overall (2013).

At 100,000 debits in sixty days, the 0.5% line allows 500 unauthorized returns. At 480, one bad batch of 30 takes the count to 510:

NOCs: the correction that is not a return

A notification of change is the return's quiet sibling. The payment went through, but a field in the entry was wrong or outdated, and the RDFI sends a NOC telling the originator what to fix. The common change codes, each beginning with C, are: C01 incorrect account number, correct the account number; C02 incorrect routing number, correct the routing number; C03 incorrect routing and account numbers, correct both numbers; C04 bank account name change, correct the account holder name; C05 incorrect transaction code, correct the checking vs savings designation; C06 incorrect account number and transaction code, correct the account number and designation; C07 incorrect routing, account, and transaction code, correct all three fields.

Nacha's guidance states the deadline: correct the record within six banking days of receiving the NOC, or before the next entry to that account, whichever is later. Ignoring a NOC is how an R03 is born: the next entry goes out with the old number, the RDFI returns it, and a free correction becomes a failed payment.

Reinitiation: the three lawful cases

Nacha permits reinitiation in three cases only. First, insufficient or uncollected funds (R01 or R09): up to two reinitiations within 180 days of the original settlement date, same company name, company ID and amount, with RETRY PYMT in the company entry description. Second, a stop payment (R08): only if the receiver separately authorizes the reinitiation after the return. Third, any return where the originator fixed the reason — an R03 or R04 retried with corrected account information, which is not a reinitiation of the same entry. Everything else is prohibited. A debit returned as unauthorized may not be reinitiated at all, and a debit returned because the account is frozen (R16) may not be reinitiated either. Four situations are not reinitiations: the next scheduled debit under a standing preauthorization, a new debit under a new authorization, a corrected-account retry after R03 or R04, and a retry after R11 once the entry meets the original terms. Changing the amount, company name, or description to make a retry look new is an improper reinitiation, returnable as R10 within sixty days.

The enforcement ladder: what a breach actually costs

For the administrative and overall levels, Nacha opens a preliminary inquiry: it writes to the ODFI, the ODFI answers with evidence, and the case closes or goes to a panel that may direct a reduction. The ODFI then has 30 days to comply, and Nacha monitors for 180 more days. Over 0.5% unauthorized, the ODFI must file a plan to get below it within 30 days, with Nacha watching for 180 days after. Fines come only at the conclusion of an enforcement proceeding, decided and assessed by the industry review panel. Fines land on financial institutions, not originators directly — but banks may pass them on contractually, and most origination agreements allow it. The ceiling in Nacha's originator guidance is $500,000 per month for egregious violations. The reserve and holdback mechanics that follow a risk event are covered in the merchant account reserve and holdback playbook.

The federal corner: 31 CFR Part 210 and benefit reclamations

Title 31 CFR Part 210 governs federal participation in ACH and incorporates the Nacha Operating Rules by reference. The overlay bites hardest after a beneficiary dies. An agency learning of a recipient's death or incapacity must start a reclamation within 120 calendar days, and may not reclaim any payment made more than six years before the notice. The RDFI is liable for benefit payments received after the death or incapacity of a recipient, and proper use of return codes R14 or R15 counts as notice of the death to the agency. Reversals are separate: an erroneous file may be reversed within five banking days of settlement, only for the errors the rules allow. Failure to fund is not an error.

Who this playbook is for — and who must not use it

This playbook is for whoever owns an originator's ACH operation: the payments manager, the controller, the operations lead, or the developer building the retry queue. It is not a consumer guide to disputing a debit, and it is not legal advice. It is also the wrong document for a business that has not yet originated a debit: authorization capture and validation are cheaper to build before the first file than after the first R10.

Run the returns desk: execution checklist

1. Pull the return file every morning. Reconcile each return to its original entry by trace number, date, amount, and account.
2. Code the queue by clock. Separate the sixty-day unauthorized returns from the two-day returns; work the sixty-day pile first.
3. Stop unauthorized debits immediately. Suspend origination to any account with an R05, R07, R10 or R29 return until a new written authorization is on file.
4. Apply every NOC the same day. Update the stored record within six banking days of receipt, and hold the next debit until the correction is applied.
5. Compute the three rates weekly. Unauthorized, administrative and overall, per Company ID; flag any rate within 20% of its line.
6. Schedule R01 retries after payday. First retry after the 1st or the 15th, both within 180 days, same amount, RETRY PYMT in the description.
7. File the authorization with the return. Keep the signed authorization, the written statement, and the ODFI's correspondence in one case record.
8. Report the trend to the bank before the bank asks. Send the ODFI a monthly note with the three rates, the cause of any rise, and the control in place.

The decision in advance

Returns are not a cost of doing business; they are a measurement of it. An originator with a 0.6% unauthorized rate and a pile of unapplied NOCs is one letter from its ODFI away from a reduction plan. The work is daily: read the file, code the return, apply the correction, compute the rate, and stop the debit you have no right to send.