Use cases · Platform builders · PG-09
Embed a ledger per tenant without becoming an accounting company
Double-entry, immutable, MCP-native: invariants below you as an API and an MCP server. You own the UX; the ledger proves itself.
- per-tenant isolation
- validate before commit
- test-class credentials
- verify in CI
The model you embed is the isolation model
A ledger is the isolation unit — its own chain, chart of accounts namespace, dimension registry and posting policy — and the boundary is structural: no query returns data across tenants.
# one hierarchy, enforced by the engine
Organization
├─ ledger: cust-0042 # isolation unit — own chain, COA, registry, policy
│ ├─ book: group_ifrs # valuation basis
│ ├─ book: local_gaap
│ └─ scenario: actual # exactly one per tenant; undeletable
└─ ledger: cust-0043
# a posting policy scoped to a ledger is enforced at write timeOrganization → Ledger → Book is structural; no query returns data across tenants · a ledger's posting policy is enforced at write time · FR-126/127, FR-114/304 · PH-1
Isolation you can promise a regulated customer
Tenant isolation is structural and the ledger is the enforcement unit, not a label. A single-tenant isolation profile — one tenant per deployment, no shared runtime state — is supported alongside the multi-tenant topology.
FR-126/127 · NFR-6 · PH-1
Multiple ledgers, multi-country groups — and where residency stops
A tenant registers its legal entities, and every ledger belongs to exactly one of them — so one organisation holds many ledgers: per customer, per region, per legal entity. Cross-ledger moves are explicit paired entries — never an invisible transfer — intercompany eliminations post as typed entries rather than report-time netting, and HQ-currency consolidation runs through translation entries posted by the engine. What stops at the roadmap is *residency*: pinning a deployment to a region so data never leaves it is a PH-2 capability, and multi-country consolidation does not depend on it.
FR-126/127/128/131–134 · PH-1 · residency (NFR-8) Roadmap
Nothing is written before it validates
Runs the full validator — balance, currency, account existence and state, dimensions, equation, policy — and returns structured, machine-readable errors without writing anything.
Previews the invariants a proposed entry would fire and the policy outcomes it would receive — evaluated tier, required approvers. Provably side-effect-free: no sequences, no events, no movement.
Draft-first: create, revise and submit a Provisional entry. Direct posting is refused when policy requires approval — the gate lives server-side, not in your client.
Dry-run and preview are available on REST and MCP at parity (FR-116/149, FR-343); PH-1 read/propose — the full MCP tool surface is Roadmap (PH-2)
Proof you can run before you trust us
Everything on this list is executable in a builder's week one — not a slide.
Test-class credentials
Bootstrap agent and builder credentials programmatically with no browser round-trip: scoped to a (ledger, audience) target, expiring, audited at issuance — and a test class that can never write to a production ledger.
FR-807 · PH-1
Chain checks in CI
The verify operation recomputes the chain and returns PASS or the first divergent entry with its location and expected/actual hash — runnable via API and CLI, and against a signed export in an air-gapped environment.
FR-121 · PH-1
One surface, published
REST, CLI, streaming and MCP share one semantics and one error taxonomy; packages ship with the developer preview and the docs link every artefact that exists — no phantom installs.
DP-2 · FR-146 · PH-1 (docs with the developer preview)
Ingestion: standardize before it posts, receipt after it lands
Your customers' data arrives messy. The ledger takes it through three registry-backed stages — and leaves evidence at every step.
Mapping registry
Connector mapping profiles are versioned registry data, never code: source system → account, dimension and currency mapping, transforms, unmapped-field policy, version stamps and the idempotency-key scope.
FR-147 · PH-1
Reconciliation receipts
Every ingest load emits a receipt comparing source control totals against posted volumes per (scenario, book), with 1:1 / 1:N / N:1 match counts and the exceptions that need a human.
FR-147 · PH-1
Suspense queue
Unmapped or unreconciled items land in a queryable queue — reported, never silently dropped and never auto-posted. The queue is data your support team can work, not a log file.
FR-147 · PH-1
The connector contract. Connectors are built on this contract, not inside the core. An adapter declares its source system and version, registers one or more versioned mapping profiles with an explicit unmapped-field policy, emits a per-row source hash plus actor hints for dual attribution, honours the batch and stream contracts including the batch idempotency key — and transforms payload shapes only, never semantics.
Ingestion-adapter contract per FR-147; streaming runs the same validator, invariants, idempotency and chain-hashing as synchronous writes (FR-146) · PH-1
Retries are safe by construction: every write path takes an idempotency key, a batch key wins over delivery metadata on redelivery, and money-bearing keys never expire — a retried load can never double-post. Roadmap Named bank-format presets — OFX, ISO 20022 CAMT.053, SWIFT MT940, BAI2 — arrive with PH-2.
White-label everything — there is nothing of ours to white-label
The boundary is simple: your product is the product; the ledger is the record under it.
Ledgerbook ships no UI: no customer portal, no admin screens, no front end to re-skin. Every screen your customers ever see is yours, and your brand is the only brand in the flow. Workflows, onboarding, notifications and the application database stay in your stack; invariants, provenance and evidence stay in ours.
That is also why we are not your competitor: application vendors are our buyers, not our rivals. The embedded deployment class — single process, file-backed, no external services — is on the roadmap, scoped for exactly your use case.
No UI or user-facing workflows in the core (NG-1); application vendors as buyers, not rivals (PD §1.8); embedded deployment class Roadmap (NFR-6, PH-2)
- Yours: UX, branding, portals, workflows, pricing screens, onboarding.
- Ours: double-entry invariants, the lifecycle, chain-hashed history, provenance events, row-level access, the audit export.
- Shared, explicitly: the credential model — a test class that cannot touch production, scoped per tool and target, expiring and audited (FR-807).
- Never ours: payments and money movement — those are ingestion sources, not ledger features (NG-3).
Builder FAQ
Can we ship the ledger under our own brand?
Yes — and there is nothing of ours to white-label. Ledgerbook ships no UI: no portals, no admin screens, no customer-facing surface. Branding, onboarding and every workflow live in your product; the ledger supplies the invariants and the evidence behind them. In an air-gapped deployment it also runs without any vendor endpoint — no SaaS hop, no vendor inference call.
What happens when an ingest load fails halfway through?
Retries are safe by construction: every write path takes an idempotency key, bulk batches carry a batch key that wins over delivery metadata, and money-bearing keys never expire — so a replayed batch can never double-post. Rejected items are persisted with their reasons and unmapped rows land in the queryable suspense queue. Every load leaves a reconciliation receipt against source control totals.
How do we test without touching production?
Use test-class credentials — they can never write to a production ledger, and the attempt is rejected before state change and audited. Pair them with the validate and preview tools: both run the full validator and policy evaluation and are provably side-effect-free — no sequence consumption, no events, no aggregate movement.
What Ledgerbook is not
The boundaries below are the reason this is embeddable at all — see also the white-label section above.
- Not an ERP or system of entry (NG-2). Your product stays the place your customers work. The ledger sits behind it, per tenant, enforcing double-entry and immutability that your own schema would otherwise have to guarantee.
- No money movement (NG-3). Your processor keeps the money and the payout schedule. We account for both, and reconcile the ledger to what actually settled.
- No UI (NG-1). There is nothing of ours for your users to see, brand or work around — which is what makes the white-label claim on this page a statement of architecture rather than a licensing term.
Bring the invariants, keep the product
The builder preview opens to design partners first. Bring a tenant model and the job your product does; we will bring the ledger underneath it.