Platform · PG-02
The accounting data layer beneath every system you run
One immutable book of record for every source system: double-entry semantics that hold under consolidation, as-of reads on three axes of time, chain-hashed history — served over REST, GraphQL (read), CLI and MCP, with streaming ingress and webhook egress.
- chain-hashed by default
- posted FX, not multipliers
- linked multi-book entries
- typed corrections only
An accounting data layer is the substrate beneath accounting applications: it ingests financial data from source systems, standardises it into a typed double-entry model — accounts, dimensions, scenarios, books — enforces the invariants that make the numbers arithmetic instead of assertion, and serves as-of reads to humans and machines. Ledgerbook AI is a headless, MCP-native accounting data layer, not an application: one immutable, vendor-neutral book of record that applications render and auditors can verify, correctable only through typed, attributable entries. It deploys in your own infrastructure — cloud, single-tenant VM or air-gapped — and the core stays domain-independent, with modules and compliance packs plugging in through versioned contracts.
Verified 2026-09-19 · source: product documentation §1.1–1.3
Phase legend: PH-1 shipped now · Roadmap arrives with PH-2. Labels are always present — colour is never the only signal.
Reference-profile design targets
p99 ≤ 250 ms
balance reads at the reference load profile · design target · NFR-3 (the 300 ms budget is NFR-2's journal post, not a read)
0 floats
integer minor units, per-currency partitions, no implicit netting · FR-107/112/130
3 axes
as-of reads: effective, insertion (recorded) and knowledge (belief) time, on every read · FR-500–504
OCEL 2.1
audit-export format, schema-validated in CI · FR-905
Throughput is quoted per ledger configuration — the scenario and book multiplier applies, and these are design targets rather than field measurements (NFR-1/2).
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, and the chain is on by default. Corrections are typed reversing, adjusting or restating entries — never edits. Every read answers as-of: the balance at a date, and the balance as we believed at a past instant.
FR-118/119/120/214 · FR-205/123–125 · FR-500–504 · PH-1
Immutability & verification →PH-1 · T0/T1
Writes you can govern
Agents can propose but cannot approve, finalize or correct — enforced at the credential, not the prompt. Approvals are content-hash-bound and any edit voids a pending approval, and materiality tiers T0/T1 are evaluated server-side.
FR-220/219/215 · FR-217/218 · PH-1; T2/T3 tiers Roadmap
MCP server & governance →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 — MCP included, with your own local model.
NFR-6/8 · FR-121 · PH-1; embedded class, multi-region residency Roadmap
Self-hosted & air-gap →One entry, three axes — never a side table
Every posting carries Status, Scenario and Book as first-class columns of the model. Dimensions ride as data on the posting, so the chart of accounts and the reporting axes stop being an afterthought.
Status — Provisional → Final
One object per entry for its whole life. Revisions append; finalization is one-way; after it, changes are typed corrections linked to the original — the original is never overwritten and the entry id never changes.
FR-200/201/205/207/211 · PH-1
Scenario — Actual, Plan, Forecast, Simulation
One mandatory scenario tag per posting, exactly one undeletable Actual per tenant, and per-scenario double-entry: a scenario can never silently contaminate Actual balances.
FR-301/302/304/335 · PH-1; delta inheritance and cross-scenario ops Roadmap
Book — the valuation basis
Group IFRS, local GAAP, tax and management are books within one ledger, not separate systems. The model axis is native: one entry per book as linked per-book entries that balance independently and never silently net.
FR-114/126/308 · PH-1
Postings and dimensions are data, not schema changes. Money arithmetic is defined on the posting — the atomic single-sided line — and dimensions are customer-definable tagging axes carried on those postings, so the data model is yours to shape without a migration. Dimensionality is not unbounded: each tenant sets caps on declared dimensions, values per dimension and postings per entry, with warnings before the cap and a typed error at it — index cost is governed, not hoped for.
FR-104/113; PD §1.7 (Entry, Posting, Dimension) · PH-1
Exact money, invariants that hold
This is a ledger of record first: the arithmetic is enumerated, the partitions are explicit, and there is no hidden netting anywhere in the path.
What the ledger enforces
- Every entry balances: debits equal credits within one book, always · FR-115
- Money is exact: integer minor units, no floats anywhere, fiat ISO-4217 only · FR-107/112
- Per-currency partitions: balances never mix currencies, and nothing is netted implicitly · FR-130
- Balances are derived and rebuildable from the log, snapshot-watermarked — overdraft is policy, never a hidden invariant · FR-135–139
- Accounts and dimensions are deactivated, never deleted · FR-100–105
Not multipliers, not netting
- FX conversion is a posted journal entry, not a multiplier: the rate comes from an append-only rate registry, and the applied rate is locked on the posting · FR-131/132/133
- HQ translation runs through explicit entries, so group numbers carry the same evidence as local ones · FR-134
- Reserves and holds are a distinct, rebuildable projection — you can hold funds without posting entries: reserve → release → capture, with owner, purpose and expiry · FR-148
- Corrections are typed: reversal, adjustment or restatement — never an edit · FR-205/123–125
This is the ledger API for accounting, qualified on purpose: not a crypto wallet surface, not a payments rail. Money movement is out of scope by design — payment systems are ingestion sources (NG-3).
Compliance does not live in these semantics either: IFRS and jurisdictional rules arrive as contract-bound packs — sandboxed, effective-dated and air-gap-installable — under the pluggable compliance layer. The rule contract ships now; the packs themselves are on the roadmap.
Multi-entity by construction: the consolidation triangle
Intercompany, eliminations and translation are ledger semantics here — not report-time adjustments made once a quarter, out of sight.
| Move | Ledgerbook representation | What you get back |
|---|---|---|
| Intercompany transfer | Explicit paired entries — one per ledger, linked, never an invisible transfer | A mismatch report that names both legs when the pair does not agree |
| Elimination | A typed posted entry in a consolidation scope | Never report-time netting: the elimination is visible, dated and reversible by reversal |
| FX conversion | A posted journal with the applied rate locked at posting, from the append-only rate registry | Rate provenance per posting, not a multiplier buried in a formula |
| HQ translation | Explicit translation entries, generated from the effective-dated rate registry by policy rather than by hand | Group numbers in the HQ (presentation) currency that carry the same evidence as local ones — never a display-time conversion |
| Parallel valuation | Linked per-book entries — group IFRS, local GAAP, tax — each independently balanced | Books that never silently net against each other |
Traces: FR-128/145 (intercompany, eliminations) · FR-131–134 (FX journals, rate lock, HQ translation) · FR-114/126/308 (multi-book) · PH-1.
Interfaces: how a headless ledger differs from a traditional accounting API
A traditional accounting API fronts an application's screens. These four surfaces — REST, GraphQL (read in PH-1; write parity is on the roadmap), CLI and MCP — are the product, together with streaming ingress and webhook egress: governed write paths with validation before commit, and reads that answer as-of.
| Surface | What it is for | Phase |
|---|---|---|
| REST | Validate, draft, approve and read; idempotency keys on every write path | PH-1 |
| MCP | The same semantics and error taxonomy as HTTP, for agents — read and propose | PH-1 read/propose |
| CLI | Operator tasks and CI: verify a chain, smoke an install, replay an export | PH-1 |
| Streaming & batch | Bulk ingestion and change feeds hitting the same governed core as interactive writes | PH-1 |
| Webhook subscriptions | HMAC-signed deliveries with retry, replay and a delivery log ordered by seq |
PH-1 delivery contract |
| GraphQL read models | Read-side composition for dashboards and planning views (v1) | PH-1 v1 |
Delivery contract FR-535–538/533 · API-webhooks. Advanced
event families — the belief.delta digest and monitor.breached — Roadmap, with their PH-2
features. The full MCP tool surface is likewise Roadmap: at PH-1 the surface is read and propose.
Dry-run the full validator — balance, currency, account state, dimensions, equation and policy — and get structured, machine-readable errors without writing anything.
FR-116/149 · PH-1
Draft-first: create, revise and submit a Provisional entry. Direct posting is refused when policy requires draft approval — the gate lives server-side, not in the client.
FR-201/206 · PH-1
As-of and as-believed balances by ledger, book, scenario and account — returned with the chain position of the events that produced them.
Propose an entry over MCP. Proposals run the materiality gate; agents hold no posting rights of their own, and every call appends a provenance event.
Ingest anything; every load leaves a receipt
Source systems stay where they are. Ingestion standardises them into the one model: a mapping registry for every source, a suspense queue for what cannot yet be mapped, reconciliation receipts per load, and money-bearing idempotency keys that never expire.
FR-140–147 · PH-1; batch and streaming paths hit the same governed core (FR-146)
Under your ERP, not another ERP
The estate consolidates into the ledger — legacy ERPs, banks, billing, spreadsheets, agent pipelines — and nothing is ripped out. The core stays domain-independent: industry modules and compliance packs plug in through versioned contracts, signed and air-gap-installable, so jurisdiction depth is added without forking the core.
NG-2 · FR-910 contract surface (interface only) · PH-1; FR-900–904 packs and signed registry Roadmap
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).
- Not a planning UX — grids, formula engines and modelling stay with your FP&A tool; scenario is an axis on the ledger they read and write (NG-6).
- We record committed schedules; we never compute them — contract revenue, prepaid amortisation, depreciation and lease expense are the owning subledger's arithmetic, recorded here as committed positions bound to their obligation (NG-1, FR-240/FR-241).
Platform FAQ
What is a headless accounting system?
A headless accounting system runs a double-entry ledger as a service with no user interface of its own: every capability is reached through APIs, a CLI, streaming and protocol surfaces, while screens and workflow software belong to applications built on top. Approval semantics — states, guards, materiality tiers and approval events — stay in the ledger; approval screens do not. Ledgerbook AI is headless by design — a ledger primitive, not an ERP — with REST, GraphQL (read), CLI and MCP as its surfaces, plus streaming ingress and webhook egress.
Verified 2026-09-19
What is an accounting data layer?
An accounting data layer is the substrate beneath accounting applications: it ingests financial data from source systems, standardises it into a typed double-entry model — accounts, dimensions, scenarios, books — enforces invariants such as debits equalling credits, and serves as-of queries to humans and machines. Ledgerbook AI is a headless, self-hostable accounting data layer: it holds the entries applications read; it does not replace the applications. Canonical definition →
Verified 2026-09-19
What is an enterprise accounting data layer?
An enterprise accounting data layer is the same substrate under group scale: one book of record across legal entities and legacy estates, with intercompany paired entries, typed eliminations, posted FX and parallel valuation books — plus row-level access control and audit exports an external reviewer can verify. Ledgerbook AI is built for that scale headlessly, and deploys inside your infrastructure, including air-gapped environments.
Verified 2026-09-19
Start from the model, not the screens
The design-partner programme is open. Bring the invariants your product depends on — we will walk the ledger semantics with you.