> ## Documentation Index
> Fetch the complete documentation index at: https://docs.capcells.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Concepts

> The objects the Platform holds, what each one is made of, and how one leads into the next.

The Platform holds a small set of objects, and each one leads into the next. A Product fixes the terms you sell. A Loan is issued under one version of it, a Schedule plans the repayment, and a Receipt reports the money that arrives.

## Scope

You hold the funds. Money arrives in your own account and you report that it arrived.

The Platform initiates no transfer, touches no bank and holds no balance. It derives which Loan, which Period and which charge a Receipt settled, from what you reported rather than by matching amounts, dates or references.

Loans are issued under Mexican rules: the CAT disclosure, VAT on interest and the penalty caps. A Loan naming another jurisdiction is refused.

## Setup

Three objects exist before any Loan does.

### Tenancy

A **Tenancy** is your business on the Platform. It is registered once as `sandbox` or `live`, and every Product, Client, Loan and Receipt you create belongs to it.

Nothing is shared between two Tenancies. A key authenticates for one Tenancy, every request path names it, and your own Reference is unique inside it. [Sandbox and live](/getting-started/environments) carries what each kind permits.

### Product

A **Product** is a versioned set of terms that Loans are issued under. It carries the principal bounds, the rate corridor, the fees, the term menu and the cadence of the Schedule.

Every Product is built on one **Archetype**, which fixes the repayment shape and decides which fields the Product carries. You choose among the three the Platform defines and cannot declare a fourth.

| Archetype    | Repayment shape                                                                                        |
| ------------ | ------------------------------------------------------------------------------------------------------ |
| `instalment` | A principal repaid over a menu of terms, each payment carrying principal, interest, fee and tax.       |
| `bnpl`       | A purchase split into instalments, always collecting a payment at the purchase itself.                 |
| `payday`     | A single period carried to one date, with no term menu, and the only Archetype that admits a rollover. |

A Product is never edited in place. A change writes a new version, every earlier version stays readable, and a Loan keeps the version it was issued under.

### Client

A **Client** is an identifier you register for someone you lend to. It is registered before a Loan can be issued, and it is the whole of what the Platform asks about that person.

No personal data sits behind it: no name, no date of birth, no address, no identity document and no contact. The one free-text field is a label the Platform never reads.

A registration is never withdrawn. Loans and Receipts name these identifiers, so a registration removed would leave records naming a Client the registry says was never registered.

## Lending

A Loan is where terms stop being a configuration and become an agreement.

### Loan

A **Loan** is a debt issued to one Client under one version of one Product. Everything the agreement costs is priced at issuance: the Schedule, every Period's amounts, and the CAT the borrower is shown.

A later change to a rate, a fee, a holiday set or a Product does not reach those figures, because nothing recomputes them. A read returns the rows issuance wrote.

Where a Loan stands is not a stored column. It is folded from that Loan's own recorded facts on every read, and four states are reachable: `active`, `cancelled`, `closed` and `written_off`.

### Schedule

A **Schedule** is the set of Periods a Loan is planned to be repaid over. Its dates come from the Product's cadence, and a due date landing on a non-working day moves forward to the next one.

That move shifts collection and not interest. Interest runs between the scheduled dates, because the holiday is a property of the Platform's calendar rather than of anything the borrower did.

### Period

A **Period** is one step of a Schedule. It carries two dates and five amounts: principal, interest, fee, tax, and the payment that sums them.

Periods mature one at a time. What has matured fixes what a Receipt settles first, what counts as overdue, and what a prepayment must reach past.

## Money

You hold the funds, and the Platform derives what they settled.

### Receipt

A **Receipt** is your report that money arrived from a Client on a date. It is addressed to a Client rather than to a Loan, because a Client may hold several.

The date it carries is the value date, which is when the funds arrived rather than when you reported them. Interest, penalty and the order of allocation all run on it.

