> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lead.bank/llms.txt
> Use this file to discover all available pages before exploring further.

# Returns, reversals, and exceptions

> Returns, reversals, and notifications of change on the ACH API: deadlines, return codes, how each one shows up on the ACH object, and what you must do.

A transfer may go through one of three exception flows:

* A return is a transfer the receiving bank sends 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.
* A reversal is a correcting entry you initiate to recover funds from a transfer you originated by mistake, such as a duplicate or a wrong amount.
* A Notification of Change (NOC) is a message from the receiving bank that accepts your transfer but tells you a detail was incorrect, with the corrected value to use on future transfers.

## Returns

You can return an ACH transfer you received for any valid reason with `POST /v2/ach/{ach_id}/return`. External banks can likewise return transfers you originate. Either way, the return is recorded on the original transfer. Its `status` moves through the return chain. A new entry is added to `returns[]` with the `return_code`, a short `reason`, and any `details` the returning bank sent. After the return posts, it also includes the `core_transaction_id` of the ledger entry that moved the funds back. See [The returns block](https://docs.lead.bank/v2/products/ach/ach-object.md#the-returns-block) and [ACH Statuses](https://docs.lead.bank/v2/products/ach/statuses.md).

The deadline depends on the return reason:

* **Standard returns** must be available to the originating depository financial institution (ODFI) by the opening of business on the second business day after the original settlement date. A business day is a weekday that isn't a Federal Reserve holiday.
* **Unauthorized debit returns** (R05, R07, R10, R11) have until the opening of business on the 60th calendar day after settlement. They also need a signed Written Statement of Unauthorized Debit (WSUD). Get the WSUD before you start the return, and keep 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 doesn't send it to the Fed until the original transfer posts.

### Return codes

The endpoint `POST /v2/ach/{ach_id}/return` handles every step of a return dispute, and the `return_code` you pass tells Lead which step you mean. A standard code starts a return. A dishonor code disputes a return you received. A contest code answers a dishonor of a return you sent. Whichever step you're on, you call the endpoint against the original transfer's `ach_id`, and the code has to fit where the transfer is in the return chain. The request body also accepts `metadata`.

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

| Code | Description | Timing | WSUD required |
| - | - | - | - |
| `R01` | Insufficient Funds | 2 business days | No |
| `R02` | Account Closed | 2 business days | No |
| `R03` | No Account / Unable to Locate Account | 2 business 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 business days | No |
| `R09` | Uncollected Funds | 2 business 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 business days | No |
| `R15` | Beneficiary or Account Holder Deceased | 2 business days | No |
| `R16` | Account Frozen / Entry Returned per OFAC | 2 business days | No |
| `R17` | File Record Edit Criteria | 2 business days | No |
| `R22` | Invalid Individual ID Number | 2 business days | No |
| `R23` | Credit Entry Refused by Receiver | 2 business days | No |
| `R29` | Corporate Customer Advises Not Authorized | 2 business 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`). It also adds another entry to `returns[]` with `type` `dishonored_return` or `contested_return`.

**Dishonored return codes** dishonor a return you received against a transfer you originated. Submit within 5 business 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 business 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 an unauthorized debit after the return window has passed, contact Lead promptly with documentation that shows the authorization is invalid. Lead reviews the request and, if appropriate, asks the ODFI for permission to make a late return.

A receiver can ask for a late return of a debit you originated. Nacha requires the originator, which is you, to keep proof of authorization for two years after the settlement date of the last debit. Keep these records ready so you can support or dispute a late return request.

## 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 /v2/ach/{ach_id}/reverse` within five business days of the original settlement date. Reversals are only for genuine mistakes. Never use them to recover a transaction you believe is unauthorized.

The request body takes `reason`, one of `duplicate`, `receiver_incorrect`, `amount_incorrect`, `debit_too_early`, or `credit_too_late`, plus optional `metadata`.

How reversals behave:

* A reversal is a separate ACH transfer in the opposite direction for the same amount, with its own lifecycle and the same [statuses](https://docs.lead.bank/v2/products/ach/statuses.md) as any other transfer. Lead sets its `statement_descriptor` to `REVERSAL`.
* Both transfers carry a `reversal` block with the `reason` and the other transfer's ID in `linked_ach_id`. See [The reversal block](https://docs.lead.bank/v2/products/ach/ach-object.md#the-reversal-block).
* 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. The return appears in the reversing transfer's `returns[]`.
* Lead can reject a reversal in review, for example when it is requested after the five-business-day limit. The reversing transfer moves to `rejected` with a `rejection` block, and the original is unaffected.

### Return or reversal?

Who made the mistake decides which action you use. 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 business 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 business days |
| A service provider you previously authorized pulls a debit you believe is in error. | RDFI (debit, pull) | Return |

## Notifications of Change

A receiving depository financial institution (RDFI) doesn't have to return a transfer with a wrong detail. It can post the transfer and send back a Notification of Change (NOC), which says what was wrong and gives the right value to use from then on.

You don't need to parse Nacha change codes. Lead normalizes each NOC into a `correction` block on the original ACH transfer, containing only the fields that changed. At least one field is present:

`"correction": {`

`"account_number": "1234567899",`

`"routing_number": "123456789",`

`"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 business days of the original entry's settlement date. Lead delivers it to you within two business days of settlement. Corrections arrive via the `ach.corrected` webhook or the Return/NOC file.

### What you must do

Do the following:

* The transfer that triggered the NOC processes as usual; no action is needed on it.
* Update your counterparty records with the corrected values. Do this within six business days of receiving the correction, or before your next transfer to that receiver.
* Do not keep using the old details. Lead might reject a subsequent transfer to a corrected counterparty with a `rejection.details` that references the ACH that carried the correction. Lead also monitors NOC activity and might reach out if the same correction keeps arriving.

Unmanaged NOCs have real consequences: Nacha can impose monetary penalties depending on frequency and volume. Those fines might 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` |

## Related

* [The ACH Object](https://docs.lead.bank/v2/products/ach/ach-object.md)
* [ACH Statuses](https://docs.lead.bank/v2/products/ach/statuses.md)
* [ACH timing and availability](https://docs.lead.bank/v2/products/ach/timing.md)
* [Receiving ACH](https://docs.lead.bank/v2/products/ach/receiving-ach.md)
* [Sending ACH](https://docs.lead.bank/v2/products/ach/sending-ach.md)