Returns, Reversals, & Exceptions

Most ACH transfers post without issue. This page covers the three exception flows for when one doesn’t:

Return: the receiving bank sends a transfer back, for reasons like a closed account, insufficient funds, or an unauthorized debit. You can return transfers you receive, and transfers you originate can be returned to you.
Reversal: you originated a transfer by mistake (a duplicate, a wrong amount) and initiate a correcting entry to recover the funds.
Notification of Change (NOC): the receiving bank accepts your transfer but tells you a detail was incorrect, and provides the corrected value to use on future transfers.

A few Nacha terms appear throughout:

Originator: the person or business that initiates an ACH transfer.
ODFI (Originating Depository Financial Institution): the bank that sends a transfer into the ACH network.
RDFI (Receiving Depository Financial Institution): the bank that receives it.

Returns

You can return an ACH transfer you received for any valid reason using POST /v1/ach/{ach_id}/return. External banks can likewise return transfers you originate; those arrive as status changes and webhooks on the original transfer (see Statuses). The deadline depends on the return reason:

Standard returns must be available to the ODFI by the opening of business on the second banking day after the original settlement date.
Unauthorized debit returns (R05, R07, R10, R11) have until the opening of business on the 60th calendar day after settlement, and require a signed Written Statement of Unauthorized Debit (WSUD). Obtain the WSUD before initiating the return and retain it for at least one year from the settlement date.

You can submit a return before the original transfer reaches posted. Lead accepts the return request immediately, but does not send it to the Fed until the original transfer posts.

Return Codes

The return_code you pass to POST /v1/ach/{ach_id}/return determines what the call does: a standard code initiates a return, a dishonor code dishonors an existing return, and a contest code contests an existing dishonored return. In every case you target the original transfer’s ach_id, and the code must match the transfer’s current position in the return chain.

The complete list of return codes is in the Nacha Operating Rules and Guidelines.

Standard return codes initiate a return against a transfer you received:

Code	Description	Timing	WSUD Required
R01	Insufficient Funds	2 Banking Days	No
R02	Account Closed	2 Banking Days	No
R03	No Account / Unable to Locate Account	2 Banking Days	No
R05	Unauthorized Debit Using Corporate SEC Code	60 Calendar Days	Yes
R07	Authorization Revoked by Customer	60 Calendar Days	Yes
R08	Payment Stopped	2 Banking Days	No
R09	Uncollected Funds	2 Banking Days	No
R10	Customer Advises Originator is Not Known/Not Authorized	60 Calendar Days	Yes
R11	Authorization Revoked / Improperly Initiated Reversal	60 Calendar Days	Yes
R14	Representative Payee Deceased/Unable to Continue	2 Banking Days	No
R15	Beneficiary or Account Holder Deceased	2 Banking Days	No
R16	Account Frozen / Entry Returned per OFAC	2 Banking Days	No
R17	File Record Edit Criteria	2 Banking Days	No
R22	Invalid Individual ID Number	2 Banking Days	No
R23	Credit Entry Refused by Receiver	2 Banking Days	No
R29	Corporate Customer Advises Not Authorized	2 Banking Days	No

A return can itself be disputed, and both sides of that dispute run through the same endpoint. Submitting a dishonor or contest code moves the original transfer through the corresponding return chain statuses (pending_dishonored_return, return_dishonored, pending_contested_return, return_contested). Dishonored return codes dishonor a return you received against a transfer you originated. Submit within 5 banking days of the return settling:

Code	Description
R61	Misrouted return
R62	Return of erroneous or reversing debit
R67	Duplicate return
R68	Untimely return
R69	Field error(s)
R70	Permissible return entry not accepted / Return not requested by ODFI

Contested dishonored return codes contest a dishonor of a return you issued. Submit within 2 banking days of the dishonor settling:

Code	Description
R71	Misrouted dishonored return
R72	Untimely dishonored return
R73	Timely original return
R74	Corrected return
R75	Return not a duplicate
R76	No errors found
R77	Non-acceptance of R62 dishonored return

Late Returns

