> ## 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.

# Receiving ACH

> Handle incoming ACH credits and debits: controls, statuses, webhooks, and returning entries you do not want.

Incoming ACH entries are originated by external institutions, so there is no endpoint to call: entries addressed to your Account Numbers arrive on their own. Each one appears as an [ACH object](/products/ach/ach-object) with an `incoming` direction, and webhooks tell you when one arrives and posts. An incoming **credit** deposits funds into your account; an incoming **debit** pulls funds out, under an authorization your customer gave the originator.

## Controlling What You Accept

Each Account Number's [ACH controls](/products/account-number/controls) govern what it can receive:

* `incoming.accept_credit` and `incoming.accept_debit`, both `true` by default. When `accept_debit` is `false`, inbound debits are automatically returned with return code `R16`.
* `incoming.counterparty_filter`: accept all counterparties (default), an allowlist of company IDs, or reject all.

## Endpoints

You don't call anything to receive an entry, but these endpoints are how you observe and act on incoming activity:

| **Endpoint**                     | **Description**                                                                            |
| :------------------------------- | :----------------------------------------------------------------------------------------- |
| `GET /v1/ach?direction=incoming` | List incoming entries. Also filterable by `account_number_id`, `status`, and `created_at`. |
| `GET /v1/ach/{ach_id}`           | Retrieve a single entry, for example when a webhook delivers its ID.                       |
| `POST /v1/ach/{ach_id}/return`   | Return an incoming entry you don't want.                                                   |

## Statuses

Incoming entries have a shorter lifecycle than outgoing: `scheduled` → `posted`, with a manual review detour when a validation rule requires it. Incoming entries cannot be canceled. The table below is an excerpt; [ACH Statuses](/products/ach/statuses) is the canonical reference, including the return chain.

| **Status**     | **Description**                                                           | **Webhook**        |
| :------------- | :------------------------------------------------------------------------ | :----------------- |
| `scheduled`    | Lead accepted the incoming entry; it is waiting to post.                  | `ach.scheduled`    |
| `under_review` | A validation rule triggered manual review by Lead Payment Ops.            | `ach.under_review` |
| `rejected`     | The entry failed validation or manual review and will not post. Terminal. | `ach.rejected`     |
| `posted`       | The entry posted: a credit was deposited, or a debit was withdrawn.       | `ach.posted`       |

See the [incoming transition diagram](/products/ach/statuses#incoming-ach-transitions) for the full lifecycle, including the return chain.

## Events

| **Event**                             | **What happened**                                  | **Recommended action**                                                             |
| :------------------------------------ | :------------------------------------------------- | :--------------------------------------------------------------------------------- |
| `ach.scheduled`                       | An incoming entry arrived and was accepted.        | Record it. If it's an unexpected debit, evaluate whether to return it once posted. |
| `ach.under_review`                    | The entry is in manual review.                     | Wait. Lead may reach out for more information.                                     |
| `ach.rejected`                        | The entry will not post.                           | No funds moved. Nothing to reconcile.                                              |
| `ach.posted`                          | Funds moved.                                       | Update balances in your system. For debits, confirm the pull was authorized.       |
| `ach.pending_return` / `ach.returned` | A return of this entry is in progress or complete. | Reconcile the reversal of funds.                                                   |

## Returning Entries You Don't Want

You can return any incoming entry, most commonly an unauthorized or erroneous debit, with `POST /v1/ach/{ach_id}/return` and an appropriate return code. Deadlines are strict: standard returns have two banking days from settlement, and unauthorized debit returns have sixty calendar days plus a signed WSUD. See [Returns, Reversals, & Exceptions](/products/ach/exceptions) for codes, deadlines, and cutoffs.

You can submit the return before the entry reaches `posted`; Lead holds it and sends it to the Fed once the original posts.

<Note>
  Incoming entries may carry the `IAT` SEC code for cross-border transactions, with the additional detail in the object's `iat_details`. Lead does not originate outgoing IAT.
</Note>

## Testing in Sandbox

Trigger an incoming entry with `POST /v1/simulate/ach/incoming_ach`, and simulate a counterparty returning one of your outgoing entries with `POST /v1/simulate/ach/{ach_id}/incoming_return`. See [Sandbox Testing](/products/ach/sandbox).