Skip to content
Get access

Use cases · Finance teams · PG-10

One provable number — and the evidence to defend it

Zero-day truth without weakening the audit trail: provisional numbers today, provable numbers forever.

  • chain-hashed by default
  • one-way finalization
  • typed corrections
  • as-of reads
  • air-gap installable

Proof primitives for finance teams

T0/T1

materiality tiers evaluated server-side; T2/T3 arrive with PH-2 (Roadmap) · FR-217

OCEL 2.1

audit-export format, schema-validated in CI · FR-905

E, K

two axes per read: the balance then, and what was believed then · FR-500–504

0

no edit path to a Final entry — corrections are new, typed entries · FR-205

Near-real-time truth without losing the audit

Provisional numbers are the point — as long as they can be told apart from final ones at every surface, by every consumer.

A data-quality envelope, not a disclaimer

Any response or artefact carrying provisional data ships with its (scenario, book) scope, a watermark, the provisional weight — amount, share of total, age of the oldest item — and a manifest hash covering the result set. Renderers must not strip it.

FR-230 · PH-1

A gate before anything leaves

Export to any external sink names its scope and needs the external-export permission; investor and filing exports additionally require actual-view and a soft-closed period, and combined data needs a named approver and reason code. Every export emits an event recording who exported what, and with what provisional weight.

FR-231 · PH-1

The bridge ties — zero tolerance

The identity actual + provisional + scheduled = combined holds at every aggregation granularity, exposed as a first-class report with per-entry drift. The CFO's "how much of today's number is soft" and the auditor's reconciliation get the same answer.

FR-232 · PH-1

Auditor identities never see provisional by default

Provisional visibility is a distinct grant from actual visibility, scoped by scenario and book, and granted only as explicit, time-boxed, evented scopes. Approved-but-not-final items ageing past the approval SLA raise an alarm.

FR-233 · PH-1

Evidence you can defend in a workpaper

The audit question is rarely "what is the number" — it is "what was the number, who changed it, and how do we know".

Every read answers as-of

The balance at a date, and the balance as we believed it at a past instant: three axes of time on every answer — effective, recorded and believed — so a restatement never erases what the board pack said at the time.

FR-500–504 · NFR-3 · PH-1

Corrections are typed, never edits

Reversing, adjusting or restating entries — linked to the original: IAS 10 / ASC 855 adjusting events post as an adjustment, IAS 8 / ASC 250 error corrections post as a restatement. The mistake and the fix both stay visible, and finalization itself is one-way.

FR-205/211/123–125 · PH-1

Export the lifecycle, not a screenshot

The event and object history exports as OCEL 2.1 — scope-filtered, reproducible, carrying who/when/where per event — and an auditor can load it without ledger access. Bundled multi-format exports and audit evidence packages are on the roadmap.

FR-905/529 · PH-1; evidence packages FR-907 Roadmap

Scoped access that expires by construction

Row-level access applies identically on every surface — a scoped principal sees the same rows in an export as in a direct query — and credentials for auditors are time-boxed and revocable, with each allow/deny recorded.

FR-803/233/807 · PH-1

See the provenance & export model

The first month is connectors and mapping — and every load leaves a receipt

Your integrator's reality, not a demo: legacy charts of accounts, source control totals, and an audit trail for the migration itself.

Mapping registry

Legacy COA → ledger dimensions, group-COA mapping for consolidation, currency mapping: versioned registry data, never code, with transforms and an unmapped-field policy per profile.

FR-147 · PH-1

Reconciliation receipts

Every load compares source control totals against posted volumes per (scenario, book), with 1:1 / 1:N / N:1 match counts — the artefact that closes out a migration review.

FR-147 · PH-1

Suspense queue

Unmapped or unreconciled rows are reported, never silently dropped and never auto-posted — an exception list a controller can work down, queryable like any other data.

FR-147 · PH-1

Batch keys win over delivery metadata on retry and money-bearing idempotency keys never expire — a replayed migration can never double-post (FR-140–142, FR-146) · PH-1

Multi-entity consolidation at the data layer

Consolidation is a posted, auditable process — not a report-time convention in a spreadsheet.

Every intercompany move is two balanced entries — one per ledger, linked, never an invisible transfer. When the legs disagree on amount, currency or date, the mismatch report names both sides. Currency conversion is posted, not multiplied: rate records are append-only, the rate applied is locked on the posting, and consolidation translates through explicit entries.

Verified 2026-09-19 · FR-128/131–134 · PH-1

Eliminations are entries, not netting

Intercompany eliminations are generated as typed, posted entries in a consolidation scope — visible and reversible only by compensating entries, never an invisible report-time netting. Cross-datastore pairs run as sagas; a stranded leg surfaces as a mismatch finding, never a silent asymmetry.

FR-128/145 · PH-1

Multi-book, never silently netted

Group IFRS, local GAAP and tax are linked per-book entries that balance independently within one ledger. Translation differences are posted; retroactive revaluation is itself a Final entry, never a recompute.

FR-114/126/134/133 · PH-1

Deploy where the data must live

For groups whose books cannot leave a jurisdiction, a VPC or a classified network.

One process on a VM or a bare-metal HA cluster; containers optional. An offline bundle installs and operates with zero egress — MCP and agent surfaces included, against your own local model. A single-tenant isolation profile — one tenant per deployment, no shared runtime state — is the structural answer regulated buyers ask for.

Attestation roadmap: SOC 2 Type II targeted inside PH-2, ISO 27001 on the same roadmap — we do not claim a certificate before it is issued.

NFR-6/8 · PH-1; multi-region residency and the embedded deployment class Roadmap (PH-2) · NFR-15 attestation roadmap

What Ledgerbook is not

Three boundaries worth knowing before you scope this, because each one names a tool you keep.

  • Not an ERP (NG-2). You are not migrating off your ERP to use this. The ledger sits underneath it — and underneath the subsidiary systems the group ERP never absorbed, which is usually where the reconciliation pain actually is.
  • No close-checklist screens (NG-1). Period states, close gates, finalization admission rules and the provisional→final bridge are ours, as data and events. The checklist your team works through is FloQast-class tooling or your own build, reading those states.
  • Not a planning UX (NG-6). Budgeting and forecasting stay in the tool your FP&A team already uses. What changes is that it reads plan and actual from one ledger, with maturity disclosed, instead of from an export.

Where the boundary is

  • Not an ERP, and not a replacement for one — the ledger beneath your estate (NG-2).
  • No AP/AR, no payments — source systems feed it (NG-3).
  • No model in the posting path — agents reach it over MCP (NG-4).
  • Fiat ISO-4217 money only, integer minor units, no floats (FR-107).

Other entry points →

Put one provable number in the next board pack

Tell us your entity structure and the audit question that keeps recurring — that is the evaluation we run with design partners.