How to explain why revenue changed (before someone asks)

"Why did revenue change?" is the most common question in any monthly review, and the one most often answered badly. The fix is a habit: decompose the change into drivers before the meeting, so the explanation is on the page when the number goes up on the screen.

This post walks through that habit with one example, from a $1.42M month to a $1.31M month, and covers the mistakes I see most often when people try it for the first time.

Start with the identity, not the chart

Before any chart, write down what revenue is made of. For a business with repeat customers, a useful version is:

This is an identity. Multiply the three together and you get revenue, exactly. That property is what makes the decomposition work. If your inputs don't multiply back to your revenue figure, stop and fix the definitions first, because every number after this depends on it.

Here are two months for a fictional subscription box company:

Revenue fell $109,000. The table already hints at the answer, but only if you squint, and the person asking the question will not squint.

Check the calendar before anything else

August has 31 days. September has 30. For any business that sells every day, that alone is worth about 3% of revenue.

$1,420,000 × 30 ÷ 31 = $1,374,194. So roughly $46,000 of the $109,000 drop is the calendar, before any customer did anything different.

I put this check first because it is embarrassing to skip. I have watched a team spend half an hour debating a February dip that was three missing days. If day count matters in your business, show revenue per day alongside the total, or call out the calendar effect as its own bar.

In this example the company bills per order rather than per day, and orders per customer held at 2.5, so the calendar mostly shows up through fewer active customers. Keep it in mind anyway. When someone asks "is this a real drop?", you want the answer ready.

Decompose the change into drivers

Now attribute the $109,000 to the three inputs. Change one at a time, in order, holding the others where they were:

1. Active customers. From 8,000 to 7,600, at August's 2.5 orders and $71 AOV: −400 × 2.5 × $71 = −$71,000.
2. Orders per customer. Unchanged at 2.5, so $0.
3. Average order value. From $71 to $69, at September's 7,600 customers and 2.5 orders: 7,600 × 2.5 × −$2 = −$38,000.

Total: −$71,000 + $0 − $38,000 = −$109,000. Every dollar is accounted for.

The explanation is now one sentence: we lost 400 active customers, and those who stayed spent $2 less per order; order frequency did not change. That last clause matters. Saying what didn't move is half the explanation, because it closes off a line of questioning before it starts.

Then find where it happened

Drivers tell you why in arithmetic terms. Segments tell you where. Do drivers first, then segment the driver that moved.

Here is the same revenue split by region:

North accounts for 69% of the drop. The next question writes itself: did North lose customers, or did North's customers spend less? Run the same three-driver decomposition on North alone and you have the answer at the level someone can act on.

This order (drivers first, segments second) stops you from presenting a region table that explains nothing. "North was down" is a location, not a reason.

When the drivers add rather than multiply

Not every business has a clean multiplicative identity. Sometimes the natural split is additive: revenue from new customers plus revenue from returning customers, or one revenue line per product.

Additive breakdowns are easier, because each part's change is simply its own difference. Here is the same company split that way:

This tells a slightly different story from the driver view, and both are true. Returning customers account for most of the drop, which fits with losing 400 active customers. The two views complement each other: the driver split says how revenue fell, and the additive split says which group of customers it fell in.

Use whichever split your audience already thinks in. A sales team thinks in new and returning. A finance team often thinks in volume and price. Showing someone the split they already recognise saves explaining the method.

The mistakes that derail the meeting

Adding percentages that don't add

"Customers fell 5% and AOV fell 2.8%, so revenue fell 7.8%." Close, but wrong, and someone with a calculator will notice. Percentage changes in a product compound rather than add. Present dollar effects, which do add, and keep percentages for context.

A big "other" bar

If your bridge has a residual larger than the smallest named driver, your definitions overlap or leave a gap. Common culprits: refunds counted in one source and not another, or currency conversion at different rates. Find it before the meeting rather than during.

The wrong baseline

Month on month is noisy for seasonal businesses. A retailer comparing December to November learns nothing useful. Compare to the same month last year, or to budget, and say which one you chose. If you're comparing to budget, the method is slightly different: see variance analysis without the jargon, which splits a budget gap into price, volume and mix.

Only showing the biggest mover

Leading with the largest driver is right. Hiding the others is not. If AOV fell $38,000 and nobody mentions it because customers were the headline, someone will find it next month and wonder why it wasn't raised.

Explaining with a chart that has no numbers on it

A line chart of revenue going down just restates the question. Put the driver values on the page.

Writing the explanation down

Once the decomposition is done, write it as three short lines, in this order:

1. What happened. Revenue fell $109K to $1.31M.
2. Why, in drivers. 400 fewer active customers (−$71K) and $2 lower AOV (−$38K). Order frequency held.
3. Where, and what's next. Two thirds of the drop was North. We're checking whether the North price test drove the churn, and will report back next week.

That is the whole slide. No adjectives. If someone asks a follow-up, you have the table behind it.

I wrote more about structuring the meeting itself in data storytelling for people who hate the phrase.

Keeping it ready for next month

The painful part of this method isn't the arithmetic. It is rebuilding it every month, from fresh exports, the night before the review.

Two things help, with or without new tools. Keep the identity in one place, as named cells or a small metric tree, so the decomposition formulas don't change month to month. And keep last month's values as a snapshot rather than overwriting them, so "change since last month" is always one subtraction away.

This is the workflow FlowProofs is built around: the three drivers on a canvas, a snapshot at month end, and a why panel that runs the one-at-a-time attribution for any number you click. The founders page shows the same idea applied to MRR, where new, expansion and churn replace customers and AOV.

Wherever you build it, do the decomposition before the meeting. Write the identity for your revenue today, check it multiplies back, and you'll have the first bar of next month's bridge already done.