> ## 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. # Receivables: Your Program's Loans on Lead's Books > What a receivable is, which receivables you can see, how they relate to fundings, card network settlements, and receivable sales, and what you can do with the Receivables API. Lead is the lender of record, so every loan your program originates starts on Lead's balance sheet. A receivable is Lead's claim on that loan: the amount of Lead's balance sheet the loan is using. How long a receivable stays on Lead's books depends on how the loan was originated. That is set by `balance_sheet_model` on the user account. See [The User Account Object](/v2/products/user-accounts/user-account-object). * **Originate to sell** (`held_for_sale`). The receivable waits out your program's hold period, then joins a receivable sale that you buy. The receivable sale is what you pay for. * **On-sheet** (`held_for_investment`). Lead keeps the receivable on its balance sheet. Use the Receivables API to see what you will buy and when, and to break each receivable sale down into the loans it contains. A receivable is not your customer's loan balance. The user credit balance tracks what the borrower owes, as reported by you. The receivable tracks what Lead holds. They start from the same origination but answer different questions. The Receivables API is currently in preview with a planned beta release in January 2027. Preview APIs are not yet available in sandbox or production and can change before beta. Use these pages to plan an integration, not to build one. Once released in beta, it will be available to all partners in sandbox, and in production for select programs. Beta APIs may change without a version increment, and changes will be announced in advance. See [Versioning and backwards compatibility](/core-concepts/platform/versioning-and-backwards-compatibility). ## Which receivables you can see Today the API returns receivables for loans originated to sell. Each one has `held_for: sale` and a `receivable_sale_details.request_date`. Receivables for on-sheet loans are not returned yet. When they are added, they will carry `held_for: investment`, and their amounts can change over time as you report activity on the loan. An on-sheet receivable can also move to `held_for: sale`, for example when on-sheet loans are marked for sale. Build your integration to accept `held_for` values other than `sale`. ## Where receivables come from | Origination | Receivable `type` | One receivable per | | :- | :- | :- | | A funding posts, or another draw is recorded on a user credit balance | `user_credit_balance` | User credit transaction that drew principal | | A card network settles your program's card spend | `card_network_settlement` | Card network settlement | Lead creates every receivable. You never create one. ## How receivables relate to the rest of the model * **Fundings.** Each posted funding produces one `user_credit_balance` receivable. See [Funding](/v2/products/fundings/overview). * **User credit balances and transactions.** A `user_credit_balance` receivable names the user credit balance and the user credit transaction it came from. * **Card network settlements.** A `card_network_settlement` receivable names the network, settlement date, and settlement reporting ID it came from. * **Receivable sales.** On its `request_date`, each receivable is grouped into that business day's receivable sale. `receivable_sale_details.receivable_sale_id` then points to it. See [Receivable Sale](/v2/products/receivable-sales/overview). ## What you can do | Endpoint | What it does | | :- | :- | | `GET /v2/receivables` | List receivables. Filter by `type`, `receivable_sale_id`, or `request_date`. | | `GET /v2/receivables/{receivable_id}` | Retrieve a receivable. | | `POST /v2/simulate/card_network_settlements` | Sandbox only. Simulate a card network settlement so Lead creates its receivables. | Common reads: * **What is in a receivable sale:** `GET /v2/receivables?receivable_sale_id={id}` * **What you will buy on a given day:** `GET /v2/receivables?request_date=2026-10-08` * **What you will buy over the next week:** `GET /v2/receivables?request_date[on_or_after]=2026-10-08&request_date[on_or_before]=2026-10-14` ### Authentication * **`receivable/read_write`** for the sandbox simulation endpoint. Also grants read access. * **`receivable/read`** for the GET endpoints. Use it when your integration only needs to read receivables. ## What you cannot do * **Create, change, or delete a receivable.** The API is read only. * **Choose which receivables to buy.** Every receivable that reaches its `request_date` joins that day's receivable sale. * **See receivables Lead holds on its own balance sheet.** When on-sheet receivables are added, they will carry `held_for: investment`. * **Subscribe to receivable webhooks.** Receivables do not emit events. Use the receivable sale webhooks, then list the sale's receivables. ## Availability Funding programs need user credit balances to use the Receivables API. Card programs that buy their card receivables can use it with card network settlements alone. ## In this section * [The Receivable Object](/v2/products/receivables/receivable-object) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.