Skip to main content

​
The entry in the ledger

What you are doing. Confirming that the book moved by exactly the number printed on the document. View journal entry opens the General Ledger focused on that entry: its lines, the native amount, the rate, and a totals row that says balanced ✓. The header shows the book as a whole: the number of posted entries, total debits, total credits, and whether they agree. That header is a one-second sanity check on the entire ledger, and it is worth glancing at every time.
Match on the document reference, not the entry number. The ledger identifies this entry by its document reference, TW-GUIDE-A1. It does not print the JE-000020 number the review page quoted.

​
That is the whole loop

Paper, or a form → a hashed PDF → a signed document → a reviewed intake row → a drafted entry → a second approval → an immutable, hash-chained line in your general ledger.

​
What just happened underneath

The write did rather more than insert two rows.

A per-org advisory lock was taken

So two concurrent postings cannot both extend the hash chain from the same head.

18 GL invariants were validated

Balance, one-sidedness, non-negative decimals, account ownership, currency and rate resolution, required dimensions, and an open period. On any failure the writer raises and writes nothing.

An entry number was allocated monotonically

Per org, so entry numbers cannot collide or go backwards.

The entry was chained

The versioned checksum binds the previous checksum, the entry head and the canonical lines. The canonical form sorts the lines and stringifies the decimals, so neither line order nor 10 versus 10.0000 can change a checksum.

An event was appended to the event stream

Itself hash-chained. There are two chains over this entry, not one.

​
What you cannot do here, and why

You cannot edit this entry. Database triggers reject an UPDATE on a posted entry, so the rule holds even against a direct SQL session, not just against the application. You cannot delete it. The only correction is a reversing entry, which is itself a posted event with its own canonical reversal control and writer provenance. You cannot quietly change it. Every entry is chained to the one before it, and the Auditor recomputes the chain rather than trusting a stored flag. A tampered entry breaks the recompute, and the Auditor reports it.
This is the trade the whole product makes. Immutability is inconvenient exactly once, at the moment you notice a mistake. It is valuable every other moment, because it is what makes the book worth reading.

​
Sub-ledgers

The sibling tab answers the questions the journal cannot. Subledgers gives you who you owe and what is in the bank, rolled up from the same entries.
A control-account leg and its sub-ledger row are one fact. Nothing posts one without the other: every path that credits the AP control account goes through a single writer for the obligation, in the same transaction as the entry. So the sub-ledger and the control account cannot disagree, and the Close checksum that ties them is checking something real rather than a value against itself.

​
Finding it again

Reading the General Ledger

The filters, how to read one entry, and the sibling tabs.
Lineage runs in both directions. From Books → Review, open the posted row and click View journal entry; from Transactions, open the event to read its native source, approved workpaper and intake document when those records exist. An unresolved historical source remains missing or legacy_unverified rather than being inferred from a label.