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

# Sending ACH

> Send outgoing ACH credits and debits: request requirements, statuses, webhooks, and cancellation.

An outgoing ACH is either a **credit**, which pushes funds from your account to the counterparty, or a **debit**, which pulls funds from the counterparty into your account.

## Prerequisites

* **Origination is configured at onboarding.** Your ACH originator identity (company name and company ID) is set up on your program by your Technical Account Manager. You do not pass originator details on requests.
* Your token needs the `ach/read_write` scope.
* The sending Account Number must be `active`, and its [outgoing ACH controls](/products/account-number/controls) must permit the counterparty. By default all counterparties are permitted.

<Note>
  The [Originator API](/products/ach/originators) is only for programs that create and maintain additional originators as part of a third-party sending setup. Most programs never call it.
</Note>

## Endpoints

| **Endpoint**                    | **Description**                                                                    |
| :------------------------------ | :--------------------------------------------------------------------------------- |
| `POST /v1/ach`                  | Create an outgoing ACH. Requires an `Idempotency-Key` header.                      |
| `POST /v1/ach/{ach_id}/cancel`  | Cancel an outgoing ACH that is still in a cancellable status.                      |
| `POST /v1/ach/{ach_id}/reverse` | Reverse an erroneous entry you originated, within five banking days of settlement. |

## Request Requirements

| **Field**              | **Requirement**                                                                                                                    |
| :--------------------- | :--------------------------------------------------------------------------------------------------------------------------------- |
| `account_number_id`    | The Account Number the funds leave (credit) or arrive in (debit).                                                                  |
| `amount`               | Amount in cents. Same Day ACH is capped at \$1,000,000 per transfer; larger same-day requests process as next-day.                 |
| `currency_code`        | ISO 4217 code.                                                                                                                     |
| `transaction_type`     | `credit` (push funds to the counterparty) or `debit` (pull funds from the counterparty).                                           |
| `delivery_type`        | `same_business_day` or `next_business_day`. Determines the cutoff schedule; see [Timing & Availability](/products/ach/timing).     |
| `sec_code`             | One of `CCD`, `PPD`, `TEL`, `WEB`, `CIE`. Incoming entries may additionally carry `IAT`, but Lead does not originate outgoing IAT. |
| `statement_descriptor` | The description that appears on the counterparty's statement.                                                                      |
| `counterparty`         | Object with `name`, `routing_number`, `account_number`, and `account_type` (`checking` or `savings`).                              |

Optional fields include `individual_id`, `descriptive_date`, `additional_information`, and `metadata`. See [Create an ACH](/api-reference/endpoint/ach/create-an-ach) for the full schema and [The ACH Object](/products/ach/ach-object) for every response field.

```json theme={null}
{
  "account_number_id": "account_number_xyz",
  "amount": 5000,
  "currency_code": "USD",
  "transaction_type": "credit",
  "delivery_type": "next_business_day",
  "sec_code": "PPD",
  "statement_descriptor": "PAYMENT",
  "counterparty": {
    "name": "Jordan Smith",
    "routing_number": "021000021",
    "account_number": "9900000001",
    "account_type": "checking"
  }
}
```

A successful response returns the ACH object in the `scheduled` status.

## Statuses

The happy path for an outgoing ACH is `scheduled` → `processing` → `submitted` → `posted`. Entries that trip a validation rule detour through manual review. The table below is an excerpt; [ACH Statuses](/products/ach/statuses) is the canonical reference, including the return chain.

| **Status**     | **Description**                                                                                           | **Cancellable** | **Webhook**        |
| :------------- | :-------------------------------------------------------------------------------------------------------- | :-------------- | :----------------- |
| `scheduled`    | Accepted by Lead, waiting for further processing.                                                         | Yes             | `ach.scheduled`    |
| `processing`   | Lead is preparing the entry for submission to the Fed.                                                    | No              | `ach.processing`   |
| `submitted`    | Submitted to the Fed for processing.                                                                      | No              | `ach.submitted`    |
| `posted`       | Completed and posted to the receiving bank account. Funds at another bank may take a few hours to appear. | No              | `ach.posted`       |
| `under_review` | A validation rule triggered manual review by Lead Payment Ops.                                            | Yes             | `ach.under_review` |
| `approved`     | Manual review passed; the entry continues processing.                                                     | Yes             | `ach.approved`     |
| `rejected`     | Validation or manual review failed. Terminal.                                                             | No              | `ach.rejected`     |
| `canceled`     | You canceled the entry before Lead began processing it. Terminal.                                         | No              | `ach.canceled`     |

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

## Events

Act on webhooks rather than assuming success from the 200:

| **Event**                             | **What happened**                                | **Recommended action**                                                                                                                    |
| :------------------------------------ | :----------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------- |
| `ach.under_review`                    | The entry is in manual review.                   | Wait. Lead may reach out for more information. Cancel if no longer needed; see [Validations](/products/ach/validations) to avoid reviews. |
| `ach.rejected`                        | The entry will not process.                      | Inspect `rejection.reason` and `rejection.details`, fix the issue, and resubmit if appropriate.                                           |
| `ach.posted`                          | The transfer completed.                          | Mark the payment settled in your system.                                                                                                  |
| `ach.pending_return` / `ach.returned` | The receiving bank is returning a posted entry.  | Handle per [Returns, Reversals, & Exceptions](/products/ach/exceptions).                                                                  |
| `ach.corrected`                       | A Notification of Change arrived for this entry. | Update your counterparty records from the `correction` object before the next transfer.                                                   |

## Testing in Sandbox

Outgoing ACH does not advance automatically in sandbox: entries stay in `scheduled` until you advance them with `POST /v1/simulate/ach/{ach_id}/advance`. See [Sandbox Testing](/products/ach/sandbox) for the sequence and timing.