> ## Documentation Index
> Fetch the complete documentation index at: https://docs.go.aiinsurance.io/llms.txt
> Use this file to discover all available pages before exploring further.
# The Ledger
> Balanced double-entry rows, and the invariant every one of them satisfies
The **ledger** is the record of effect: which accounts an action moved money
between, and by how much. It is double-entry, append-only, and balanced by
construction.
Where the [journal](/financials/accounting-model/journal) says *"a \$5,000 payment
was recorded"*, the ledger says *"\$5,000 left Cash and \$5,000 came off Indemnity
Payable"*.
## What a Ledger Row Carries
| Field | What it is |
| ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Account** | Which [account](/financials/pages/chart-of-accounts) this row posts to. |
| **Amount** | Signed integer cents. **Positive is a credit, negative is a debit.** Never zero. What a credit or a debit *means* depends on the account it lands on — see [Signs, Concretely](#signs-concretely). |
| **Effective date** | The date this money is effective for accounting purposes. |
| **Journal** | The action that appended this row. |
| **Leg** | A label naming the row's part in its action's recipe — `lineItem`, `balance`, `cash`, `reserves`, `unpaid`, or `additional`. |
| **Book** | The single book every row belongs to. There is one, in cents. |
The **leg** is audit vocabulary and nothing more. It carries no behavior: it is
there so a batch of rows can be read back and understood without reconstructing
which recipe produced it. A reversal row keeps the leg name of the row it negates
— what makes it a reversal is its action type, never its leg.
## Every Action Appends One Balanced Batch
An action does not append rows one at a time. It produces a **batch**, and the
batch is checked as a unit before anything is written:
The amounts sum to exactly zero — and they do so **per effective date**. A
batch spanning two dates must balance at each of them independently, not just
overall.
Every amount is a nonzero whole number of cents. A row that would post nothing
is dropped before the batch is assembled, not written and ignored.
Every account posted to must exist and belong to this company. There is no
such thing as an account that exists but cannot be posted to.
Each row is stamped with the journal row the batch was assembled for. A row
that names a different action fails the batch.
If any of these fails, nothing commits — not the ledger rows, not the journal
row, not the projection. The whole action is refused as an internal error, because
a batch that does not balance is a bug in the engine, never something a user
typed.
An **empty** batch is legal, and normal. Re-linking an invoice to a different
event, approving one, or voiding one that had nothing posted all append a journal
row and no ledger rows at all — the act is recorded, but no money moved.
## Signs, Concretely
**Direction** — whether money is flowing into or out of the business — is never
carried by the sign of a ledger amount. The sign carries **debit or credit**, in
the ordinary accounting sense. Which way money is actually moving is only
interpretable once you also know whether the account being posted to is
**debit-normal** or **credit-normal**:
| | Debit-normal accounts | Credit-normal accounts |
| ------------------------------ | --------------------- | ---------------------- |
| Which accounts | Assets, Expenses | Liabilities, Income |
| A **debit** (negative amount) | Increases the balance | Decreases the balance |
| A **credit** (positive amount) | Decreases the balance | Increases the balance |
So a positive amount is a credit either way, but a credit to Cash means money
left the business, while a credit to a Payable means the business now owes more.
The same sign, opposite stories — the account is what disambiguates them.
This is why the balancing invariant works at all. Every action's rows sum to
zero, and yet each row means something different, because the meaning lives in
the pairing of *sign* and *account*, not in the sign alone.
An expense invoice of \$800 for legal fees on an Operating type posts two rows:
| Account | Leg | Posted Change | Reads as |
| ----------------------- | ---------- | ------------- | ------------------------------------------------------------------------ |
| ALAE Legal Fees | `lineItem` | −80,000 | Debit \$800 to a debit-normal expense account — an expense is recognized |
| ALAE Legal Fees Payable | `balance` | +80,000 | Credit \$800 to a credit-normal liability — the business now owes \$800 |
They sum to zero. Paying it posts the opposite side of the liability against Cash.
This sign convention is internal to the ledger, and is **not** the convention on
screen or in exports. Screens show unsigned magnitudes with direction in color;
exports take a sign from the configured reference frame. See [Reference
Frames](/financials/reference-frames).
## Effective Date Is Not Entry Date
Every row carries both:
* **Effective date** — the accounting date. On an invoice's postings this is its
invoice date; on a payment, the payment date.
* **Created at** — when the row was actually written, taken from the action.
These are independent on purpose, and that independence buys three distinct
things.
Recording a March payment in April posts it effective in March, where it
belongs, while the audit trail still shows it was entered in April.
A row can be posted with an effective date that has not arrived yet.
Because every row is dated and none is ever amended, the books can be read as
they stood on any date.
### Future Dating
Money can be recorded **before** it influences the books. An invoice raised now to
collect policy premium on the first of next month posts effective on that date: it
is a real record from the moment it is entered, visible and auditable, but it does
not appear in this period's figures.
This is what makes scheduled and anticipated money expressible without a separate
"pending" concept. There is one kind of record, and its effective date decides
when it counts.
### Point-in-Time Reads
Nothing in the truth tier is ever amended or removed, and every row carries the
date it is effective for. Together those two properties make a question like
*"what did Financials look like on 31 December?"* answerable exactly: read every
ledger row effective on or before that date and ignore the rest.
A correction entered in February does not retroactively change what December
looked like — it is a new row with its own effective date. Whether it lands in
December or February is a property of that date, and the reconstruction respects
it either way.
This is only true because the ledger is append-only. A model that updated rows in
place could report today's balances, but could never reliably reproduce
yesterday's — the old values would be gone.
### Date Corrections Need No Special Case
Changing an invoice's date does not rewrite the old rows: the postings are
**reversed at the old date and reposted at the new one**, because the effective
date is part of what identifies a posting. Both dates balance independently, and
a point-in-time read of either date stays correct.
## Integer Cents, One Book
Every amount is a whole number of cents, in a single book. No figure in Financials
is ever a floating-point number at any point in its life, so no total ever drifts
by a penny and no rounding rule has to be agreed on. A batch either sums to zero
exactly or it is rejected.