Balances are projections over an append-only journal, not stored figures kept in step by a nightly job. There is one source of truth because there is only one place the number exists.
There is no update and no delete in the journal API. A mistake is corrected by a reversal entry linked to the original, so history is never rewritten.
An entry whose debits do not equal its credits is refused at post time. Not flagged in a report the next morning — refused.
No period-end rollup, no rebuild. Ask for a balance as of any date and it is computed from the entries that existed then.
Every entry needs at least two lines, every line a positive amount and a known account, and the debit and credit totals must match exactly. These are checks in the post path, not conventions in a manual.
Balance → ledger rows → journal entry → source document. Because the balance is derived from the rows, the path can never lead somewhere that disagrees with where it started.
Account type fixes the normal balance side, so the accounting equation is structural rather than conventional. Parent accounts must share their children's type.
Debits and credits totalled from the same journal the statements read. A trial balance that does not balance is impossible unless the journal itself was corrupted — and the journal refuses to be.
reverse() flips an entry's lines into a new entry that references the original. An entry can be reversed once, and a reversal cannot itself be reversed — post a fresh correct entry instead.
Every entry is scoped to one organization, and there is no code path that reads another's data. The chart, journal and ledger for an org are checked against each other at construction.
The demo runs on a seeded company with a live close waiting — two real blockers and agents holding proposals.