--- title: "Decompose the variance before you narrate it" url: "https://obserbi.com/blog/decompose-variance-before-narrating" description: "Ask a model why revenue missed plan and you get a fluent story. Unless price, volume, mix and FX are separated first, that story is often wrong. How to fix the order." --- # Decompose the variance before you narrate it October 8, 2026·3 min read·Editorial team A row of polished brass calibration weights of decreasing size beside fine tweezers, a precision balance in a glass case behind The board pack is due on Thursday. Revenue came in below plan and the commentary needs a paragraph. A model is given the P&L lines, the plan and last year, and asked why. It writes a good paragraph: softer demand late in the month, partly offset by price increases, with a shift toward lower-margin products. It reads as if a controller wrote it. Nobody checks it against a decomposition, because it sounds like what everyone expected. Two weeks later someone runs the numbers properly. Volume was on plan. The miss was almost entirely currency: a large part of the export book is invoiced in euros, and the plan rate was set before the home currency strengthened. The paragraph was fluent, plausible and wrong — and it went to the board. ## The real cause: narration without arithmetic Language models are very good at producing the explanation a reader expects. From aggregated lines there is no way to know how much of a revenue variance is price, how much is volume, how much is mix and how much is exchange rate — that information is not in the aggregate. So the model fills the gap with the most likely story. Most likely is not the same as true. That is not a reason to keep models away from commentary. It is a reason to change the order of work: arithmetic first, done deterministically, and narrative second, written from the computed components rather than from the totals. ## How variance commentary goes wrong **Totals in, story out.** A model that sees only “revenue below plan” will explain it. It cannot do anything else. The explanation is a guess with good grammar. **Mix hidden inside volume.** Selling the same number of units with more of the cheaper product looks like a price problem in the totals and like nothing at all in the unit count. Without a product-level split, mix is attributed to whichever story is more familiar. **FX treated as noise.** For a company that invoices or buys in foreign currency, the gap between the plan rate and the actual rate can outweigh every operational driver combined. If it is not computed separately, it gets absorbed into “pricing” or “demand”. **No residual.** Every honest decomposition leaves something unexplained — timing, one-offs, credit notes, reclassifications. Commentary that explains the whole variance is a warning sign, not a comfort. **A method that changes between months.** If price is computed at plan volume one month and at actual volume the next, the components move when the business did not. The bridge has to use the same convention every time. ## What to do instead - **Decompose first, with fixed rules.** Build the bridge from plan (or last year) to actual by product, customer group or region: volume at plan price, price at actual volume, mix as the shift in shares, FX as the difference between plan and actual rate applied to foreign-currency sales. Choose one convention, write it down, and never change it quietly. - **Name the residual.** Whatever the components do not explain stays visible as its own line, with its size. If it is large, the commentary says so. - **Let the model narrate the components, not the totals.** Given a computed bridge, a model is genuinely useful. It can rank the drivers, connect them to known events and write the paragraph in the board’s language. It is now explaining numbers it was handed, not inventing them. - **Keep the bridge with the text.** The paragraph in the board pack should be traceable to the bridge that produced it, for the reasons set out in [what EU AI rules mean for a finance model](https://obserbi.com/blog/eu-ai-act-finance-models): when a number is questioned, the reasoning has to be reproducible. - **Watch which component keeps coming back.** If FX explains the miss three months running, the problem is the plan rate, not the month. That is the second-loop question described in [the autonomous CFO is not a dashboard](https://obserbi.com/blog/autonomous-cfo-is-not-a-dashboard). This division of labour suits local models well. The arithmetic is cheap and deterministic. The narrative step needs a model that is good with language and careful with numbers it is given, not one at the frontier of reasoning — so it runs comfortably on your own hardware, next to the data it describes. ## A test you can run today Take last month’s largest revenue or gross-margin variance against plan. From the ERP’s sales lines — quantity, net price, currency, product — split it into volume, price, mix and FX in a spreadsheet. The first time takes an afternoon. Then reread the commentary that went into last month’s management report. Does its first sentence name the largest component of your bridge? If it names something else, you have just measured how much your commentary depends on what people expected to see. Closing that gap — the arithmetic every night, the explanation on top of it, both on your own infrastructure — is what [ObserBI](https://obserbi.com/) is being built for. - variance analysis - price volume mix - management reporting - local LLM ## Keep reading - [Where to run the finance model so the data stays home](https://obserbi.com/blog/where-to-run-the-finance-model) - [The board asks: can we afford it? The answer should already exist](https://obserbi.com/blog/can-we-afford-it-answer-should-already-exist)