Use cases · PG-08
Who builds on a headless ledger
Six kinds of teams build on Ledgerbook AI. Platform builders embed a ledger per tenant — double-entry, immutable, MCP-native — without becoming an accounting company. Finance teams put one provable book of record under a fragmented ERP estate. Close teams tie billing, terminals, channels and the bank into one verified number with the evidence path to defend it. FP&A leaders plan against numbers they can verify. AI-agent platforms get a governed write path: agents propose, policy approves, the chain proves it. Planning vendors consume actuals and scenarios from the same ledger their customers plan on. It is a data layer, not an application: no UI, no workflows, no money movement, no models in the core — payment ledgers and app vendors are ingestion sources here, not rivals.
Verified 2026-09-19 · Five buyer segments, one ledger
Six ways in
One ledger, one set of guarantees — a different job on top of each.
PH-1
Platform builders
Embed a real ledger — double-entry, immutable, MCP-native — per tenant, without becoming an accounting company. Structural isolation, validate-before-commit, test-class credentials, and a connector contract for every load.
Embedded ledger for platform builders →PH-1
Finance teams
One provable number — and the evidence to defend it. Near-real-time truth with a data-quality envelope, typed corrections, as-of answers, multi-entity consolidation, and a deployment that can stay inside your infrastructure.
Ledger of record for finance teams →PH-1 · T0/T1
AI-agent platforms
Your agents propose. Your policy approves. The chain proves it. Scoped non-approving credentials, content-hash-bound approvals that void on edit, and one provenance event per commit — the governed substrate under AI accountants.
Ledger for AI-agent platforms →Roadmap
Planning vendors
Plan on the same ledger as actuals. No ETL, no drift. The scenario registry, filters and writability matrix are consumable today; delta inheritance, composition modes and variance runs arrive with PH-2.
Planning data contract for EPM vendors →PH-1
Reconciliation close teams
Billing, terminals, channels and bank tie into one verified number on one traversable evidence path: exception queues with owners and aging, and adjustment proposals that post only when a human approves.
Reconciliation for finance teams →PH-1 · reads
FP&A leaders
Plan against numbers you can verify: maturity-gated actuals, variance that drills to the posting, and one contract your EPM stack consumes without ETL. The readiness gate and driver postings arrive with PH-2. Roadmap
FP&A for planning leaders →What every segment gets
Different entry points, the same four guarantees — traced, not asserted.
One record you can prove
Every Final entry is chain-hashed and the chain is on by default. Corrections are typed reversing, adjusting or restating entries — never edits — and every read answers as-of.
FR-118/119/205 · PH-1
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.
FR-220/215/216 · PH-1 (T0/T1); T2/T3 Roadmap
Evidence a third party can check
Verify the chain online or offline, and export the full lifecycle as OCEL 2.1 that an independent verifier — or an auditor without ledger access — can load and reproduce.
FR-121/905 · PH-1
A ledger you can own
Self-hosted and air-gapped is a first-class deployment: one process on a VM or a bare-metal HA cluster, an offline bundle with zero egress, and no vendor endpoint in the path.
NFR-6 · PH-1
Self-select by need
Four needs, six segments. Every cell names the primitive that answers it.
| Need | Platform builders | Finance teams | AI-agent platforms | Planning vendors | Reconciliation close teams | FP&A leaders |
|---|---|---|---|---|---|---|
| Embed a ledger | Core job — one ledger per tenant, own chain per ledger FR-126 | Multiple ledgers per group; a legal-entity registry with multi-country consolidation, intercompany eliminations and HQ-currency translation FR-126/128/131–134 (data residency pinning: Roadmap) | One ledger per client portfolio FR-126 | One ledger per customer estate, scenario-tagged FR-301 | One ledger per group; source sides stay in place FR-152 | One ledger per estate, scenario-tagged FR-301 |
| Governed agent writes | Scoped agent credentials, test class FR-807 | T0/T1 gates now; T2/T3 Roadmap FR-217 | Core job — propose → approve → post FR-220 | Server-side writability matrix FR-344 | Reconciler MCP tools read and propose only FR-343 | Reads over REST/MCP — same gates FR-217 |
| Audit evidence | Chain checks runnable in CI FR-121 | As-of reads + OCEL 2.1 export FR-905 | Engagement review from the event log FR-905 | Planned-number provenance FR-345 | Assertion-edge evidence paths FR-153 | Maturity on every read FR-350 |
| Scenarios & planning | Scenario-tagged postings FR-302 | Actual + registry; consolidation FR-304 | Scenario filters on every read FR-342 | No-copy consumption, read and write PH-1 FR-341 | Scope (scenario, book) on every run FR-150 |
Variance drill-through FR-352 |
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).
Pick an entry point
Tell us the job — we will point you at the segment page and the primitives behind it. Named design partners only; no placeholder logos here.