Forecast — planning and projections
Planning as derivation, not data entry — projections built from your governed actuals and your business context, where every line carries the assumption that produced it and nothing is ever overwritten.
Derived from your actuals and your context · every line carries its basis
Planning is not a data-entry exercise
A spreadsheet gives you an empty grid; a planning cube gives you a tidier empty grid. Either way someone types numbers into cells and the reasoning stays in their head. Six months on, the number survives and the thinking behind it does not.
A projection here is derived — from your own history and what the platform already knows about you — and the reasoning is written down as the number is created.
How a plan gets built
Six steps, in this order, because each one depends on the last. The exhibit alongside is the same sequence.
- Start from governed actuals and your context. Not a blank grid, and not last year plus a percentage. Your reconciled history, plus the targets, policies and definitions the platform has held since onboarding. Both have to be there — a projection derived from disputed history inherits the dispute.
- Identify the drivers. What actually moves the numbers: volume, price, mix, headcount, capacity.
- Map the relationships. Which driver feeds which account, so a change propagates instead of being retyped.
- State the initiatives and assumptions. Discrete, dated and owned — a hire plan, a price rise, a new site.
- Build the projection line by line. Account by account, entity by entity, month by month, each line storing its reasoning in words beside the amount. We call that the basis.
- Approve it. The projection is signed off and becomes the plan. The baseline locks, and variance has something to measure against.
From history to plan — and back.
Governed actuals
Your own history, already reconciled — not a blank grid.
Your context layer
The targets, policies and definitions the platform already holds.
Drivers
What actually moves the numbers — volume, price, mix, headcount, capacity.
Relationships
How each driver connects to the accounts it feeds.
Initiatives and assumptions
Discrete, dated and owned — a hire plan, a price rise, a new site.
Granular projections
Account by account, entity by entity, month by month — each line with its basis.
Testing
One assumption at a time, one initiative on or off, scenarios derived from a baseline.
Approval
The projection is signed off and becomes the plan. The baseline locks.
Actuals arrive, and the variance attributes back to the assumption that was wrong — so the next cycle starts better informed than the last.
The sequence is the method. Testing is the capability a granular, assumption-linked model is built for — and what we are building towards.
What that structure buys
- Forecast is the only surface that writes. Ask, Report and Monitor read the governed model; Forecast writes into it under the same governance. So plan-versus-actual is a query, not a monthly rebuild.
- Variance goes to the assumption. When a number misses you can see which assumption was wrong, because it is attached to the line.
- Nothing is overwritten. Revising a line writes a new version, attributed to an authenticated identity. What a line said in July is still there in March.
Every line carries its assumption.
Revenue — retail
600100 2027-01 1,240,000Volume +6% on the FY26 exit run-rate; price held to April, +3% thereafter.
Payroll — production
521000 2027-04 −312,400Headcount 42 → 45 from Q2 at €45k; pay review +4% lands in April.
Marketing
518300 2027-01 −64,000Held flat until the rebrand ships; revisited at half-year.
Other overheads
518850 2027-08 −16,072Other overheads +4%, excluding depreciation, memo and disposal accounts; spread evenly.
Demo Company — plan lines as written to the governed layer. Each keyed by scenario, entity, account and period; the basis is stored with the number, not beside it.
Testing the plan
Because every line is linked to the assumption that produced it rather than buried in a cell formula, the model can be interrogated — one variable at a time, with everything else holding still.
That is the part a spreadsheet and a data cube cannot reach. Not for want of ambition: neither of them knows which assumption produced which number, so neither can tell you what moving it would do.
Sensitivity
Move one assumption. Everything else holds, so the effect is attributable.
What-if
Switch a single initiative on or off — the second site, the hire plan — and read the year without it.
Scenarios
Derive a downside from the base by changing only what differs. No second plan to maintain.
One plan, wherever you need it
The plan is written once, into the governed layer. Everything downstream reads it from there rather than receiving a copy.
In Power BI, plan against actual is an ordinary report that refreshes with everything else — no month-end rebuild, and no argument about which version of the budget is current.
As a workbook, it is the file auditors and boards ask for, reconciling line for line to what the system holds. Because the honest answer to “can we have it in Excel?” is yes.
What nobody should have to accept is a file that is the only copy — or two copies that have to be reconciled to each other.
What a governed forecast buys you.
Four outcomes, one mechanism: the assumption travels with the number.
Defensible six months later
Every number keeps the assumption that produced it. Nobody reconstructs the logic from a spreadsheet nobody remembers building.
Plan and actual in one model
Same accounts, same entities, same periods. Plan-versus-actual becomes a query, not a monthly rebuild.
Nothing is lost
Every revision is kept and attributed. What you assumed in July, and who changed it, is still there in March.
A file your auditor can sign
The plan lives in the governed layer and reconciles line for line to a formatted workbook.
Explore the platform
Put your data to work — in weeks, not months.
We connect your systems, build the governed model, and hand you reports ready to use. A proven process across 50+ mid-market finance teams.