> ## 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.
# What Each Action Posts
> Reserving, invoicing, paying, and voiding, traced through the accounts
Four recipes cover every posting in Financials. Which one runs is decided by two
things and nothing else:
* the **kind** of the invoice's type — Operating or Loss/Recovery;
* the **direction** of the line item being posted — expense or income.
That is the whole branch table. Everything below is those four recipes applied at
two moments in an invoice's life.
## Reading the Tables Below
Each table is one action's **ledger batch** — the complete set of rows that action
appends. Two conventions to keep in hand:
Every figure is the **change this action posts**, never a resulting balance. An
account's balance is the sum of every change ever posted to it.
Amounts are whole cents, exactly as stored — \$800 posts as **80,000** and
\$15,000 as **1,500,000**. Nothing in the ledger is ever a decimal, which is
why no total drifts by a penny.
Sign is debit-or-credit, not direction: positive is a credit, negative a debit,
and what either *means* depends on the account it lands on. See [Signs,
Concretely](/financials/accounting-model/ledger#signs-concretely).
Every batch below sums to zero, which is the invariant each one is checked
against before it is written.
## Two Regions
An invoice's postings fall into two groups, and they are reconciled
independently:
What the invoice *commits* to move, posted at its invoice date. Written by
creation, finalization, and update; reversed by void and delete; rewritten by
restore.
What has *actually* moved, posted at each payment date. Each payment is its own
region, together with any later removal of it.
Keeping them separate is what lets an invoice's dates be corrected without
disturbing its payments, and a payment be removed without touching what the
invoice committed to.
## An Operating Invoice
The simple case. An expense line recognizes the expense immediately and creates a
liability; paying it settles that liability against Cash.
| Account | Leg | Posted Change |
| ----------------------- | ---------- | -------------------------------------- |
| ALAE Legal Fees | `lineItem` | −80,000 *(debit — expense recognized)* |
| ALAE Legal Fees Payable | `balance` | +80,000 *(credit — liability created)* |
| Account | Leg | Posted Change |
| ----------------------- | --------- | ------------------------------------- |
| ALAE Legal Fees Payable | `balance` | −80,000 *(debit — liability cleared)* |
| Cash | `cash` | +80,000 *(credit — cash goes out)* |
An **income** line on an Operating type is the exact mirror: the line item account
is credited, a Receivable is debited, and collecting the money debits Cash.
## A Loss/Recovery Invoice
Here the reserve is involved, and the expense is recognized **at payment**, not at
invoicing. Three separate acts, each balancing on its own.
Declaring a reserve moves money between two accounts. Nothing has been
invoiced and nothing has been paid.
| Account | Leg | Posted Change |
| ----------------------- | ---------- | --------------------- |
| Indemnity Reserves | `reserves` | +5,000,000 *(credit)* |
| Indemnity Unpaid Losses | `unpaid` | −5,000,000 *(debit)* |
Invoicing against a reserved type does **not** hit an expense account. It
converts reserve into a payable — the reserve is drawn down by exactly what
the invoice commits to.
| Account | Leg | Posted Change |
| --------------------------- | ---------- | ----------------------------------------- |
| Indemnity Reserves | `reserves` | −1,500,000 *(debit — reserve drawn down)* |
| Indemnity Indemnity Payable | `balance` | +1,500,000 *(credit — liability created)* |
The payment does four things at once: clears the payable, moves the cash,
recognizes the expense on the line item, and takes relief on Unpaid Losses.
| Account | Leg | Posted Change |
| --------------------------- | ---------- | ----------------------------------------- |
| Indemnity Indemnity Payable | `balance` | −1,500,000 *(debit)* |
| Cash | `cash` | +1,500,000 *(credit — cash goes out)* |
| Indemnity Indemnity | `lineItem` | −1,500,000 *(debit — expense recognized)* |
| Indemnity Unpaid Losses | `unpaid` | +1,500,000 *(credit — relief)* |
Where that leaves the event:
| Account | Balance | Reads as |
| --------------------------- | --------------- | -------------------------------------------- |
| Indemnity Reserves | \$35,000 credit | \$35,000 still expected to move |
| Indemnity Unpaid Losses | \$35,000 debit | the same \$35,000, reserved and not yet paid |
| Indemnity Indemnity Payable | \$0 | nothing invoiced and outstanding |
| Indemnity Indemnity | \$15,000 debit | \$15,000 of loss recognized |
| Cash | \$15,000 credit | \$15,000 has left the business |
### Updating Reserves, or Not
The relief leg on that final step is the one place a payment on a Loss/Recovery
type has a choice, and it is the choice behind the prompt described in
[Reserves](/financials/reserves#when-the-app-asks-how-to-record-a-payment):
| Choice | Relief posts to | Effect |
| --------------------------------------------------------------------- | ----------------------- | -------------------------------------------------------------------------------------------- |
| **Update Reserves** — the estimate was too low | **Unpaid Losses** | The payment draws down what was reserved |
| **Update Expected Totals** — the payment is additional to the reserve | **Additional Incurred** | Unpaid Losses is left alone; the payment is recorded as incurred over and above the estimate |
Everything else about the posting is identical. This is why the two answers record
the same money and disagree only about what the claim is now expected to cost.
A recovery-oriented Loss/Recovery type mirrors all of the above: Reserves is
debited where it was credited, relief lands on **Unpaid Recoveries** or
**Additional Recovered**, and collecting money debits Cash instead of crediting
it.
## Corrections Are Reversals
No correction removes a ledger row. Instead, the engine works out what the
invoice's postings **should** be now, compares that to what is **currently**
posted, and appends exactly the difference.
| Action | Target for the region | What gets appended |
| -------------------- | ------------------------------------ | ------------------------------------------------------ |
| **Update** | Recomputed from the new field values | Only what changed |
| **Void** | Nothing at all | The exact negation of everything currently posted |
| **Restore** | The incurred postings again | The negation of the void — the original postings, back |
| **Delete** | Nothing, in both regions | Negations sweeping the incurred *and* payment regions |
| **Remove a payment** | Nothing, for that payment's region | The negation of that one payment |
Because a posting is identified partly by its **effective date**, a date change
needs no special handling: the old date's rows are reversed and the new date's are
posted, and both dates balance independently.
Anything already correct posts nothing. Updating an invoice's memo produces a
journal row and an empty ledger batch, because the recomputed target is identical
to what is posted. This is why an audit trail of financial actions contains
entries with no money attached — the act happened, and it moved nothing.
## Resetting Reserve History
A [reserve history reset](/financials/reserves#resetting-reserve-history) is the
one action that reasons over a whole scope rather than one document. It reads the
current net of that type's reserve accounts on that event, and posts a single
batch that returns the reserve balance to zero — clearing Unpaid Losses, moving
Reserves back to just what the event's invoices have drawn, and absorbing the
remainder into Additional Incurred.
Payments recorded before the reset are already accounted for by it. If one of them
is later removed, the reset would otherwise be left describing money that no
longer exists — so the removal appends a **companion** correction at the original
reset's effective date, keeping the reset's arithmetic true.