How to write variance commentary managers actually read

“Cloud hosting expenses were $60K higher than budget (-30%).” That sentence is in every variance pack I’ve ever inherited, and it tells the manager nothing they couldn’t read off the table themselves. The number is already in the report. Your job in the commentary is to answer the two questions the number provokes: why did it happen, and what should we do about it.

Good commentary does five things. It checks the baseline is worth narrating, comments only on what’s material, decomposes the number into causes, classifies each cause so the reader knows if it reverses, and ends with a so-what and an owner. Skip any one of those and you’re back to restating the table.

Check the baseline before you narrate it

Decide what you’re measuring against before you write a word. A static budget is your original plan at planned volume. A flexible budget recalculates that plan at the volume you actually hit. The difference matters because a static-budget variance can tell the wrong story when volume moves.

Say revenue came in $200K “ahead” of a static budget but you sold 25% more units than planned. On a volume-adjusted basis you might actually be behind on price. Narrate the static number and you’ll write a story that’s literally backwards. Whether your house reports against static or flexible is a finance-policy call, so settle it with your FP&A lead rather than assuming. But know which one you’re holding before you explain it.

Comment only on what clears the threshold

Management by exception is the whole game. Set a materiality rule, say variances over $25K and over 10%, and let everything below it pass without a word. (Those figures are illustrative; agree the real ones with your controller.)

A $60K, 30% overage on cloud hosting earns full commentary. A $3K, 2% wobble on office supplies the same month gets nothing. Comment on everything and you bury the two lines that matter under twelve that don’t, and leadership stops reading by line three.

Decompose the number before you describe it

This is where most commentary skips a step. Before you assign a cause, split the variance into components that sum back to the total. For our $60K overage:

• About $35K is volume. Two enterprise customers went live a month ahead of plan, adding usage. This is matched by revenue, so gross margin is intact. Good cost.
• About $10K is price. The cloud vendor’s contracted rate rose 8% at renewal on the 1st. This recurs every month for the rest of the year.
• About $15K is a one-off data-migration project that consumed compute and won’t repeat.

$35K plus $10K plus $15K equals the $60K. Now the cause is grounded in arithmetic, not a guess from the account name. Note the conventions: there are several valid ways to split price, volume, and mix, especially the joint term, so use whatever formula your function has standardized.

A category like “volume variance” is not an explanation. It’s a bucket. You still have to name which customers, which vendor, and why.

Classify each piece so the reader knows what happens next

Decomposition tells you the size. Classification tells the reader the future. For each component, mark it on three axes: timing versus permanent, one-off versus structural, controllable versus uncontrollable.

The $35K volume piece is real and ongoing, but supported by revenue. The $10K rate rise is permanent and recurring, so it belongs in the reforecast. The $15K migration is a one-off that drops out next month. That classification is the difference between “we’re $60K over” and “$10K of this is the new run-rate and the rest is explained.”

Write to a repeatable sentence shape

Once you’ve decomposed and classified, the prose almost writes itself: direction and size, because specific driver, which is classification; so-what and owner. Here’s the cloud hosting line built that way:

Cloud hosting was $60K (30%) over budget. About $35K reflects two enterprise customers going live a month ahead of plan, which is volume-driven and matched by the associated revenue, so gross margin holds. A further $10K is the 8% vendor renewal rate increase effective this month; this is permanent, and we’re baking +$10K/month into the reforecast (roughly $90K full-year), owned by Infra. The remaining ~$15K was a one-off data migration that doesn’t recur, so underlying run-rate is ~$245K. Action: Infra to renegotiate committed-use discounts at the next review to offset the rate rise.

A manager can decide from that without a single follow-up email. The favorable-versus-unfavorable convention and whether you show variances as actual-minus-budget or the reverse differ by company, so state yours once at the top of the pack.

What the formula can’t do for you

Decomposition is math. Root cause is not. The arithmetic tells you $35K came from higher volume; only someone who knows the period can tell you it was those two enterprise customers and that they went live early on purpose. That context lives with the cost-center owner, not in the ledger, and no formula will manufacture it.

This is also why an AI first draft needs a human on cause attribution before it ships. A model will happily read “cloud hosting up $60K” and invent a plausible reason from the account name. Plausible and true are different things, and your credibility rides on the gap. Let the tool draft the structure; you own the why.

And don’t wave a favorable variance through just because it’s favorable. An underspend on hiring or deferred maintenance reads as good this month and bills you later. Classify it the same way you’d classify an overspend.

Check the work

Run one test before it ships: delete every sentence that only repeats a figure already in the table. If a line survives that cut, it’s carrying a cause, a classification, or an action. If half your commentary disappears, you were writing captions, not analysis.

The bar is simple. A manager should be able to read your comment and act, without asking you a single question back.