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

# The Funding Object

> Field-level reference for the v2 Funding object, the rules Lead checks on create, and how it maps from the v0 Fundings API.

A funding asks Lead to disburse loan principal from Lead's general ledger to an account number. Each funding is drawn against a user credit balance, which records the loan the principal belongs to. You create one with `POST /v2/fundings` and read it with `GET /v2/fundings/{id}`. The `funding.posted` webhook carries the same object.

```json theme={null}
{
  "id": "funding_0o5Fs0EELR0fUjHjbCnEtdUwQe3",
  "user_credit_balance_id": "user_credit_balance_1HCpXwx2EK9oYluWbacgeCnFcLf",
  "account_number_id": "account_number_7Kq2Lm9PxR4sTvWy",
  "currency_code": "USD",
  "amount": 1000000,
  "metadata": { "loan_id": "201681646780571" },
  "core_transaction_id": "core_transaction_5BIJT5QH8Qm2n1x~0",
  "status": "posted",
  "created_at": "2026-09-17T11:01:36Z",
  "updated_at": "2026-09-17T11:05:00Z"
}
```

## Fields

| Field | Type | Description |
| :- | :- | :- |
| `id` | string | Unique identifier, prefixed `funding_`. |
| `user_credit_balance_id` | string | The user credit balance this funding draws against. Required on create. |
| `account_number_id` | string | The account number Lead disburses to. This serves as the instruction for which core balance this funding should be deposited into. Required on create. |
| `currency_code` | enum | ISO 4217 code. `USD` only. Must match the user credit balance. Required on create. |
| `amount` | integer | The principal to disburse, in minor units. Must be greater than zero. Required on create. |
| `metadata` | object | Optional key-value pairs you set on create, such as your own loan or draw ID. Lead does not read them. |
| `core_transaction_id` | string or null | The core transaction that credited the destination core balance. `null` until the funding is `posted`. |
| `status` | enum | `processing` or `posted`. See [Funding Statuses](/v2/products/fundings/statuses). |
| `created_at`, `updated_at` | timestamp | RFC 3339, UTC. |

## Create rules

Send `POST /v2/fundings` with an `Idempotency-Key` header. Lead checks the following before it accepts the request:

* **User credit balance.** It must exist, belong to your program, and be `active`. If it has an `expected_maturity_date`, that date cannot be in the past. A funding on the maturity date itself is allowed.
* **Currency.** `currency_code` must match the user credit balance.
* **Amount.** `amount` must be greater than zero.
* **Funding limit.** On a `non_revolving` user credit balance, `amount` plus every `processing` and `posted` funding already on it cannot exceed `details.max_funding_amount`. In-flight fundings count against the limit.
* **Destination.** The account number must exist, belong to your program, and be `active`. It must sit on a core balance that Lead has enabled to receive fundings. Your Technical Account Manager can tell you which of your account numbers qualify.

If a check fails, the request returns an error and no funding is created. If every check passes, the response returns the funding with `status: processing`.

## What Lead creates when a funding posts

When the money moves, Lead creates these objects for you. You do not report them.

| Object | What it records | How to find it |
| :- | :- | :- |
| Core transaction | The credit to the destination core balance. | `core_transaction_id` on the funding. |
| User credit transaction | A `funding` user credit transaction on the user credit balance, with `amount_breakdown.principal` equal to `amount`. | `GET /v2/user_credit_transactions?funding_id={id}` |
| Receivable | Lead's claim on the disbursed principal. | `GET /v2/receivables`. See [Receivable](/v2/products/receivables/overview). |

The funding moves to `posted` first. The user credit transaction and receivable follow within seconds, so they may not exist yet when you receive `funding.posted`.

## Coming from the v0 Fundings API

A v2 funding replaces the v0 funding. Fundings created on `/v0/fundings` stay on v0. Nothing is migrated.

| v0 | v2 | Notes |
| :- | :- | :- |
| `subledger_balance_id` | `user_credit_balance_id` | Points to a user credit balance instead of a subledger balance. |
| No destination field | `account_number_id` | Required. You now choose where the principal lands. |
| `principal.external_disbursement_amount`, `principal.withheld_amount`, `principal.merchant_origination_fee_amount` | `amount` | One total. To hold back part of a disbursement, keep it in your account and send the rest onward. |
| `other_fees.borrower_origination_fee_amount` | Removed | Post a `fee` user credit transaction with `fee_type` `borrower_origination` and `funding_id` set to the funding it belongs to. `funding_id` is required for this fee type. |
| You report the disbursement transaction on a daily file | Lead posts the `funding` user credit transaction | Do not report it yourself. |
| No `core_transaction_id` | `core_transaction_id` | New. Set when `posted`. |
| `rejected` status and `funding.rejected` webhook | Not used | A v2 funding that passes the create checks always posts. A request that fails them returns an error and creates no funding. |

## Sandbox

Fundings stay `processing` in sandbox until you call `POST /v2/fundings/{id}/advance`, which moves them to `posted` and creates the downstream objects.

## Related

[Funding Overview](/v2/products/fundings/overview) · [Funding Statuses](/v2/products/fundings/statuses) · [The User Credit Balance Object](/v2/products/user-credit-balance/user-credit-balance-object) · [The User Credit Transaction Object](/v2/products/user-credit-transaction/user-credit-transaction-object) · [The Receivable Object](/v2/products/receivables/receivable-object)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.