Skip to content

Finance & FP&A

Monthly variance analysis that a business partner will actually use

How to structure a budget-versus-actual review so it explains cause rather than restating numbers: materiality thresholds, driver decomposition, and the four questions every variance comment should answer.

9 min read · updated 10 September 2026

Variance analysis has a reputation for being the dullest task in finance, largely because it is often done as narration: "Travel is 18% over budget." The reader can see that in the column next to your comment. What they cannot see is why it happened, whether it repeats, and what decision it implies.

This is the structure I use for a monthly OpEx and CapEx review. It works with a spreadsheet and an ERP extract; the tooling matters far less than the sequence.

Start by fixing what you are comparing

Before any commentary, be explicit about the comparison basis. Budget versus actual, forecast versus actual and prior-year versus actual answer different questions and often disagree. A cost centre can be under budget and badly over last year's run rate at the same time.

Lock the version of the budget you are comparing to, note the date of the actuals extract, and state whether figures include accruals and internal recharges. Half of all disputed variance reviews are actually disputes about the baseline.

Filter by materiality before you write anything

A useful pack explains five to ten variances, not eighty. Apply a two-part threshold: an absolute value that matters to the business and a percentage that indicates something changed.

A common starting point is "greater than 5% and greater than a defined currency amount", tuned so the filter returns a readable number of lines. Everything below the line gets a single aggregate row. This is not hiding detail; it is directing attention.

Decompose into drivers, not accounts

An account code tells you where the money was posted. A driver tells you what caused it. For most cost lines, the variance breaks into three components: volume, rate and timing.

Volume is how much activity happened — headcount, shipments, tickets, machine hours. Rate is the unit cost — a contract renewal, an FX movement, a tariff change. Timing is a cost falling in a different period from the plan, which is not overspend at all and needs an explicit call on whether the annual number still holds.

Separating timing from real overspend is the single highest-value thing an analyst does in this process, because it changes the decision from "cut spend" to "nothing to do".

  • Volume × plan rate = the part explained by activity.
  • Actual volume × (actual rate − plan rate) = the part explained by price.
  • Anything left is timing, mix or a booking issue — chase it, don't average it.

Write comments that answer four questions

Every variance comment should answer: what happened, why, does it repeat, and what are we doing. Two sentences is usually enough.

Compare a weak comment — "Consulting spend above budget due to higher project activity" — with a usable one: "Consulting is 240k over for the quarter because the ERP migration testing phase moved from Q4 into Q3; full-year spend is unchanged and Q4 will be 240k under. No action required, phasing corrected in the forecast."

The second version ends the conversation. The first guarantees a meeting.

Close the loop into the forecast

Variance analysis that does not update the forecast is archaeology. Each explained variance should produce one of three outcomes: adjust the phasing, adjust the full-year number, or accept it as one-off with no change.

Record which outcome you chose and who agreed it. Next month, the first thing you check is whether the corrections you made held. That habit is what turns a reporting pack into a forecasting capability.

Make the process repeatable before you make it pretty

The reason month-end drags is rarely analysis; it is manual data assembly. Fix the extract and mapping layer first — a stable cost-centre-to-owner mapping, a consistent chart-of-accounts grouping, one refreshable query per source — and only then invest in the visual layer.

Once the data pipeline is reliable, the commentary is genuinely the analyst's job again, and the pack can move from days to hours.

  • One canonical mapping table, owned and version-dated.
  • Refreshable queries instead of pasted extracts.
  • A standing exception report for postings with no valid owner.
  • A short written definition of every KPI on the pack.

Frequently asked questions

What materiality threshold should I use?
There is no universal figure. Pick a percentage and an absolute amount that together surface roughly five to ten lines per review, then keep them stable so trends stay comparable.
How do I separate timing from genuine overspend?
Ask whether the full-year commitment changed. If the annual number is unchanged and only the month moved, it is phasing — correct the forecast rather than the budget conversation.
Should commentary be written by finance or by the budget owner?
Both. Finance supplies the decomposition and the draft explanation; the owner confirms cause and action. Comments written entirely by one side tend to be either unexplained or unchallenged.

Put it into practice

Budget-versus-actual dashboards, PR/PO tracking and reporting automation, built on illustrative demo data.

See the portfolio work behind this

Written by Syed Danish Arafat, a financial analyst working in FP&A, reporting and finance automation. Shared for educational purposes — review anything here against your own circumstances before acting on it.