The first question after any number moves is why. Revenue is below plan, gross margin slipped, a cost line jumped. The dashboard shows the what in seconds; then analysts spend days on the why, pulling extracts, slicing by region and product, and calling colleagues who might know. By the time the explanation arrives, the meeting has moved on.
Three techniques, used together, shorten that loop. Driver decomposition says how much each factor contributed. Anomaly detection says which of those contributions are unusual. A language model turns the result into a few plain sentences that cite the drivers. None of the three is new on its own; the value lies in combining them on numbers finance already trusts.
Start with the bridge
Every explanation begins with arithmetic. A bridge decomposes the change in a measure into the factors that produced it: for revenue, volume, price and mix; for margin, price, mix, input costs and freight; for operating expenses, headcount, rates and one-time items. The same decomposition then runs down the hierarchy, by region, product and customer, so the bridge says not only which driver moved but where.
The rules of the bridge are a finance decision, not a data science one. Agree them once with the controller and build them into the reporting model, so every report and every explanation uses the same arithmetic. If your team already reviews a bridge every month, for example as part of a rolling forecast, most of this work is done.
Separate the unusual from the expected
Not every movement deserves an explanation. Seasonality, calendar effects, planned price changes and budgeted growth all move numbers in ways nobody needs to discuss. Anomaly detection learns the expected range of each measure in each segment from its own history, including its weekly and seasonal patterns, and scores how far the latest value sits from that range. A high score means a movement is unusual for that segment at that time, not merely large. Fixed thresholds cannot make that distinction: they flag every seasonal peak and miss the slow drift that matters.
The scores do two jobs. They tell readers which drivers deserve attention, and they keep the explanation short: commentary that lists every movement buries the one that matters. They also work in the other direction, because a large movement that the model expected, such as a seasonal peak, needs one line rather than an investigation.
Let the language model write, not calculate
A language model is good at turning a table of drivers and scores into readable sentences. It is not a calculator, and it should never be asked to find the numbers itself. The design that works is simple: the reporting model computes the bridge, the anomaly model scores it, and the language model receives both as structured input, with instructions to lead with the largest unusual driver, quantify it, name the segment and cite the source. Every number in the explanation can then be traced to a number in the model. The instructions also fix the tone: plain words, no adjectives the numbers do not support, and the same order every time.
The explanation should also say what it does not know. If the largest driver is unusual and nothing in the data accounts for it, the right sentence states the movement and says that the cause is not yet in the data. A plausible guess is worse than an honest gap.
Add what the data cannot see
Many movements have causes outside the systems: a price increase announced to customers, a plant shutdown, a renegotiated carrier contract, a promotion moved by a week. Keep a simple calendar of known events, owned by the business, and give it to the model alongside the numbers. When an analyst confirms or corrects an explanation, store that too. The explanations improve with every cycle, because the system learns what the organization already knows.
The same calendar improves the anomaly scores. A spike that coincides with a known event is expected, and the explanation can say so in one line instead of raising an alarm.
Keep people in the loop where it counts
Automated explanations change the analyst’s role rather than remove it. Analysts review the explanations for the largest and most unusual movements before they reach leaders, investigate the ones the data cannot explain, and decide when a pattern that keeps recurring should become a new driver in the bridge. That review is also what makes the approach credible: leaders learn that the explanation in front of them has been read by someone who knows the business.
Building the anomaly models and connecting them to the language model is standard machine learning work. Deciding which movements matter, and what the organization should do about them, stays with people.
Where to start
Choose one measure leaders ask about every month, usually revenue against plan or gross margin, one hierarchy, and a bridge finance already agrees with. Run the explanations alongside the analysts’ own for a few cycles, compare them, and publish when the controller is comfortable. Then extend to the measures that generate the most follow-up questions.
The goal is not to replace the analyst. It is to give leaders the why at the same moment as the what, and to give analysts their time back for the movements that genuinely need investigation.