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. ✓ 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. ✓ 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. ◇ 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. ✓ 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. ✓ 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 ## 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 | [Not sure? Start with the docs](/developers) ## 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.