FP&A · PG-26
FP&A on one ledger: plan against numbers you can verify
Actuals, plans and simulations through the scenario axis — with maturity disclosed on every read, and variance that drills to the posting that explains it.
- no ETL, no extracts
- maturity on every read
- variance to the posting
- scenario-native consumption
- air-gap installable
An FP&A data layer should answer one question before it answers any other: how final is this number? In Ledgerbook AI, actuals, plans and simulations live on the same ledger through the scenario axis, and every composed or variance read discloses maturity — the final amount, the provisional amount, the provisional share and the oldest open item per returned slice, at any dimension grouping. Variance is computed, never stored, and drills to the entry or posting that explains it, with provisional rows either included and labelled or excluded and disclosed. No extracts, no copied actuals, no three-day-old totals: EPM tools consume one contract over REST and MCP. Maturity reads, the quality-gated boundary and drill-through ship at PH-1; the forecast-ready gate, driver postings and allocation runs are Roadmap (PH-2).
Verified 2026-09-19 · source: FP&A consumption contract FR-350–357, scenario registry FR-301/304/335
Phase legend: PH-1 shipped now · Roadmap arrives with PH-2. Labels are always present — colour is never the only signal.
FP&A consumption primitives
per slice
maturity on every composed and variance read: final, provisional, share, oldest open · FR-350
4
drill-through levels: aggregate → account → entry → posting · FR-352
E, K
reads resolve effective time and knowledge time, and echo the belief instant used · FR-500–504
0
copies of your actuals — reads hit the ledger, not an extract · FR-341
Quality-gated reads: every number says how final it is
FP&A does not need more data; it needs to know how much of the data is finished. Every composed balance and every variance response carries a maturity object per returned slice — at any dimension grouping, not only at total level — computed from the contributing postings' statuses.
| Field | What it tells you |
|---|---|
final_amount |
The part of the slice that is Final — sealed, immutable, correction-only |
provisional_amount |
The part still Provisional, and therefore still able to move |
provisional_pct |
The provisional share of the slice — “92% final, here is what is open” |
oldest_provisional_days |
Age of the oldest open item behind the number |
as_of_knowledge echo |
The belief instant the read resolved at, so a forecast can cite its basis |
Inherited rows are reported separately
A composed read never hides borrowed provisional weight: the rows it inherited from another scenario are disclosed on their own, so nobody discovers the soft part after the board pack ships.
FR-350 · PH-1
The boundary follows the numbers
Boundary modes last_final and last_closed resolve from ledger state — and when
resolution lands earlier than the last booked period, the blocking provisions or open reconciliations are
echoed with it.
FR-351 · PH-1
Forecasts are only as good as the numbers they stand on — maturity travels with every read instead of living in a side spreadsheet · FR-350 · PH-1
Plan vs actual, explainable to the posting
Variance on one ledger means the difference between two scenario slices of the same books — computed from the composed rows, never stored, so the number a forecast explains is the number the ledger holds. Two things are worth separating: **drill-through** from a difference to the contributing accounts, entries and postings is an interactive read, while the **composed variance read itself is report-class, not interactive** — it is served from scenario-scoped materialised balances or a columnar tier, and we do not present it as a sub-second query. The plan vs actual API is one read contract, served over REST and MCP with no extract in between. The registry, full-mode planned and simulated scenarios, per-scenario double-entry, computed variance and no-copy planning reads and writes are live at PH-1; delta inheritance, switchover and the roll-forward, override and promote operations arrive with PH-2.
| Detail level | What the response enumerates |
|---|---|
aggregate |
One difference per requested slice — the headline the report needs |
account |
The accounts contributing to that difference, ranked by size |
entry |
The contributing entries, with ids, amounts, statuses and scenario provenance |
posting |
Individual postings — where the difference was actually born |
Filter by maturity — and see what you excluded
final_only excludes provisional contributions and labels exactly what it excluded; all
keeps them in with status attached. A forecast can therefore state its basis instead of asserting one.
FR-352 · PH-1
Decompose without a second system
group_by=<dimension> walks the same variance across cost centres, products or any dimension
the postings carry — the same read, a different axis, no extract in between.
FR-335/342/352 · PH-1
Delta inheritance over the Actual base, promote and cross-scenario operations: Roadmap — planned for PH-2 alongside the scenario deltas. FR-310–334
Why actuals arrive days late — it is the extract, not the analysis
The pattern is familiar to every planning team: a 6–12-week integration project, actuals landing three days late, totals-only extracts that cannot be explained back to a posting, and a close run in one tool while the forecast is built in another.
The cost is the disagreement
Two copies of the same month that no longer agree — and a variance meeting that starts with reconciling the inputs instead of explaining the business. Totals-only extracts remove the detail you need to defend the number.
Context: FP&A ledger-consumption research
Remove the extract, remove the drift
Postings arrive scenario-tagged, reads answer as-of, and maturity travels with the numbers — so plan, forecast and actual are three filters on one ledger rather than three pipelines that must be kept in step.
FR-341/342/350 · PH-1
Planning grids stay yours
Ledgerbook is not a planning tool: formula engines, model logic and workflows stay third-party. EPM vendors are partners, not competitors — the ledger is the substrate their integrations read.
NG-6 · For planning vendors →
The forecast-ready gate — and the operations around it Roadmap
Until these ship, maturity reads already disclose the same quality signals on the numbers themselves — the gate formalises them into a contract a pipeline can enforce. Every item below is Roadmap (PH-2).
- Forecast-ready gate. Period readiness returns the period state (open, soft-closed,
hard-closed), the final and provisional shares, the oldest open item and the boundary candidates; reads can
require a forecast-ready period and fail closed with a typed
FORECAST_NOT_READYnaming the unsatisfied conditions. Roadmap FR-355 - Driver and statistical postings. Quantity reads grouped by driver, unit, dimension, period and scenario — with unit-aware variance and the implied rate where a monetary posting shares a driver reference. Roadmap FR-353
- Allocation runs as recorded operations. A rule registry — pool, basis, receivers, offset policy, method, run mode — emitting balanced postings into the target scenario, each carrying its operation id and the driver postings used. Roadmap FR-354
- Planning-consumer conformance pack. A CI profile partners run against the ledger contract — budget-vs-actual and forecast consumption tests, so an integration is proven before a close depends on it. Roadmap FR-357
Traces: FR-353–355/357 · PH-2 per the product phase plan · boundary modes last_final/last_closed are live at PH-1 (FR-351)
Frequently asked
How do FP&A tools get actuals from a ledger?
Through the scenario axis, with quality attached. FP&A tools read actuals over REST or MCP using scenario and status filters, and every composed read returns a maturity object — final amount, provisional amount, provisional percentage and the oldest open item per slice — so a forecast can state how final its inputs are. No extracts, no copies, no three-day-old totals. The maturity object →
What does maturity mean on a financial read?
Maturity is the ledger's disclosure of how final a number is. Every composed or variance read carries final and provisional amounts, the provisional share, and the oldest provisional days per returned slice — computed from the contributing postings' statuses at any dimension grouping. It separates 'the number is X' from 'X is 92% final, and here is what is still open'.
How do you know a period is ready to forecast on?
The forecast-ready gate is a Roadmap feature (PH-2). When it ships, a read can require a forecast-ready period, and period readiness — open, soft-closed or hard-closed, plus provisional share and oldest provisional days — fails closed with an error naming the unsatisfied conditions. Until then, maturity reads already disclose the same quality signals on the numbers themselves. The readiness contract →
When is a period forecast-ready?
A period is forecast-ready when it is closed (or soft-closed with declared posture) and its reconciliation status is at or above the boundary you set. Planning reads may pin boundary=last_final so plans only consume fully reconciled final actuals.
Read what is already determined, instead of assuming it
A planning tool fed by a trial-balance export has to model a whole future month as an assumption, including the parts that are already known. Ledgerbook reports a committed band on every forward read: the share of the period carried by schedules that already exist — contracted revenue, prepaid amortisation, depreciation, lease expense — recorded as entries bound to the obligation behind each one, and drillable to it.
Three bands, one object. Maturity already tells you the final and provisional amounts, the provisional share, the age of the oldest open item and whether the contributing accounts reconcile. Committed joins it as another band on the same response, at any dimension grouping — so the question "how much of Q4 is real?" is one read, not a reconciliation project.
No estimate lives in this band. Committed contains no forecast and no model output. If a number is in it, an obligation determines it and the drill-through resolves to that contract, bill, asset or lease. Anything genuinely uncertain stays out, which is what makes the band worth quoting to a board.
The schedules are recorded, not computed. Your subledgers do the arithmetic; the ledger holds the result and relates it to its source. That boundary is deliberate — it is why the committed view is available to whatever tool you already plan in, rather than only to the system that generated the schedule.
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 Ledgerbook is not
The contract on this page works precisely because of what sits outside it.
- Not a planning UX (NG-6). Planning grids, formula engines and multi-year modelling stay with the tool your team already uses. This page describes what that tool reads: one ledger, with maturity disclosed on every number.
- No forecasting models (NG-4). We do not produce your forecast. We make the numbers under it checkable — final versus provisional share, how old the oldest provisional entry is, whether the underlying accounts reconcile.
- We record committed schedules; we never compute them (NG-1). Contract revenue, prepaid amortisation, depreciation and lease expense are computed by the subledgers that own them and recorded here as committed positions bound to their obligation — so the part of next month that is already determined can be read rather than assumed.
Plan on the ledger your actuals live on
One contract for actuals, scenarios and maturity — consumed by your stack, governed by the same gates as every other read and write.