Every ACH return code from R01 to R85 — what each one means, how long the bank has to send it, and what to do next.
When an ACH payment can't be completed, the customer's bank sends it back with a return reason code. The code tells you why the payment failed — and, more importantly, whether you're allowed to try again, what you need from the customer first, and whether the return counts against the limits Nacha sets for every business that accepts ACH payments.
New to accepting bank payments? See how ACH & eCheck processing with Merchly works.
The account exists, but the money wasn't there. These are the only returns you can simply try again.
R01 · R09
The account is closed, frozen, mistyped, or can't accept debits. Get new details before resubmitting.
R02 · R03 · R04 · R12 · R13 · R14 · R15 · R16 · R20
The customer told their bank to stop or reverse the payment. These carry the most risk to your ACH account.
R05 · R07 · R08 · R10 · R11 · R23 · R29 · R37 · R38 · R51 · R52 · R53
Formatting, routing, or settlement issues between banks. Usually fixed by your processor, not your customer.
R06 · R17 · R18 · R19 · R21 · R22 · R24 · R25 · R26 · R27 · R28 · R30 · R31 · R32 · R33 · R34 · R35 · R36 · R39 · R50
Your bank rejecting a return, or the customer's bank contesting that rejection. Handled bank-to-bank — you'll rarely need to act.
R61 · R62 · R67 · R68 · R69 · R70 · R71 · R72 · R73 · R74 · R75 · R76 · R77
Returns on federal benefit enrollment (ENR) entries and international (IAT) payments. Most merchants never see these.
R40 · R41 · R42 · R43 · R44 · R45 · R46 · R47 · R80 · R81 · R82 · R83 · R84 · R85
Search by code or keyword, or filter by category. Most codes from R34 up are used between banks, gateways and federal agencies, so the returns you'll actually see are mostly in the first four categories.
Showing 70 of 70 return codes
The account's available balance wasn't enough to cover the debit.
A previously open account was closed by the customer or their bank.
The account number is formatted correctly but doesn't match an open account — or the name on the entry doesn't match the account holder.
The account number fails the bank's format check — wrong length, invalid characters, or a bad check digit.
A business-to-business entry type (CCD or CTX) was used to debit a consumer's personal account without a consumer authorization.
Your bank (the ODFI) asked the customer's bank to send the entry back — usually because it was sent in error, duplicated, or flagged as possible fraud.
The customer told their bank they revoked the authorization they gave you before this debit was sent.
The customer placed a stop payment order on this debit, or on a series of recurring debits, with their bank.
The ledger balance covers the debit, but the available balance doesn't — typically because a recent deposit is still on hold.
The customer told their bank they don't recognize your business or never authorized you to debit their account.
The customer did authorize you, but this debit didn't match the agreed terms — wrong amount, wrong date, debited early, or an incomplete authorization.
The customer's account or branch was transferred to a different financial institution.
The routing number isn't valid for ACH — the bank doesn't participate in the ACH Network, or the number was entered incorrectly.
The representative payee — a person authorized to receive funds on someone else's behalf — has died or can no longer act in that role.
The account holder or beneficiary has died.
The bank has frozen the account — due to legal action, a dispute, or an OFAC instruction — and won't allow debits.
The customer's bank couldn't process a field in the entry — or flagged the entry as suspicious, in which case the return is marked “QUESTIONABLE.”
The effective date on the entry was invalid or outside the allowed window.
The amount field was invalid — non-numeric, too large, or zero on an entry that requires an amount.
The account doesn't allow ACH debits — common with some savings, money market, and investment accounts that limit withdrawals.
The company ID on the entry wasn't valid. Most common on CIE entries, where a customer pays a bill through their bank's online bill pay.
The individual ID number on the entry — such as a customer or account reference — didn't match the receiver's records. Typically seen on CIE and MTE entries.
The customer refused a credit you sent them, such as a refund or payout — because the amount is wrong, the account isn't theirs, or they don't want it.
The customer's bank believes it received the same entry twice — same trace number, amount, and account.
The addenda record attached to the entry was missing or improperly formatted.
A required field in the entry was blank or invalid.
The trace number was invalid, or didn't match the original entry it referenced.
The routing number's check digit failed validation — a sure sign it was mistyped.
A business account holder told their bank they didn't authorize the debit.
The customer's bank doesn't participate in the check truncation program the entry relied on.
The customer's bank returned a business-to-business entry after the normal return window, with your bank's agreement.
The customer's bank wasn't able to settle the entry.
A destroyed check entry (XCK) — a paper check that was lost or destroyed in processing and converted to ACH — was returned.
The customer's bank has been restricted by its regulator from processing this kind of ACH entry.
A debit was sent where debits aren't allowed — such as a CIE (bill payment) entry or a debit to a loan account.
A credit was sent using an entry type that only allows debits — ARC, BOC, POP, RCK, TEL, or XCK.
A check you converted to an ACH debit (ARC, BOC, or POP) was also presented as a paper check, so the customer's bank returned the electronic version.
The customer placed a stop payment on the paper check you converted to an ACH debit (ARC or BOC).
The customer's bank determined the check behind an ARC, BOC, or POP entry wasn't eligible for conversion — such as a third-party or credit card check — or that the paper check was also presented.
An automated enrollment (ENR) entry — used by banks to sign customers up for federal benefit direct deposits — was sent to an agency that doesn't participate in the program.
The transaction code in an enrollment entry was invalid.
The routing number or check digit in an enrollment entry was invalid.
The account number in an enrollment entry was invalid.
The individual's ID number in an enrollment entry didn't match the agency's records.
The name in an enrollment entry didn't match the agency's records.
The representative payee indicator in an enrollment entry was invalid.
The agency already has this enrollment on file.
The customer's bank is in a state whose laws require checks to be presented on paper, so it can't accept a returned check re-presented electronically (an RCK entry).
The customer says a re-presented check entry (RCK) was improper — they weren't given the required notice, the signature isn't theirs, the check was altered, or it wasn't eligible to be re-presented electronically.
The customer placed a stop payment on the original check that was re-presented electronically as an RCK entry.
Both the paper check and its electronic RCK entry were presented, so the customer would have paid twice.
Your bank rejected (dishonored) a return because the customer's bank sent it to the wrong routing number.
Your bank rejected a return of a debit that was sent to reverse an earlier mistake — such as a debit pulling back a credit sent in error — because the reversal was legitimate.
Your bank rejected a return because the customer's bank sent more than one return for the same entry.
Your bank rejected a return because it arrived after the deadline for its return code.
Your bank rejected a return because it contained errors — a missing or incorrect account number, amount, trace number, or other field.
Your bank rejected a return that needed its agreement — such as a late R31 — or one coded as requested by your bank (R06) when it wasn't.
The customer's bank is contesting a dishonored return because your bank sent the dishonor to the wrong routing number.
The customer's bank is contesting a dishonored return because your bank sent the dishonor after its five-banking-day deadline.
The customer's bank is contesting a dishonor for lateness (R68) by showing the original return was sent on time.
The customer's bank is contesting a dishonor for errors (R69) by sending a corrected return.
The customer's bank is contesting a dishonor for duplication (R67) by showing the original return wasn't a duplicate.
The customer's bank is contesting a dishonor for errors (R69), stating the original return had no errors.
The customer's bank is contesting an R62 dishonor because the funds from the original erroneous entry can't be recovered from the customer.
An international ACH transaction (IAT) was missing required information or was coded incorrectly.
The destination country or foreign bank doesn't participate in the international ACH program the entry was sent through.
The foreign bank's identification number on the international entry was invalid.
The foreign bank couldn't settle the international entry.
The originating gateway operator (OGO) chose not to process the international entry — because it posed too much risk, or the foreign payment system can't support it.
The receiving bank or gateway found the payment was headed abroad but was sent with a domestic entry type (such as PPD or CCD) instead of as an IAT, so it lacked the details required for sanctions screening.
Nacha tracks your return rate for ACH debits over the previous 60 days. Crossing any of these levels triggers a review by your bank.
| Return type | Threshold | Codes included |
|---|---|---|
| Unauthorized returns | 0.5% | R05, R07, R10, R11, R29, R51 |
| Administrative returns | 3% | R02, R03, R04 |
| Overall returns | 15% | All return codes |
Return code definitions and time frames follow the Nacha Operating Rules. This guide is general information, not legal or compliance advice — confirm specifics with your processor or bank.
A specialist can walk through your return mix, authorization flow and retry timing with you.