ACH return codes: the complete list, in plain language

What are ACH return codes?

When a bank cannot post an ACH entry, or its customer rejects it, the bank sends the entry back through the network with a standardized reason attached. That reason is the return code: an R followed by two digits, with a fixed meaning that every bank on the network shares. Nacha, the body that governs the ACH network, maintains the list.

The code matters because it tells you two things at once: what went wrong, and what you are allowed to do about it. Some returns invite a corrected retry. Some forbid any retry until the recipient acts. A few are signals to stop entirely and escalate.

If you already have a code in hand and just need the answer, the ACH return code lookup tool gives the meaning and next step in one search. The table below is the same material in full.

Complete ACH return code list

Codes in the R80s exist too, but they apply to international (IAT) entries. A domestic payout program rarely sees them. If one shows up, it usually traces to a gateway handling a cross-border leg, and your bank or processor is the right first call.

Most common ACH return codes

R01: insufficient funds. The available balance was not sufficient for the entry. The account itself may be perfectly valid; the issue is funds availability. For a payout program sending credits, the relevant return profile differs from a debit collection program, so interpret the code in the context of the entry type and your bank or processor rules.

R02: account closed. The account has been closed. Sending the same instruction to the same account again will not solve it. The only fix is a new destination from the recipient.

R03: no account or unable to locate account.The receiving institution could not locate the account using the information provided. The number looked plausible but matched nothing. The next step is to verify the recipient’s account details, not to retry as-is.

R04: invalid account number structure. The account number itself is malformed, often a typo or a digit dropped during entry. The destination should be corrected before another attempt.

R23: credit entry refused by receiver. This is the return unique to sending money out. The credit reached the account, but the account holder refused it: the amount was wrong, the payment was unexpected, or the account is in dispute. A refused credit is a conversation, not a technical fix. Contact the recipient, resolve the reason, and only then resend.

R24: duplicate entry. The receiving bank believes it already got this entry. This is one reason payout systems need duplicate protection with idempotency keysbefore they submit payments. The right question is not “Can we retry?” It is “Do we know whether this obligation has already been paid?”

ACH returns vs reversals

A return moves from the receiving bank back to you: the other side could not or would not accept the entry, and the code explains why. A reversal moves the other direction. It is a new entry you originate to pull back a payment you sent in error, such as a duplicate, a wrong amount, or a wrong account.

Reversals are narrow. Nacha permits them only for specific error cases, within a short window measured in banking days, and the money is not guaranteed to come back: if the account is empty or closed, the reversal itself can return. Treat reversals as a correction of your own mistake, and returns as information about the destination.

ACH return codes vs Notification of Change codes

Not every correction arrives as a return. When the receiving bank can post the entry but spots stale details, it lets the payment settle and sends a Notification of Change instead: a message saying “this went through, but fix these details before you send the next one.” NOCs carry C-codes rather than R-codes.

The distinction matters for operations. A return means the money came back and the obligation is still open. A NOC means the money arrived and your job is data hygiene: update the stored account details so future entries carry the corrected information.

Notification of Change C-codes

C02 is the one payout teams see most, usually after a bank merger: the payment settled, but the routing number you have on file is out of date, and the NOC carries the corrected routing number to use from now on. Apply the correction promptly; continuing to send entries with the old details after a NOC is a rules problem, not just an operational one.

What to do after an ACH return

The code is only useful if it becomes an action someone can take. Instead of showing this:

R03

show this:

Payout returned

Reason
Account could not be located

Action
Ask the recipient to update bank information

Retry
Only after the destination is corrected

That mapping is mechanical: every code in the table above pairs with a next step, so a payout API should hand your team the action, not just the raw code. A returned payout is one kind of failed payout, and the broader playbook for handling failed payouts, retries, fallback rails, and recipient communication, applies from the moment the return lands.

Two habits prevent most of the damage. First, never retry automatically on codes that require new information (R02, R03, R04) or that forbid retries outright (R16, and unauthorized claims like R10 and R29). Second, when the fix is a new destination, collect it through a secure flow rather than email, because a return is exactly the moment fraudsters like to impersonate recipients.

How returns affect payout reconciliation

A return does not erase the payment attempt. It adds a second event that has to land in your books against the same obligation:

Obligation
$750 owed

Attempt 1
ACH
Returned R03

Attempt 2
RTP
Completed

Result
Obligation satisfied

Finance can now explain why two attempts exist without treating them as two separate amounts owed. That structure, one obligation with many attempts, is the core of payout reconciliation: returns become ledger entries that offset the original attempt, and the obligation stays open until an attempt actually completes.