How to build a budget vs actual report people read

A budget vs actual report has one job: show where the business is off plan, by how much, and why. Most of them do the first part well and skip the other two, which is why they get skimmed in the meeting and questioned by email afterwards.

This post covers a layout that people read, the rules for which variances deserve attention, and how to annotate them so the report answers its own questions. The example is a quarter's operating expenses, but the same structure works for revenue.

The layout

Here is the core table. One row per line item, in the same order as your chart of accounts so people can find things:

Six columns, and every one earns its place:

• Budget and Actual next to each other, budget first, because people read left to right and the budget is the reference point.
• Variance in dollars, because that is what changes cash.
• Variance in percent, because $12K means something different on a $60K line than on a $640K line.
• Flag, so the eye goes to the three lines that need discussion and skips the two that don't.

Things to leave out of the main view: last year's actuals, the full-year budget and a reforecast column. All useful, all available on a second tab. On the first view, they turn a readable table into a wall.

Sign conventions that don't need explaining

This is where most budget vs actual reports confuse people. For revenue, actual above budget is good. For costs, it is bad. A positive number in the variance column means opposite things depending on the row.

Two ways to handle it, pick one and keep it:

Option 1: label favourable and unfavourable. Add an F or U next to each variance. Payroll +$45,000 U. Travel −$12,000 F. Nobody has to think about signs.

Option 2: flip cost variances. Calculate cost variance as budget minus actual, so a positive number is always good news. This is tidy, but it confuses anyone who expects "actual minus budget", so state it in a footnote.

I prefer option 1 for reports that go to non-finance readers. Colour can help too, but never rely on colour alone, since a printed or forwarded copy may lose it.

Which variances to flag

Not every variance deserves a conversation. A $300 overspend on stationery is a 15% variance and nobody cares.

Use two thresholds together: a variance is flagged only if it passes both a dollar threshold and a percentage threshold. For this example, $10,000 and 5%.

• Payroll: $45,000 and 7.0%. Both pass. Flagged.
• Software: $18,000 and 20.0%. Both pass. Flagged.
• Travel: $12,000 and 20.0%. Both pass. Flagged, even though it is favourable.

The double threshold filters out big percentages on tiny lines and small percentages on huge lines. Set the numbers to fit your business. A company with $50M of opex might use $100,000 and 3%.

In Excel or Google Sheets, with variance in column D and variance percent in column E:

=IF(AND(ABS(D2)>=10000, ABS(E2)>=0.05), "Review", "")

Flag favourable variances too. An underspend can mean a hire that slipped, a campaign that didn't launch, or a vendor that hasn't invoiced yet. Each of those is worth knowing before it shows up as an overspend next quarter.

Annotate every flagged line

This is the part that turns a table into a report. For each flagged line, write one line, in plain words, with the number in it:

• Payroll +$45K: two engineering hires brought forward from Q4 (+$38K), plus support overtime during the September launch (+$7K).
• Software +$18K: annual analytics licence renewed at the new price tier, not in the budget.
• Travel −$12K: the customer visits planned for August moved into October. Expect the spend next quarter.

Notice the pattern: the variance, the cause, and where possible the split into drivers. "Payroll is over due to hiring" is a guess at what happened. "+$38K from two hires brought forward" is something a manager can verify and act on.

Also notice that the travel note tells the reader what happens next. A timing difference is not a saving, and saying so now prevents a surprise later.

Show the bridge

For the total, add a bridge chart that walks from budget to actual through the flagged lines:

Budget $1.20M, payroll +$45K, software +$18K, travel −$12K, actual $1.25M. The three bars explain all $51K of the variance, and the chart shows it in a few seconds. If your bridge needs an "other" bar bigger than the smallest named one, set the thresholds lower or split a line further.

For a revenue variance, the bridge splits into price, volume and mix rather than cost lines. That method has its own post: variance analysis without the jargon.

Month, year to date, or both

Monthly variances are noisy. Invoices land a week early or late, and a line can swing from over to under budget and back. Year to date is steadier but hides a recent change inside months of history.

My default: show the month in the main table, and add a YTD variance column on the second tab. When a line is flagged for the month but fine YTD, it is probably timing, and the annotation should say so.

The reforecast question

At some point in the year, the original budget stops being a useful reference. If you hired ahead of plan in March, payroll will be "over budget" every month until December, and the flag will stop meaning anything.

That is the moment to add a reforecast: a revised expectation for the rest of the year. Report against the reforecast for operational decisions, and keep budget for the board's view of how the year compares to the original plan. Label clearly which one you're using. Mixing them in one table is a reliable way to start an argument.

Making it readable

A few last habits that make the difference between a report that gets read and one that gets skimmed:

• Lead with the summary. One sentence above the table: "Opex $51K (4.3%) over budget, driven by payroll timing and an unbudgeted software renewal; travel under budget on timing."
• Same layout every month. Readers learn where to look, so don't move things.
• Round in the narrative, exact in the table. "$45K" in the text, "$45,000" in the cells.
• Put the source and date at the bottom. "General ledger export, closed 3 October."

The broader principles behind this are in data storytelling for people who hate the phrase, and the reasons Excel versions of this report tend to rot over time are in why Excel dashboards break.

A checklist before you send it

Run through this every month. It takes five minutes and catches most of the mistakes that end up in a reply-all thread:

1. The totals tie out. Total actual matches the ledger for the period, to the dollar.
2. The period is right. Month-end close date on the report, and no late journals posted after you exported.
3. Every flagged line has a note. No exceptions, including favourable ones.
4. Every note has a number. "Timing" alone is not an explanation. "Timing: $12K of August visits moved to October" is.
5. Signs are consistent. Every variance labelled F or U, or the convention stated at the bottom.
6. Unflagged lines are really fine. Scan for a line just under both thresholds two months running. That is a trend, and worth one sentence.

Then send it with the summary sentence in the body of the email, so the people who never open attachments still get the answer.

Keeping it live

Everything above works in a spreadsheet, and for many finance teams the spreadsheet is the right place for it. The ongoing cost is rebuilding it every month from new exports, and answering follow-ups like "can you show that for the London office only?" with another round of filtering and pasting.

FlowProofs is built for that second part. You upload the ledger export and the budget, write the variance and flag formulas once, and draw the bridge from them. When someone asks about one office, you filter the canvas and every line recalculates. It is not FP&A software, though. If you need consolidation across entities or approval workflows, use a dedicated planning tool. The finance teams page shows where it fits.

Start with the double threshold. Apply it to last month's report, count the flagged lines, and write one annotation for each. If the report can then answer its own first question, people will read it.