How the general ledger works
Books keeps one immutable, hash-chained journal. Everything else — every report, balance, and dashboard tile — is computed from it. Here is what that means in practice.
ConceptFor Business owners, Bookkeepers, Firm staff
One journal, many views
There is a single journal per legal entity. A bill, an invoice, a payroll run, a bank categorization, and a hand-typed adjusting entry all end up in the same place, as balanced entries with a date, accounts, amounts, and a source.
Nothing maintains a separate stored balance. The Trial Balance, the Balance Sheet, the account register, and the cash tile on your dashboard are all computed on demand from the journal. That is why they cannot disagree with each other, and why there is no "rebuild balances" operation to run when something looks wrong.
Entries are never edited in place
Once an entry is posted it is permanent. Correcting it means posting a reversal and then posting the correct entry. Both remain visible forever.
This feels heavier than editing a row until the first time someone asks why a number changed between two versions of a report you sent them. With an immutable journal that question has an answer, with a date and a name attached.
What immutability buys:
- A report you exported last month can be reproduced exactly today.
- Every change has an actor and a timestamp in the audit trail.
- Reconciliations stay reconciled — a cleared line cannot be altered underneath a locked statement.
- Auditors can verify the ledger has not been rewritten, rather than taking your word for it.
The hash chain
Each posted entry is chained to the one before it with a cryptographic hash. Altering or removing a historical entry would break every link after it, and the Audit Trail's chain verifier walks the whole chain to prove it has not happened.
The chain head is also stamped to an external timestamping service on a weekly schedule, which produces independent evidence of what your ledger contained at a point in time — evidence that does not depend on trusting Backline.
Where entries come from
Every entry carries its provenance, surfaced as the Source column on list screens and in a provenance popover on individual records.
| Source | Meaning |
|---|---|
| Manual | A person typed it in the workspace. |
| Document | Derived from an uploaded or emailed document by intake. |
| Bank feed | Originated from imported or connected bank activity. |
| Subledger | Generated by a bill, invoice, payment, payroll run, or depreciation run. |
| API | Posted by an integration using an organization API key. |
| AI | Proposed by automation and posted after passing its safety checks. |
Common questions
No. You reverse it. The reversal posts an equal and opposite entry dated as you choose, and both entries stay in the journal with a link between them.
See alsoCorrecting a posted entry
Because activity was posted for dates inside the report period after you exported it — back-dated bills, a late bank import, an adjusting entry. The Audit Trail's event log shows exactly what was posted and when.
If the period is closed, back-dated posting is refused, which is precisely why closing periods matters.
See alsoPeriod locks and closing the booksThe audit trail and chain verification
Only for work it can complete deterministically and safely, and those entries are marked with an AI source. Anything ambiguous becomes an exception for a person to resolve.
See alsoHow the AI in Books works
Was this useful?