> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # How origination works > The path one loan application takes: what it binds to, the four lifecycle decisions, the single transaction that disburses it, and the loan account it leaves behind. Origination turns a request for credit into a live loan account. It has four decisions and one transaction that does everything at once. This page follows one application from submitted to disbursed on the generic `XX` profile. A Brazilian regulated loan originates through the Brazil pack rather than through `POST /api/v1/loan-applications`. Read the [Brazil regulatory pack](/en/lender/brazil-regulatory-pack) for that path. ## What an application binds to *** An application binds to a **product version**, never to a product on its own. The version pins the currency, the rate terms, and the accrual basis, so a contract always traces back to the terms it was created under. A later version does not change a loan that already exists. Bind an **accounting profile** to that version before you disburse. The disbursement builds its posting from the profile's legs, and a disbursement without a profile fails. See [Define a loan product](/en/lender/define-a-loan-product). ## Preview, if you want it *** Schedule preview computes the installments and the cost disclosure for prospective terms. It creates nothing and it changes nothing. Use it to show a borrower what the loan looks like before anyone commits. This step is optional. ## Submit *** The submit call creates the application in `pending_approval`. It carries the product version, the borrower, the requested principal, the requested **monthly** interest rate, the number of installments, and an expected disbursement date. Lender accepts up to 600 installments. One field is not in the body: the **assigned officer**. Lender takes it from the authenticated subject of the submit call. Later decisions are checked against that officer, so submit with the identity that will also approve and disburse. ## Decide *** Exactly one decision resolves a pending application. | Decision | Result | Who may act | | -------- | ------------------------------------------------------------- | ------------------------------------------------------------------------------------ | | Approve | `approved`, with the approved amount and a decision timestamp | The jurisdiction's approval policy. Under the generic profile, the assigned officer. | | Reject | `rejected` | The assigned officer. | | Withdraw | `withdrawn` | The borrower, or the assigned officer. | An approved application can still be withdrawn. `rejected` and `withdrawn` are final, and nothing moves out of them. The approved amount is a limit, not a payment. It bounds every disbursement that follows. ## Disburse *** Disbursement moves money, so it carries the most guards. Three things belong in the request: * An `X-Idempotency` header. Lender requires it on this operation. * The **loan account identifier**. It is a UUID you choose, and Lender does not mint one for you. The schedule, the transactions, the charges, and the audit trail are all addressed by it. * The gross requested amount and the net delivered amount. Lender checks five rules. It checks the first four before it writes anything. It checks the balance rule inside the disbursement transaction, so a failure there rolls the whole disbursement back. | Guard | Rule | | ---------- | ---------------------------------------------------------------------- | | Amount | Gross must not exceed the approved amount. | | Total | Gross across every tranche must stay within the approved amount. | | Chronology | The disbursement must not predate the approval decision. | | Identity | The loan account identifier must be the same on every tranche. | | Balance | Net must equal gross minus the withholdings the jurisdiction computes. | The balance rule is the one that surprises integrators. Under the generic profile there are no withholdings, so **net equals gross**. A lower net leaves the posting unbalanced and Lender rejects the disbursement. ## One transaction, four results *** A disbursement is a single database transaction. Four things happen inside it. Lender appends a disbursement event that records the amounts, the date, and the actor who disbursed. Lender computes a Price (French) amortisation schedule over the cumulative disbursed principal. It stores the result as schedule version 1, with the change reason `origination`. Under the generic profile the pipeline computes nothing, so it adds no withholding to the disbursement. Lender writes a balanced posting intent to the outbox: principal debited at gross, cash credited at net, and one credit for each withholding. All four commit together, or all four roll back together. There is no half-disbursed loan. If the schedule cannot be written, or the posting does not balance, the application stays `approved`. ## More than one tranche *** You can disburse an approved application more than once. The status stays `disbursed`, Lender appends another disbursement event, and Lender writes a **new schedule version** over the cumulative principal. The new version supersedes the previous one on read. The total across tranches still cannot exceed the approved amount, and every tranche uses the same loan account identifier. ## Two callers, one application *** Every lifecycle write states the status it expects to find. When two callers decide the same application at the same time, one wins and the other receives `409 Conflict` without changing anything. A repeated disburse that does not match the first one is refused the same way. ## The state model *** | From | Decision | To | | -------------------------------- | -------- | ----------- | | `pending_approval` | approve | `approved` | | `pending_approval` | reject | `rejected` | | `pending_approval` or `approved` | withdraw | `withdrawn` | | `approved` or `disbursed` | disburse | `disbursed` | ## What you have at the end *** * An application that reads `disbursed`, with one disbursement event per tranche. * A loan account under the identifier you supplied, carrying its schedule, its transactions, its charges, and its audit events. * A posting intent on the way to the ledger. That booking is asynchronous, so it lands shortly after the request returns rather than during it. * One lifecycle event on the streaming backbone for each transition. Continue in [Service a loan](/en/lender/service-a-loan). ## Next steps *** Record repayments, prepay, reschedule, and correct an active loan account. The domains, the jurisdiction seam, and the outbox that carries money out. Posting rules, accrual runs, and the journal reference that ties a booking back. IOF, CET, capitalization consent, and the rest of the Brazilian profile.