Skip to main content
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 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 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:

Statuses

Incoming entries have a shorter lifecycle than outgoing: scheduledposted, with a manual review detour when a validation rule requires it. Incoming entries cannot be canceled. The table below is an excerpt; ACH Statuses is the canonical reference, including the return chain. See the incoming transition diagram for the full lifecycle, including the return chain.

Events

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

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.