The model and the reporting disagree
One was built from assumptions and the other comes from the systems, so every variance meeting turns into a reconciliation exercise.
Financial modelling
Forecasts you can defend
Driver-based models built on the same definitions as your reporting, so the forecast and the actuals stop disagreeing.
The plan usually lives in a spreadsheet built from assumptions while the actuals come out of the systems, which turns every variance discussion into a reconciliation. We build the model on the same definitions as the reporting, document the calculation, and separate inputs from logic so that somebody other than the author can open it, challenge it and stress it.
Discuss this buildWhen this comes up
What this usually looks like from the inside.
The forecast says where, not what to change
A number lands on the page without the operating drivers underneath it, so nobody can see which lever moves it.
Only one person can open it
The logic is undocumented and fragile, which means it cannot be challenged, stress-tested or handed to anybody else.
The work
The work, step by step.
Scope varies with the state of your systems. These are the parts that recur.
Driver structure
Revenue, cost, working capital and operating assumptions connected to the measures already defined in your reporting.
The model build
A documented, auditable model with the calculation visible and the inputs kept separate from the logic.
Scenario and sensitivity
The what-if cases a lender or board will press on, built in rather than bolted on afterwards.
What you leave with
Everything you keep.
You own all of it: the code, the written definitions and documentation aimed at whoever maintains this after us.
- A driver-based operating model
- Documented calculation logic with inputs separated
- A scenario and sensitivity set
- Board and lender reporting generated from the model
How this runs
Scope, timescale and what happens afterwards.
Roughly the first week
We establish which commercial question is worth answering here, and what your data, systems and people can realistically support.
The bulk of the engagement
We build it, rather than specifying it for somebody else to build. Reconciled continuously against numbers your team already accepts.
The final fortnight
Documentation, definitions and a runbook, plus a walkthrough where your team drives and we watch.
Only if you ask
Ongoing technical support is quoted separately from the build, so declining it costs you nothing.
Worth asking
Questions this tends to answer.
- Do the plan and the actuals use the same definitions?
- Which drivers does the forecast actually turn on?
- When would we know the downside case was happening?
- Can anyone but the author open this?