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 ◐ 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 ✓ 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 ## 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](/compliance). 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) [Ingestion & integrations →](/integrations) ## 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). [Read the quickstart →](/developers) ## Platform FAQ 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 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 →](/glossary#accounting-data-layer) Verified 2026-09-19 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.