Driver‑based Power BI example

A small Power BI thread landed because it showed something most finance dashboards still avoid: not just what changed, but what likely caused the change. In a public post, analyst Shina Awopeju walked through a revenue decomposition that split performance by department, day pattern, and inventory status, then used those cuts to explain why growth was uneven across the business. The example did not treat revenue as a single number drifting up or down. It treated revenue as the result of specific operating conditions that could be isolated and acted on (sites.google.com, github.com). That distinction matters because Power BI has long been built for slicing metrics, and Microsoft’s own sample reports still frame revenue in familiar ways: by region, deal size, channel, or period. Those views are useful, but they mostly answer the first question in management reporting. What happened. Microsoft’s decomposition tree goes a step further. It lets users start with a measure, then drill into contributing dimensions in any order, with AI-assisted splits that surface the highest or lowest contributors for ad hoc root-cause analysis (learn.microsoft.com, learn.microsoft.com). Awopeju’s example used that logic in a way finance teams immediately recognized. The decomposition traced stronger revenue to a handful of departments, showed that weekends behaved differently from weekdays, and exposed a gap tied to unsold inventory rather than weak demand alone. That is a more serious use of BI than the standard budget-versus-actual page. It turns a dashboard from a scoreboard into a map of pressure points. Her broader portfolio makes that emphasis explicit. She describes her work as turning operational data into recommendations, not just charts, and highlights measurable gains from faster reporting, cost savings, and revenue improvement (sites.google.com, github.com). The reaction thread pushed the argument further. The claim was that FP&A should stop living in descriptive A/B reporting and move toward causal inference and prescriptive modeling. That sounds grander than the example itself, but the direction is real. Driver-based planning in modern FP&A is built on the idea that forecasts should be linked to operating drivers such as volume, price, utilization, acquisition, churn, or labor inputs, rather than rolled forward from last year’s totals. CFI’s recent guide makes the case plainly: static, historical planning misses the real drivers of performance, while driver-based models adapt as business conditions change (corporatefinanceinstitute.com). Finance trade groups have been saying the same thing for years, though usually in duller language. The Association for Financial Professionals defines driver-based modeling as building calculations that reference underlying variables, then using those variables to drive outcomes. Its guide argues that finance teams need to understand what numbers are made of, work with business owners to identify the drivers that matter, and use rolling forecasts to give management time to act before results harden into history (financialprofessionals.org). That is why the thread spread beyond Power BI enthusiasts. It captured a broader change in finance work. The old monthly pack explains variance after the fact. The newer model tries to connect revenue and margin to operational levers while there is still time to intervene. Power BI’s decomposition tree is not causal inference in the strict statistical sense. It cannot, by itself, prove that weekends caused weak sales or that inventory gaps caused lost revenue. But it can force the right next question into view, and in this case the next question was concrete enough to matter: which departments were carrying growth, what happened on weekends, and how much money was sitting in products that never sold (learn.microsoft.com, financialprofessionals.org).