Immutability · PG-15
An immutable ledger for accounting — and not a blockchain
Append-only enforced at the storage layer, a chain hash on every Final entry, and an independently runnable verifier — no vendor trust required.
- chain on by default
- verify offline
- SHA-256, algorithm-tagged
- typed corrections only
An immutable ledger for accounting means posted records cannot be altered or deleted: the final store rejects UPDATE and DELETE at the storage level, every Final entry carries a cryptographic chain hash, and later economic changes enter as new, typed entries — reversal, adjustment or restatement — linked to the original. Ledgerbook AI implements that without blockchain: append-only storage, a hash-chained event stream with per-batch Merkle roots and per-event inclusion proofs, an online or offline verifier any third party can run, and as-of reads that reconstruct both the balance and what was believed on a past date. Chain hashing is on by default and cannot be switched off.
Verified 2026-09-19 · Sources: Ledgerbook product docs — immutability (FR-214, FR-118–121) and corrections (FR-205) · Phase: PH-1
Phase legend: PH-1 shipped now · Roadmap arrives with PH-2. Labels are always present — colour is never the only signal.
How the chain works — and why it cannot quietly change
Immutability here is a property of the data path, not a policy promise: each layer removes a different way to rewrite history, and each fails closed when it cannot verify. Together they are the answer to the non-rewriteable, non-erasable record condition regulators test for — WORM-grade audit trails without WORM media, in the SEC Rule 17a-4 pattern, where the evidence is a verification you can run rather than a media certificate.
| Layer | Mechanism | What it forecloses |
|---|---|---|
| Storage | The final store rejects UPDATE and DELETE at storage level — role revocation plus a database trigger — and offers no soft-delete that could detach Final entries from reports. | In-place mutation; "deleted but reported" ambiguity · FR-214 |
| Entry | Every Final entry is sealed with a chain hash: hash_n = H(prev_hash ‖ canonical_payload), with a defined genesis per ledger and SHA-256 by default. The chain is on for every ledger and cannot be disabled by writers or configuration shortcuts. | Retroactive rewrite of sealed entries · FR-118/119 |
| Event stream | Every event carries prev_hash/hash over its canonical serialization, in insertion order — every commit, even micro-edits — with batch-level Merkle roots at volume. | History surgery between checkpoints; provenance tampering · FR-237/524, FR-208 |
| Algorithms | The hash payload carries its serialization/schema version and algorithm id; the algorithm registry is data, migration is segment-wise, and unknown or missing algorithm ids fail closed on both writes and verification. | Silent downgrades; migration invalidating old proofs · FR-120/122/810 |
Scope note: "every entry is chain-hashed" always means every entry once Final — pre-finalization entries are protected by the append-only event chain and per-revision content hashes until sealed. Roadmap The post-quantum hybrid suite (ML-KEM / ML-DSA) and external anchoring ride the PH-2 schedule; the crypto-agility seams that make them a migration rather than a re-architecture ship at PH-1.
Verify it yourself — do not take the vendor's word
Verification must be reproducible, not asserted. Ledgerbook chain-hashes every event, publishes per-batch Merkle roots and per-event inclusion proofs, and ships an independently runnable verifier: given a root and an audit tuple, it recomputes the balance from chain data alone and detects any retroactive rewrite.
- Online. A verify operation recomputes the chain and returns PASS — or the first divergent entry with its location and expected/actual hash.
- Offline. The same check runs against a signed ledger export in an air-gapped environment; the same signed export replays into a fresh deployment, materialising ledger state — air-gap transfer and host migration are first-class operations, not bespoke tooling.
- Against published roots. The verifier reproduces any balance from the audit tuple plus inclusion proofs, so an auditor detects a retroactive rewrite without ledger access.
Roadmap The published correctness-evidence regime (repeated build evidence for auditors) and external timestamp/witness anchoring are PH-2 — deliberately off the critical path.
Recompute the chain over a range and get PASS, or the first divergence with expected and actual hashes. A tampered payload fails at the offending sequence — the error names it.
FR-121 · PH-1
For the tuple (E, K, scope): checkpoint hash, redo sequence range and inclusion proofs — enough for a third party to recompute the balance from the chain alone.
FR-813, FR-516 · PH-1
# online — recompute the chain from genesis
$ ledgerbook verify --chain grp-eu --from genesis
chain grp-eu
sealed ledger_seq 184220
result PASS
root sha256:3d81…c04e (batch 1847 · 2026-09-19)
# divergence is named, never summarised
result FAIL at ledger_seq 120411 expected 7ab3… actual c19f…
# offline — same check against a signed export, air-gapped
$ ledgerbook verify --export grp-eu-2026-Q3.ocel.json
result PASSThe verifier runs from the chain alone; a fixture chain ships with the developer preview so the check can be reproduced before deployment. FR-121/813 · PH-1
The same query, the honest answer: not blockchain
Chain-hash tamper-evidence and distributed-ledger technology solve different problems. One is a data-integrity mechanism inside your accounting record; the other is a consensus system for multi-party truth. Ledgerbook uses only the first.
| Dimension | Ledgerbook chain-hash | Public blockchain / DLT |
|---|---|---|
| What seals the record | A per-entry chain hash over the canonical payload, genesis per ledger, every event chained in insertion order. | Consensus over a replicated, shared ledger. |
| Who verifies | Any third party with the export, the published roots and the verifier — offline, no vendor access. | Network participants, per the protocol's rules. |
| Where the data lives | Your infrastructure. PII never enters hashed ledger payloads — off-ledger vault, on-ledger commitments only. | Replicated across the network; erasure is protocol-dependent. |
| Corrections | Typed new entries — reversal, adjustment, restatement — linked to the original; nothing is edited. | Protocol-dependent, often immutable-by-default with no accounting vocabulary. |
| Independent time | Roadmap External timestamp/witness anchoring ships PH-2, off the critical path. | Intrinsic to consensus — this is where public chains genuinely win. |
| Erasure story | Commitments stay verifiable while per-subject keys are destroyed — crypto-shredding ships at PH-1, within 30 days including backups and caches, with legal hold suspending it. | Not an accounting-grade erasure model; legal-hold conflicts are unsolved in practice. |
The design in one line: hashes on the ledger, PII off it. Commitments keep the audit trail verifiable through erasure, and the erasure act itself is a provenance event. Legal-hold regimes suspend erasure for affected subjects.
FR-808, NFR-11 · PH-1
Why can't you edit a finalized journal entry?
Because an edit would destroy the evidence trail — the audit question is not only what the number is, but what it was and who changed it. Once Final, an entry's postings cannot be modified or deleted; a later change is recorded as a new typed entry — reversal, adjustment (for IAS 10 adjusting events) or restatement (error corrections) — linked to the original. Both the mistake and its fix stay visible and attributable.
Verified 2026-09-19 · Sources: Ledgerbook product docs — correction semantics (FR-205, FR-123–125, FR-228) · Phase: PH-1
The original entry stays byte-identical and gains a corrected-by relationship to the new one; the correction carries its type on every surface — REST, events, MCP and OCEL exports. "Revision" is provisional-edit vocabulary only and is never used as a correction type. Full lifecycle mechanics live on the Provisional → Final lifecycle page.
Immutability FAQ
What is an immutable ledger for accounting (not blockchain)?
In accounting, an immutable ledger means posted records cannot be altered or deleted — corrections are added as new, typed, attributable entries. Ledgerbook implements that with append-only storage, chain-hashed event history and typed corrections (reversal, adjustment, restatement); no blockchain is involved and no wallet-custody semantics apply. Third parties can verify the chain without trusting the vendor.
How do you make accounting data immutable?
Three layers. Storage refuses UPDATE and DELETE for posted rows — revoked privileges plus a defending trigger, with no soft-delete that could detach Final entries from reports. Every Final entry carries a chain hash over its canonical payload, on by default and not disableable. And any later economic change enters as a new, typed entry linked to the original: history is appended, never rewritten.
FR-214, FR-118/119 · PH-1
How do you verify a ledger hasn't been tampered with?
Verification must be reproducible, not asserted. Ledgerbook chain-hashes every event, publishes per-batch Merkle roots and per-event inclusion proofs, and ships an independently runnable verifier: given a root and an audit tuple, it recomputes the balance from chain data alone and detects any retroactive rewrite. External anchoring with a timestamp or witness service is a roadmap item, deliberately designed to sit off the critical path.
Related: Run the verifier · Provenance & OCEL 2.1 · FR-524/813/516 · PH-1 (anchoring Roadmap)
After a correction, is the original entry still in the chain?
Yes — that is the point. The original entry stays byte-identical and gains a corrected-by relationship to a new entry typed reversal, adjustment or restatement. Both the mistake and its fix stay visible, attributable and chain-linked — and the correction is itself a chain-sealed event like any other. Correction semantics.
Verify the ledger — don't take our word
Chain-hashed by default, verifiable offline, correctable only by provable, attributable entries.