Skip to content
Get access

Use cases · FP&A · PG-28

Budget and forecast against numbers you can verify — maturity-gated actuals, variance you can explain

For FP&A leaders who judge an EPM stack by the quality of its inputs: every read says how final the number is, and every variance walks back to the postings.

Talk to us about planning The FP&A consumption contract
  • final vs provisional, visible
  • variance to the posting
  • one contract, no ETL
  • EPM-friendly by design
  • air-gap installable

What FP&A leaders get here

The contract behind the confidence — the mechanics live on the FP&A feature page; this is what it changes in your operating rhythm.

PH-1

Budget vs actual without extracts

The actual side of every comparison is read from the ledger — scenario-tagged, as-of, and never a copy that can drift from the books. No ETL job sits between the close and the variance pack.

FR-341/342 · PH-1

PH-1

Forecast inputs with final-vs-provisional visible

Every read states its maturity — final amount, provisional amount, share and oldest open item — so a forecast can declare how much of its foundation is still soft instead of discovering it at reforecast.

FR-350 · PH-1

PH-1

Explain variance to the posting

Drill from the aggregate difference to the account, the entry and the individual posting — filtered by maturity — so the story you tell is the one the ledger can prove.

FR-352 · PH-1

PH-1

One contract for the EPM stack

Your planning tools consume one governed read contract over REST and MCP — the same semantics, scopes and error taxonomy as every other surface.

FR-342/343 · PH-1

Partners, not competitors

Planning grids, formula engines and model logic belong to your EPM stack — we do not compete for that surface. Ledgerbook supplies the substrate: scenario-tagged postings, as-of reads and maturity, consumed through one contract instead of a nightly rebuild.

What the ledger does

Holds the actuals, plans and simulations in one double-entry core with the scenario axis; serves composed reads and variance; discloses maturity; records who read and wrote what.

FR-301/304/341/350 · PH-1

What your stack keeps

Grids, drivers, allocation intent, dashboards and workflows. Driver postings, allocation runs and the forecast-ready gate are ledger operations on the roadmap — the app still owns the decisions.

FR-353–355 Roadmap · NG-6

Why it matters to input quality

The failure mode FP&A leaders know is late, totals-only actuals that cannot be explained. Scenario-tagged, detail-preserving reads remove the failure at the source — before the 6–12-week integration project, not after it.

Context: FP&A ledger-consumption research

The planning-vendor data contract

Links up and sideways

The proof strip holds until real numbers exist: pre-launch, this page publishes no benchmark figures — the inspectable proof is the contract and the phase labels. No unsourced numbers

The part of next month you should not be forecasting

Ask a planning team what share of next month is already contracted and most cannot answer without rebuilding a schedule by hand, because the tool only ever received a trial balance. Ledgerbook reports it directly: committed positions — contracted revenue, prepaid amortisation, depreciation, lease expense — are recorded in the ledger and returned as a band on every forward read, each drillable to the obligation behind it.

It changes what the model is for. The determined part of a period stops being an assumption you carry and becomes an input you read, so modelling effort goes where the genuine uncertainty is — pipeline, usage, hiring — instead of being spread evenly across things that are and are not already decided.

Your tool keeps its job. The grid, the formulas and the drivers stay yours. What changes is the source: one ledger carrying plan and actual on the same axis, with maturity and the committed share disclosed on every number, rather than an export that was stale when it landed.

The schedules are the subledger's arithmetic. Ledgerbook records them and relates each position to its contract, bill, asset or lease; it does not compute them and runs no business calendars. That is precisely why the committed view is readable by the planning tool you already use.

Committed positions and the obligation registry: FR-240/FR-241 · the committed band on maturity: FR-350 — PH-1. The forecast-ready gate (FR-355) is Roadmap.

What one number can be

Every posting answers three questions at once — and keeps them separate.

One posting, three tags A single ledger posting of 48,200.00 shown once, carrying three independent tags: a Scenario tag (Budget), a Status tag (Provisional) and a Book tag (Group IFRS). Below it, the values each axis can take: Scenario is Actual, Budget, Forecast, Plan, Simulation or a custom variant; Status is Provisional or Final; Book is any valuation basis such as Group IFRS, local GAAP or tax. ONE POSTING 48,200.00 4100 · Revenue · EU-West Budget Provisional Group IFRS SCENARIO STATUS BOOK Illustrative values. Nothing is copied between axes — this is one row.
  • Scenario — which reality this number describes: Actual, Budget, Forecast, Plan, Simulation, or a custom variant you name. Budget, Forecast and Plan are presets of one engine kind, so they behave identically and report separately.
  • Status — how settled it is: Provisional while it is still moving, Final once finalized, one way only.
  • Book — under which valuation basis: group IFRS, local GAAP, tax, management.

All three are answered by the same row, on the same double-entry core, balanced within each scenario. That is why a budget figure can be provisional, and why plan versus actual is one question you can ask of this model rather than the shape of the model itself.

What Ledgerbook is not

Each boundary below names something your planning stack keeps.

  • Not a planning UX (NG-6). Your planning tool keeps its grid, its formulas and its drivers. What changes is where it reads from: one ledger carrying plan and actual on the same axis, instead of an export that was stale when it landed.
  • No forecasting models (NG-4). We do not forecast for you. We disclose how much of each number is final, how much is provisional, how old the oldest provisional entry is, and whether the accounts behind it reconcile.
  • We record committed schedules; we never compute them (NG-1). Contract revenue, prepaid amortisation, depreciation and lease expense are the owning subledger's arithmetic. The ledger records them as committed positions bound to the obligation, so the already-determined part of a future month stops being an assumption in your model.

Where the boundary is

  • Not a planning tool: no planning grid, no model editor, no budget workflow (NG-6).
  • Not an ERP, and not a replacement for one — the ledger beneath your estate (NG-2).
  • No UI of ours to learn — your EPM stack renders it; the ledger proves it (NG-1).
  • No model in the posting path — agents read and propose over MCP; policy approves (NG-4).

Make actuals a contract, not a pipeline

Tell us which EPM surfaces you run and what wastes the first three days of your month — that is the evaluation we run with design partners.

Talk to us See the FP&A model