What a monthly budget vs. actuals review should actually look like.

The thing it's actually for

Budget vs. actuals compares what you planned to spend and earn against what really happened, line by line, and asks why they differ. That's it. The mechanics are simple. The value is entirely in the "why."

A 30% jump in software spend might be a billing error. It might be a duplicate subscription nobody cancelled. Or it might be a signal that the product team is throwing compute at a problem they need to fix. Those are three completely different responses, and you only get to pick one if you noticed in the first place.

Monthly, not quarterly

Founders push back on this and I push back harder. Starting with a monthly review gives you a better opportunity to fix problems before they become big problems. Quarterly means you find out about something three months after it started, and by then it's expensive and half the context is gone.

There's a second reason. A monthly cadence forces the books to close monthly, which forces the categorization to be right, which is what makes your burn number trustworthy. Companies that review quarterly usually also close quarterly, and their data is worse for it.

The meeting

Forty-five minutes, monthly, within about ten business days of month end. Whoever owns finance runs it. The founder or CEO is in the room. Anyone who owns a meaningful budget line is in the room too, because the person who can explain the variance is rarely the person in finance.

The materials go out before the meeting, not during it. Nobody should be reading a P&L for the first time while you're talking.

The agenda is short. Cash and runway as of today. Revenue against plan. Every expense variance over the threshold, with an explanation. Anything expected next month that isn't in the plan yet. Decisions and owners.

Set a variance threshold and hold it

Flag anything over 10% and over a dollar amount that's meaningful at your size. At Seed that might be $2,500. A line that's 40% over plan but only $300 is noise. A line that's 6% over plan but $80,000 is not.

Without a threshold you get a review that either flags everything, which nobody reads, or flags nothing, which defeats the point.

What good variance commentary sounds like

Bad commentary restates the number. "Software was $32,000 against a $24,000 budget, a $8,000 unfavorable variance." Everyone can see that on the page.

Good commentary tells you what happened, whether it repeats, and what to do. "Software was $8,000 over. Most of it is the new data warehouse contract, which is a permanent monthly increase we didn't put in the plan. About $1,200 is a duplicate seat licence I've cancelled. I'm raising the software line by $6,800 a month going forward, which takes about three weeks off runway."

That second version is a decision document. The first one is a spreadsheet with sentences on it.

Split the variance three ways

Every variance is one of three things and the response differs for each.

1. A timing difference. The invoice landed in a different month than planned. Real but self-correcting. Note it and move on.
2. A permanent change in the run rate. A new contract, a raise, a vendor price increase. Update the forecast the same day, because your runway just moved.
3. Something broken. A billing error, a duplicate charge, a process that stopped working. Assign an owner and a date.

Founders lose a lot of time arguing about variances that are just timing. Naming the category first makes the meeting shorter.

The whole company should understand the budget

This part gets skipped and it's the part that makes the rest stick. If the only person who understands the budget is the finance person, every variance conversation starts from zero and feels like an audit.

When the people who own the lines understand the plan, they flag things before you do. Your head of engineering tells you cloud spend is about to jump because of a migration, three weeks before it shows up in the actuals. Ownership of the numbers comes from understanding them.

Where AI helps and where it doesn't

The mechanical parts of this review automate well. Pulling the actuals, calculating variances, flagging anything over threshold, drafting the first version of the commentary. That work used to eat two days a month and now it takes an hour of review.

What doesn't automate is knowing that the $8,000 software variance is worth a conversation with your CTO and the $3,000 legal variance isn't. That judgment is the job. The automation just clears enough time to actually do it.

If you're starting from nothing

You need a budget before you can compare against one, and it doesn't have to be sophisticated. Twelve months, by month, by category, built on what you're actually spending now plus what you know is coming. Budget conservatively on revenue and generously on costs, because surprises tend to run in one direction.

Then run the review for three months before you judge it. The first one is a status report. By the third, the commentary starts telling you things you didn't know about your own company.