If you suspect a debit from one of your accounts was unauthorized but the return window has passed, contact Lead promptly with documentation showing the authorization is invalid. Lead will review the request and, if appropriate, ask the ODFI for permission to make a late return. The same process can run against you as an Originator. Nacha requires Originators to retain proof of authorization for two years after the settlement date of the last debit, so keep authorization records ready to support or dispute late return requests.

Reversals

Use a reversal to correct a transfer you originated in error: a duplicate payment, a wrong amount, or a wrong receiver. Initiate it with POST /v1/ach/{ach_id}/reverse within five banking days of the original settlement date. Reversals are only for genuine mistakes; never use them to claw back a transaction you believe is unauthorized (that is a return, initiated by the receiving side). How reversals behave:

A reversal is a separate ACH transfer with its own lifecycle and the same statuses as any other transfer.
The original transfer is annotated with a reversal object containing the reversal reason and the ID of the reversal transfer.
No webhooks fire on the original transfer when a reversal is created. Watch the reversal transfer for status webhooks.
A reversal can itself be returned by the receiving bank.

Return or Reversal?

Who made the mistake determines the tool. If you originated it, reverse it. If you received it, return it.

Scenario	Lead’s role	Action
You sent the same ACH credit twice and need the funds back from the duplicate.	ODFI (credit, push)	Reversal, within five banking days
You receive an ACH credit you don’t recognize and suspect fraud.	RDFI (credit, push)	Return
You pull scheduled ACH debits from a counterparty, and one was a mistake you need to send back.	ODFI (debit, pull)	Reversal, within five banking days
A service provider you previously authorized pulls a debit you believe is in error.	RDFI (debit, pull)	Return

Notifications of Change

Instead of returning a transfer, an RDFI can accept and post it but send back a Notification of Change (NOC): a notice that a detail of the transfer was incorrect, along with the corrected value to use on all future transfers to that receiver. You don’t need to parse Nacha change codes. Lead normalizes each NOC into a correction object on the original ACH transfer, containing only the fields that changed. At least one field will be present:

"correction": {
  "account_number": "1032345678",
  "routing_number": "021000021",
  "account_type": "checking"
}

account_number: the corrected counterparty account number.
routing_number: the corrected counterparty routing number.
account_type: the corrected counterparty account type, checking or savings.

RDFIs must send an NOC within two banking days of the original entry’s settlement date, and Lead delivers it to you within two banking days of settlement. Corrections arrive daily via webhook, the Return/NOC file, or Online Banking.

What You Must Do

The transfer that triggered the NOC processes as usual; no action is needed on it.
Update your counterparty records with the corrected values within six banking days of receiving the correction, or before initiating the next transfer to that receiver, whichever is later. Originators of one-time payments are exempt.
Do not keep using the old details. Lead may reject a subsequent transfer to a corrected counterparty with the rejection reason previously_corrected, which references the ACH that carried the correction. Lead also monitors NOC activity and may reach out if the same correction keeps arriving.

Manage the corrections you receive proactively. If you have questions or see unexpected activity, contact Lead as soon as possible.

Unmanaged NOCs carry real consequences: Nacha may impose monetary penalties depending on frequency and volume. Those fines may be charged to you under the Lead ACH Agreement, and Nacha can bar repeat violators from the ACH network.

Mapping to Nacha Change Codes

If you reconcile against raw Nacha data, such as the Return/NOC file, the common change codes map to correction fields as follows:

Nacha code	What was incorrect	`correction` fields populated
C01	Account number	`account_number`
C02	Routing number	`routing_number`
C03	Routing number and account number	`routing_number`, `account_number`
C05	Account type (transaction code)	`account_type`
C06	Account number and account type	`account_number`, `account_type`
C07	Routing number, account number, and type	`routing_number`, `account_number`, `account_type`

Banking Infrastructure

Funding & Settlement

Payment Rails

Customers & Accounts

Returns

Return Codes

Late Returns

Reversals

Return or Reversal?

Notifications of Change

What You Must Do

Mapping to Nacha Change Codes

​Returns

​Return Codes

​Late Returns

​Reversals

​Return or Reversal?

​Notifications of Change

​What You Must Do

​Mapping to Nacha Change Codes

Returns

Return Codes

Late Returns

Reversals

Return or Reversal?

Notifications of Change

What You Must Do

Mapping to Nacha Change Codes