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

# Validations and how to avoid them

> How Lead validates ACH entries, which failures you see synchronously as a 422 and which arrive as an ach.rejected webhook, and how to avoid each one.

Lead runs validation checks on every ACH entry it processes, outgoing and incoming. A failure takes one of two paths:

* **Synchronous.** The check fails at submission time. `POST /v2/ach` returns 422 and creates no entry. Fix the request and resend it.
* **Asynchronous.** The check runs after Lead receives the entry. An outgoing entry moves to `rejected`, directly or after `under_review`. You receive an `ach.rejected` webhook with the entry's `rejection.reason` and `rejection.details`.

The table lists each check, how to avoid it, and which path a failure takes.

| Validation | How to avoid it | Synchronous |
| - | - | - |
| `account_number_not_active` | Check that the account number is `active` before you send. | Yes |
| `aggregate_limit_exceeded` | Review your volume against the daily and 30-day limits set with Lead, and ask for a change before you need it. | No |
| `client_customer_not_present` | Every account number you send from must have an `entity_id`. It's required at creation. | Yes |
| `disallowed_counterparty` | Keep your account numbers' counterparty allowlists current. See [Payment controls](https://docs.lead.bank/v2/products/account-number/controls.md). | Yes |
| `disallowed_sec_code` | Use only the SEC codes Lead approved for your program and originator. See [The Originator Object](https://docs.lead.bank/v2/products/originators/originator-object.md). | Yes |
| `invalid_format` | Follow the request schema for API entries and the Nacha spec for files. | Yes |
| `non_sufficient_funds` | Monitor the balance behind the sending account number so outgoing credits don't overdraw it. | No |
| `ofac_rejection` | Screen counterparties before you send. | No |
| `per_transaction_limit_exceeded` | Review your per-entry limit with Lead before sending larger entries. | Yes |
| `previously_corrected` | Act on `ach.corrected` webhooks before the next entry to that counterparty. See [Returns, reversals, and exceptions](https://docs.lead.bank/v2/products/ach/exceptions.md). | No |
| `related_prenote_exception` | If you send prenotes, wait three business days (weekdays that aren't Federal Reserve holidays) from the prenote before sending a live entry. | No |
| `return_untimely` | Submit returns as soon as you can so they fall inside the Nacha window. See [Returns, reversals, and exceptions](https://docs.lead.bank/v2/products/ach/exceptions.md). | Yes |
| `reversal_rejection` | Reverse only genuine errors, within five business days of settlement, with the right `reason`. | No |
| `unexpected_return_code` | Use the return code Nacha prescribes for the situation. | No |
| `unexpected_routing_number` | Confirm the counterparty routing number before you send. | Yes |

## Reading a rejection

On an asynchronous rejection, `rejection.reason` is a value from a closed set. `rejection.details` is free text that names the specific problem, for example the account number that was inactive. Branch on `reason` and show `details` to operators. See [The rejection block](https://docs.lead.bank/v2/products/ach/ach-object.md#the-rejection-block).

## 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)
* [Sending ACH](https://docs.lead.bank/v2/products/ach/sending-ach.md)
* [Errors](https://docs.lead.bank/api-reference/using-the-api/errors-v2.md)