Sending ACH

An outgoing ACH is a credit or a debit. A credit pushes funds from the balance behind your account number to the counterparty. A debit pulls funds from the counterparty into that balance.

Prerequisites

Before you send, check these:

Origination is configured at onboarding. Lead sets up your ACH originator identity (company name and company ID) on your program. You don’t 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 must permit the counterparty. By default all counterparties are permitted.
The sending account number can’t be one Lead holds. Every rail returns an error for those.

Endpoints

You can use these endpoints:

Endpoint	Description
`POST /v2/ach`	Create an outgoing ACH. Requires an `Idempotency-Key` header.
`POST /v2/ach/{ach_id}/cancel`	Cancel an outgoing ACH that is still in a cancellable status.
`POST /v2/ach/{ach_id}/reverse`	Reverse an erroneous entry you originated, within five business days (weekdays that aren’t Federal Reserve holidays) of settlement. Takes `reason`.

Request requirements

The create request takes these fields:

Field	Requirement
`account_number_id`	The account number the funds leave (credit) or arrive in (debit).
`amount`	Amount as an integer in minor units. `5000` is $50.00. Nacha caps same-day ACH at $1,000,000 per transfer. A `same_business_day` request over that amount is processed 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 ACH timing and availability.
`sec_code`	One of `CCD`, `PPD`, `TEL`, `WEB`, `CIE`. Incoming entries can also carry `IAT`, but Lead doesn’t 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 for the full schema and The ACH Object for every response field.

{
  "account_number_id": "account_number_2fTZ4St5HSJnxzv7jdevxQnev3U",
  "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": "123456789",
    "account_number": "4455667788",
    "account_type": "checking"
  }
}

A successful response returns the ACH object in scheduled, with core_balance_id already set to the core balance the entry posts to and core_transaction_id still null.

Statuses

An outgoing entry that passes validation moves from scheduled to processing, submitted, and posted. An entry that fails a validation rule goes to manual review. This table is an excerpt. ACH Statuses is the canonical reference, including the return chain.

Status	Description	Cancellable	Webhook
`scheduled`	Accepted by Lead, waiting for further processing.	Yes	None for outgoing
`processing`	Lead is preparing the entry for submission to the Fed.	No	None
`submitted`	Submitted to the Fed for processing.	No	`ach.submitted`
`posted`	Completed and posted. `core_transaction_id` is set. Funds at another bank might take a few hours to appear.	No	`ach.posted`
`under_review`	A validation rule triggered manual review by Lead.	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	None

See the outgoing transition diagram 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 might contact you for more information. Cancel if no longer needed; see Validations and how to avoid them to avoid reviews.
`ach.rejected`	The entry doesn’t 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 and record `core_transaction_id`.
`ach.returned`	The receiving bank returned the posted entry.	Handle per Returns, reversals, and exceptions. Reconcile using the `core_transaction_id` on the `returns[]` entry.
`ach.corrected`	A Notification of Change arrived for this entry.	Update your counterparty records from the `correction` block before the next transfer.

Canceling

POST /v2/ach/{ach_id}/cancel cancels an entry that is scheduled, under_review, or approved. After an entry is processing, it can’t be canceled. The call requires an Idempotency-Key.

Reversing

POST /v2/ach/{ach_id}/reverse creates a new outgoing entry in the opposite direction for the same amount. The body takes reason, one of duplicate, receiver_incorrect, amount_incorrect, debit_too_early, or credit_too_late. Both entries carry a reversal block linking them. See Returns, reversals, and exceptions.

Testing in sandbox

Outgoing ACH doesn’t advance on its own in sandbox: entries stay in scheduled until you advance them one status at a time with POST /v2/simulate/ach/{ach_id}/advance, naming the next status in the body. See Sandbox testing.

Products

Banking Infrastructure

Customers & Accounts

Balances and Transactions

Lending & Receivables

Payment Rails

Prerequisites

Endpoints

Request requirements

Statuses

Events

Canceling

Reversing

Testing in sandbox

​Prerequisites

​Endpoints

​Request requirements

​Statuses

​Events

​Canceling

​Reversing

​Testing in sandbox

​Related

Prerequisites

Endpoints

Request requirements

Statuses

Events

Canceling

Reversing

Testing in sandbox

Related