Skip to main content
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:

Posted Change, Not Balance

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.

Integer Cents

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. 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:

The Incurred Region

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.

The Payment Region

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.
1

Create an $800 legal fee invoice

2

Pay it

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.
1

Reserve $50,000 of Indemnity on the [event](/financials/pages/event-financials-tab)

Declaring a reserve moves money between two accounts. Nothing has been invoiced and nothing has been paid.
2

Create a $15,000 Indemnity invoice

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.
3

Pay the $15,000, updating reserves

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.
Where that leaves the event:

​
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: 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. 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 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.