Variance Analysis: Explaining the Number, Not Finding It

The report says materials were 14% over budget. Everybody in the room can see that. The column next to it says timing. Nobody knows whether that is true, nobody can check it before the meeting ends, and the number appears again next month.

Identification is the cheap half

Any system can subtract budget from actual and colour the result red. That part has been automated for thirty years and it is not where the value sits.

A decision needs more. Was the cost per unit higher, or did you use more units? Did the mix shift toward a lower-margin product? Will it recur? Each answer points at a different person and a different action, and a single percentage points at nobody.

This is why the monthly review so often ends with an agreement to look into it. Nobody in the room has the evidence, and assembling it takes a day that nobody has between month-ends.

Split it before you explain it

Management accounting has a standard answer to this and smaller businesses skip it: break one variance into its components, because each component has a different owner.

Component	What it means	Who can act
Price	You paid more per unit than planned	Purchasing
Volume	You used more units than planned	Operations
Mix	You sold a different blend of products	Sales
Timing	It lands in a different period	Nobody, if it genuinely reverses
One-off	A specific event you can name	Whoever approved it

Timing deserves suspicion every time it appears. A real timing variance reverses, and you can say in which period and for how much. If nobody can name the reversal, the word is a label on an unexplained number, and the same label will appear next month.

One-off deserves the same test. A cost described as exceptional that has appeared in four of the last six months is not exceptional, it is a budget that is wrong.

What AI can assemble

The reason explanations do not get written is extraction. Finding the transactions behind a line, grouping them, checking them against prior periods and the original assumption is hours of work per variance, and there are thirty variances.

That is the part to automate. Pull the underlying transactions, compute the price and volume split where the data supports it, show whether the same line moved in previous months, and surface the largest individual contributors rather than the percentage.

Asking for the biggest contributors instead of the total is the change that turns a variance pack into something actionable. A 14% overspend that turns out to be one invoice is a conversation about one invoice, not a review of a cost category, which is the same principle as finding the real bottleneck rather than optimising the average.

A drafted narrative is useful too, as a starting point a controller edits. It will be wrong in places and it will be written, which beats an accurate explanation that never got typed.

Where it will mislead you

Causation is the line. A model can tell you that a cost rose in the same month that a supplier changed, a volume spike happened and two staff left. It cannot tell you which of those caused it, and it will write a fluent sentence selecting one.

Treat every generated explanation as a hypothesis to put to somebody who was there. A plausible wrong cause is more damaging than an honest unknown, because it closes the question and sends somebody to fix the wrong thing.

The data quality caveat applies with force here. Variance analysis sits on top of your coding discipline, and if costs are posted to inconsistent accounts the split will be confidently wrong, which is the dependency described in data cleansing.

There is also a quieter failure worth watching for. If one of your source systems stops feeding the report, the variance it would have produced simply does not appear, and the pack looks clean. Ask what the figure was built from and which sources answered, which is the habit described in a vendor publishing its own list of ways its numbers go wrong.

A smaller pack, properly explained

Set a threshold and explain only what crosses it. Five variances with a named cause, a named owner and a stated expectation for next month beats forty lines with a colour code.

Then check last month's explanations against what happened. A business that does this for two quarters finds out which of its stated causes were real, and the quality of the explanations improves faster than any reporting tool would improve them. It also feeds directly into understanding where margin actually goes.

Frequently Asked Questions

What is variance analysis?

Comparing what actually happened against what you expected, and explaining the difference. The comparison is arithmetic and takes seconds. The explanation is the part that makes it useful, and it is the part that often arrives as a one-line comment reading timing.

Why do so many variance reports go unused?

Because they stop at identification. A report telling you that materials cost was 14% over budget has told you something you could see from the numbers. What a decision needs is whether that was price, quantity, mix or a one-off, and whether it will repeat next month. Without that, the meeting turns into people guessing out loud.

What does it mean to split a variance?

Separating one difference into the things that caused it. A cost overrun can come from paying more per unit, using more units than planned, a different mix of products, or timing. Those have different owners and different fixes, so a single percentage hides the decision. Splitting it is standard practice in management accounting and is skipped constantly in smaller businesses.

Is timing a real explanation?

Sometimes, and it is also the most overused word in management reporting. A genuine timing variance reverses in a later period, and you can say which period and by how much. If nobody can name the reversal, timing is a label on an unexplained number rather than an explanation of it.

Where does AI genuinely help?

Assembling the evidence. Pulling the transactions behind a variance, splitting it into price and volume components, checking whether the same line moved in prior periods, and drafting a first-pass narrative that a controller then corrects. It compresses the hours of extraction that stop the explanation from being written at all.

What should it not be trusted with?

Causation. A model can tell you that a cost rose at the same time as a supplier changed and a volume spike occurred. It cannot tell you which one caused it, and it will produce a confident sentence either way. Treat any generated explanation as a hypothesis to check against someone who was there, because a plausible wrong cause is worse than an admitted unknown.