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. - 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](/fp-and-a); 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](/use-cases/planning-vendors) ## Links up and sideways - [The FP&A feature page](/fp-and-a) - [All use cases](/use-cases) - [Plan vs actual in one ledger](/scenario-dimension#plan-vs-actual) - [Planning vendors](/use-cases/planning-vendors) - [Reconciliation: one verified number](/reconciliation) - [Talk to us about a design partnership](/contact) 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 ## 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). ## 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. **Figure — one posting, three tags.** A single posting of 48,200.00 (4100 · Revenue · EU-West) carries a Scenario tag (Budget), a Status tag (Provisional) and a Book tag (Group IFRS) at the same time: - **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. ## 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.