Headless · MCP-native · self-hostable
The ledger of record your agents may write to — and your auditors can verify.
Ledgerbook AI is the headless, MCP-native accounting data layer: one immutable, bitemporal book of record for every system you run — deployed in your own infrastructure, correctable only by provable, attributable entries.
- chain-hashed by default
- verify offline
- air-gap installable
- fiat, exact-decimal money
Phase legend: PH-1 shipped now · Roadmap arrives with PH-2. Labels are always present — colour is never the only signal.
Proof primitives
OCEL 2.1
audit-export format, schema-validated in CI · FR-905
T0/T1
materiality tiers evaluated server-side · FR-217
ISO-4217
fiat only; integer minor units, no floats anywhere · FR-107
0
models in the posting path — agents interact via MCP · NG-4
The intelligence layer is arriving faster than the data layer can support it.
Three conditions every finance stack shares, and no closed application fixes from the inside.
Truth is fragmented
Balances live across ERPs, banks, billers and spreadsheets. Each system answers a different question in a different vocabulary, and the consolidation sink is a spreadsheet.
Provisional numbers have nowhere to live
Teams either post early or report late. Either way the evidence of what was believed, and when, is destroyed before anyone asks.
Agent writes are ungoverned
Agents are being handed write access with no per-action provenance, no materiality gate and no content-bound approval. That is a control failure waiting for an audit.
One record you can prove. Writes you can govern. A ledger you can own.
PH-1
One record you can prove
Every Final entry is chain-hashed, on by default. Corrections are typed reversals, adjustments or restatements — never edits. Every read answers as-of: the balance at a date, and as you believed it then.
Immutability & verification →PH-1 · T0/T1
Writes you can govern
Agents propose; they cannot approve, finalize or correct — enforced at the credential, not the prompt. Approvals are content-hash-bound, and any edit voids a pending approval. Every mutation is a provenanced event.
MCP server & governance →PH-1
A ledger you can own
Self-hosted and air-gapped is first-class: a VM, a bare-metal HA cluster, or an offline bundle with zero egress. No proprietary formats — OCEL 2.1 and open interfaces. Your plan data lives here too, not in a copy.
Self-hosted & air-gap →One object, one identity — never an edit
Provisional and Final are the public lifecycle terms. Corrections are new, typed entries; the original stays exactly where it was.
-
Provisional T0 · entry.created
Every material edit appends an immutable revision — actor, timestamp, content hash — to the same entry object. Nothing is overwritten.
-
Final one-way · entry.finalized
Finalization seals that same object: postings become immutable, the entry id never changes, and the chain hash is on by default.
-
Correction entry.reversed · entry.corrected
Later economic changes arrive as typed reversing, adjusting or restating entries, linked to the original. The mistake and the fix both stay visible.
-
T2/T3 approval tiers
Roadmap
Period states, close gates and the higher approval tiers are ledger-native by design and arrive with PH-2.
One entry, three axes
Every posting answers three independent questions at once, on the same double-entry core. Nothing is copied between them, and none of the three collapses into another.
PH-1
Scenario — which reality
Actual, Budget, Forecast, Plan, Simulation, or a custom variant. Budget, Forecast and Plan are presets of one engine kind — identical behaviour, separate reporting. Each balances on its own; none copies the actuals.
Scenario dimension →PH-1
Status — how settled
Provisional while a number is still moving, Final once finalized — one way, never an edit. A budget figure carries a status exactly as an actual does, which is why the two axes stay separate.
Provisional → Final →PH-1
Book — under which basis
Group IFRS, local GAAP, tax, management. One entry per valuation basis, linked, each balanced in its own book — not one set of numbers with a reporting toggle on top.
Multi-book & consolidation →And on any forward period, how much is already decided: committed positions — contracted revenue, prepaid amortisation, depreciation, lease expense — are recorded from the owning subledger and reported as a band of every forward read. The ledger records those schedules; it never computes them.
And four ways to reach it
- REST, GraphQL, CLI and MCP — one provenance envelope across all four, plus streaming ingress and signed webhook egress. GraphQL is a read surface at PH-1; write parity is Roadmap. Interfaces →
- Signed outbound events — every committed mutation publishable, at-least-once, with replay from a sequence watermark and a queryable delivery log. Integrations & ingestion →
- Access is your IdP’s, enforced row by row — OIDC federation plus row-level predicates applied identically on every surface, including exports, lineage and webhook deliveries. Security →
And the rest of what holds
The guarantees that do not fit a headline but decide whether the numbers survive an audit.
Provisional numbers cannot leak
Provisional data cannot reach an external channel without an approved disclosure gate and a data-quality envelope travelling with it.
PH-1 · Provisional → Final
Intercompany is explicit
Paired entries, one per ledger, linked — never an invisible transfer. Eliminations are typed posted entries, never report-time netting, and the mismatch report names both sides.
PH-1 · Multi-entity & consolidation
FX is a posted entry, not a multiplier
An append-only rate registry, the applied rate locked on the posting, and HQ translation through explicit entries you can point an auditor at.
PH-1 · Ledger semantics
Hold funds without posting
Reserves are a distinct, rebuildable projection — reserve, release, capture — each carrying owner, purpose and expiry, and none of them touching the books until they should.
PH-1 · Ledger semantics
The core stays domain-independent
Industry modules and compliance packs plug in through versioned, signed, air-gap-installable contracts. The contract ships with a reference module; the pack ecosystem, the IFRS baseline pack and the signed registry are Roadmap.
Contract PH-1 · Compliance layer
Design targets, stated as targets
Balance reads p99 ≤ 250 ms, trial balance ≤ 2 s, a balanced journal post ≤ 300 ms. Storage measured at ~245.6 bytes per posting row — about 2.7 TB per ledger-year at one scenario and one book. Design targets, not benchmarks.
PH-1 targets · Reference-profile targets
Read the ledger the way your agents will
MCP is a first-class surface with the same semantics and error taxonomy as HTTP — and it works air-gapped with your own local model. Balances come back with their chain position attached.
# JSON-RPC 2.0 tool call — effective time and knowledge time on every read
→ tools/call get_balance
{
"ledger": "grp-eu",
"book": "group_ifrs",
"scenario": "actual",
"account": "1000",
"as_of": "2026-08-31", # effective time
"as_believed": "2026-09-19T09:41:07Z" # knowledge time
}
← 200 { "balance_minor": 18425000, "currency": "EUR",
"status": "final", "ledger_seq": 841223 }Pick your entry point
Six ways into the same ledger. Each one starts from the job, not the feature list.
Embed a real ledger — per tenant, without becoming an accounting company
Invariants below you: double-entry, immutability and governance as an API and an MCP server. Per-tenant isolation, validate-before-commit, and test-class credentials that can never write to production.
Per-tenant isolation FR-126 · validate-before-commit FR-116 · test credentials FR-807 · PH-1
Platform builders →Zero-day truth without weakening the audit trail
Provisional numbers today, provable numbers forever. One verifiable book of record across the estate, with as-of answers, typed corrections and a data-quality envelope on every disclosure.
Provisional bridge FR-230/232 · data-quality envelope FR-230 · PH-1
Finance teams →Your agents propose. Your policy approves. The chain proves it.
Read and propose against one ledger with scenario and status filters; never posting rights, always attribution. Proposals run the materiality gate server-side, and every call appends a provenance event.
Proposal-only credentials FR-220 · hash-bound approvals FR-215 · PH-1; full MCP tool surface Roadmap
AI-agent platforms →Budget, forecast and plan on the same ledger as actuals
Give your planning module one real ledger: scenario-tagged postings and as-of reads across actual, budget, forecast, plan and simulation — each carrying its own status, none of them copied. No ETL, no drift. Delta storage, switchover and roll-forward arrive in PH-2.
Scenario registry FR-301/304 · filters FR-342 · no-copy planning reads and writes FR-341 · computed variance FR-330 — PH-1; delta inheritance FR-310–317, switchover FR-318–320, roll-forward/override/promote FR-331–334 Roadmap
Planning vendors →Two more families to walk:
Comparisons, on the record
Verifiable facts only. Every table is dated, every claim links its source, and “where they win” is mandatory — because an honest table is the only one worth citing.
| Comparison | Axis | Status | Page |
|---|---|---|---|
| Ledgerbook vs Formance | Hash-chained bi-temporal log, MIT-licensed open-source core, self-host proportions | 2026-09-19 | Compare → |
| Ledgerbook vs Blnk | OSS Go fintech ledger; chain off by default, balances mutate in place | 2026-09-19 | Compare → |
| Ledgerbook vs Campfire | AI-native ERP that owns its ledger; inbound-only MCP, cloud-only | 2026-09-22 | Compare → |
| Build vs buy | What the free option costs when audit evidence is the requirement | in preparation | — |
What Ledgerbook is not
- Not an ERP, and not a replacement for one — it is the ledger beneath them (NG-2).
- No UI, no close workflows, no AP/AR: your application renders it; the ledger proves it (NG-1).
- No money movement — payment systems are ingestion sources (NG-3).
- No model in the core; agents reach it over MCP (NG-4). Fiat ISO-4217 money only (FR-107).
Get early access
The design-partner programme is open. Named partners only — we publish no placeholder logos.
Design-partner programme open — consented names appear here at launch. Pre-launch, this wall stays empty by policy: no invented logos, no implied endorsements.