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 time` Organization → 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). [How the data layer works →](/platform) ## Builder FAQ 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. 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. 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.