No Receipt is refused for its size. Less than due, more than due, more than the whole Loan, and money on a Loan that owes nothing are all recorded.

### Election

An **Election** is the borrower's statement of what a Receipt's money does once every matured Period stands settled. It is stated on the Receipt, and stating nothing is the ordinary case.

| Election    | What the remainder does                                                                                 |
| ----------- | ------------------------------------------------------------------------------------------------------- |
| `principal` | Reduces outstanding principal; the plan is recalculated, the term is kept and the payments fall.        |
| `term`      | Reduces outstanding principal; the plan is recalculated, the payment is kept and the schedule shortens. |
| `advance`   | Settles Periods that have not matured, at the figures the plan schedules for them, oldest first.        |
| `payoff`    | States that this Receipt discharges the Loan, which no amount on its own can state.                     |

Neither prepayment is gated by a Product. Both are the borrower's own right, so a Product that ordinarily advances instalments still yields to a Receipt electing `principal`.

### Allocation

An **Allocation** is the derived answer to what a Receipt settled: which Loan, which Period, which charge. No table holds it, and it is recomputed from your reported Receipts in value-date order every time it is asked for.

It is decided at two levels. Between the Loans it honours the borrower's designation where you passed one on, and otherwise applies the jurisdiction's supplementary rule. Within one Loan it walks the matured Periods oldest first, settling each Period's charges in the order that jurisdiction fixes.

Two things about that order are not jurisdictional, and no rule overrides them. Principal is settled last, and a matured obligation is settled before a later one.

### Obligation

An **Obligation** is what you owe a Client back. Money above everything that Client owes is recorded as one rather than discarded.

The Platform neither returns it, offsets it nor recognises it as income.

## Lateness

Lateness costs a Loan money, and that cost is derived rather than posted.

### Arrears

**Arrears** are what lateness costs a Loan: the penalty, the late fee, and the tax on each. They start once a Period stands unpaid past its due date and its grace days.

No job posts them. They are derived for the date your request names, from every fact on record at the moment you ask. A Receipt reported late therefore changes the answer for each date after its value date.

The terms they accrue under are frozen at issuance: the penalty rate, the late fee and the grace days the Product version carried.

### Write-off

A **Write-off** is your judgement that a Loan is uncollectable. Charging stops from the date you name, and the Loan reports `written_off`.

It releases nobody. The debt survives in full, stays collectable, and money arriving afterwards is recorded against it.

## Corrections

Nothing recorded is edited or deleted, so a wrong fact is undone from the outside.

### Withdrawal

A **Withdrawal** is how a recorded fact stops counting. A Receipt is reversed, a recorded Loan event is retracted, and the withdrawn record stays readable while contributing to nothing.

Every figure is then derived again without it. A closure withdrawn by the reversal of the Receipt that caused it is not repaired; the fold produces whatever state now follows.

### Anomaly

An **Anomaly** is a disagreement the Platform resolved, or a figure it could not establish. It is reported in `anomalies` beside the answer rather than raised as a failure.

No figure the Platform cannot state arrives as `null`. The field is left out and `anomalies` names why.

## Relationships

Seven lines carry the model, in the order the objects lead into one another.

1. a Tenancy holds every record you create
2. a Product fixes the terms, one Archetype and one version at a time
3. a Client is who a Loan is issued to
4. a Loan freezes those terms and is repaid over a Schedule of Periods
5. a Receipt reports money that arrived
6. an Allocation derives which Loan, Period and charge it settled
7. Arrears derive what lateness cost

```mermaid theme={null}
flowchart LR
  T["Tenancy"] --> P["Product"]
  T --> C["Client"]
  P --> L["Loan"]
  C --> L
  L --> S["Schedule"]
  R["Receipt"] --> A["Allocation"]
  A --> L
```

Election, Obligation, Write-off, Withdrawal and Anomaly qualify those seven rather than standing beside them. [Model](/getting-started/model) carries the conventions every one of them is written in.
