> ## 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 & the Daily Sale

> Why every Lead-originated loan or card spend creates a receivable, how the hold period works, and how each day's receivables are grouped into a single sale you purchase — today via the Sales Request/Response files, with a Sale API in flight.

<Note>
  **Integration surface today:** the daily sale runs as the **Sales Request/Response file exchange** over SFTP — schemas: [Sales Request](/file-reference/sales/request-schema) · [Sales Response](/file-reference/sales/response-schema). **A Sale API is in flight** that replaces the exchange with a daily sale object and webhooks; it will be announced in [Upcoming Changes](/upcoming-changes) when sandbox access opens. The cycle described on this page is identical across both transports.
</Note>

## Why Receivables Exist

Lead is the lender of record, so every origination — a [Funding](/products/lending/balance-and-funding) you request, or card spend arriving through [network settlement](/products/network-settlement/overview) — creates a **receivable**: Lead's claim on that loan, held on Lead's balance sheet. What happens next depends on your program's [balance-sheet model](/products/lending/balance-sheet-models). Most programs run **Originate-to-Sell**, where receivables are sold to you daily; this page describes that cycle.

## The Cycle

1. **Origination.** The receivable is created and its **hold period** — a program-level number of business days — begins.
2. **The hold period.** While Lead holds the receivable, **imputed interest** accrues daily at your program's configured rate. This is the interest component of the eventual settlement amount — see [Sales Settlement Amount](/products/funding-and-receivables/sales-settlement-amount) for exactly how the day's purchase is priced.
3. **The daily sale.** Each business day, every receivable past its hold period is grouped into **one sale for the day**. The day's purchase settles **whole**: a single cash movement from your operating account for the day's settlement amount, with all of the day's receivables transferring together. There is no partial settlement — the day succeeds or fails as a unit.
4. **Empty days are explicit.** A day with no receivables to sell still produces the day's exchange, so a quiet day is always distinguishable from a broken pipeline.

## Operating the Cycle

Treat the sale as a **daily operational rhythm**, not an event to react to:

* **Reconcile against the day's sale as a unit** — the day's total, then its member receivables. This is the shape guaranteed stable across the file→API transition, so reconciliation built this way carries over unchanged.
* **Fund the operating account as a daily pre-check.** Because settlement is all-or-nothing, an insufficient-funds failure fails the entire day's sale. On a failure, fund the account and coordinate with your Lead team on the retry.
* **Handle the empty-day case from day one** — your pipeline should treat "explicitly nothing to buy" as a success state.

## What Changes with the Sale API

*Preview — full details at announcement in [Upcoming Changes](/upcoming-changes).* The day's sale becomes a queryable **sale object** carrying the day's rollup totals and a breakdown into member **receivable** objects, with webhooks when the day's sale is created and when it settles — replacing file parsing with object reads and giving you a forecast surface for what you'll purchase and when. The daily grain, whole-day settlement, and pricing do not change.