Three reports are open on three screens in a Monday finance meeting. All three claim to show last month’s revenue. All three show a different figure. Nobody in the room can say which one is right, so the meeting stops being about the business and turns into an argument about the data.
If you run reporting in Power BI, you have probably sat through some version of that. The first instinct is to assume the data is broken somewhere upstream, so someone goes off to check the source system. Usually the source is fine. Each number was calculated correctly. They just weren’t calculated the same way, because each report was built by a different person who wrote their own version of the maths.
The data is usually fine. The definitions are not.
“Revenue” sounds like one thing. In practice a business carries several honest versions of it. Is it gross, or net of credit notes and refunds? Booked on the invoice date or the delivery date? Does it include intercompany sales, or strip them out? Each of those is a defensible choice, and each produces a different total for the same month.
When three analysts build three reports, each one makes those choices on their own, often without realising a choice was being made. The logic gets baked into a DAX measure and never written down anywhere a human reads. The reports then agree only by coincidence, and they stop agreeing the moment an edge case shows up, like a large refund landing in a new month.
How self-service reporting drifts
Power BI is good at letting anyone build a measure. That is why teams adopt it, and it is also why the numbers drift. Someone needs a margin figure for a board pack, writes a measure, and ships the report. A month later a colleague needs something similar, can’t find the first one, and writes their own with a slightly different filter. Now there are two definitions of margin, both live, both trusted by whoever built them.
Repeat that across a year and a growing team and you get dozens of measures that look alike and behave differently. The tool has no opinion about which version of margin is the real one. It will calculate all of them, correctly, forever. Left alone, a self-service estate drifts toward disagreement by default, and no amount of double-checking the source data will pull it back.
What a semantic model actually does
The fix is to stop scattering the definitions across reports and put them in one place. A semantic model is a governed dataset that sits between your data and your reports. It holds the tables, the relationships between them, and one certified measure for each metric that matters. Revenue is written once, in that model, and every report points at it instead of re-deriving it.
Practically, that means a well-shaped star schema, measures written in DAX that live in the shared dataset rather than inside individual reports, and access rules applied in the model so the same person sees the same rows whichever report they open. When a definition needs to change, it changes in one measure and every report that uses it updates together. Reports become views onto a single agreed model rather than private calculators.
Governance is the part that gets skipped
Building the model is the technical half. The half that keeps the numbers agreeing over time is governance, and it is mostly an agreement between people that the model then enforces. In Power BI that looks like a few concrete things:
- A named owner for each metric. Someone in the business, usually in finance or operations, signs off what “revenue” means and is the person who approves a change to it.
- Certified datasets. The governed model is marked as endorsed so report authors can tell the trusted source from someone’s weekend experiment.
- Change control. A measure changes through a reviewed process, not because a contractor edited it in a hurry before a deadline.
- Retiring the duplicates. The old competing measures get removed, so people can’t quietly keep using them.
None of this is exotic, and none of it is expensive compared with the cost of a leadership team that no longer trusts its own reports. The reason it gets skipped is that it feels like overhead when there are only two reports and one analyst. By the time the disagreement is obvious, the estate is large enough that untangling it is real work.
How we tend to fix it
When we do this for a client, the first step is not to build anything. It is to catalogue what already exists: every place “revenue” or “margin” is defined, and how each one differs. That inventory is usually the moment the disagreement becomes visible to everyone, because you can finally see the four definitions side by side.
From there we agree the certified definition of each metric with the business owner, build the governed measure library in a single semantic model, apply the security rules, and then retire the duplicates so there is one path to each number. We hand the model over documented, so your own analysts can extend it and answer new report requests from the same certified measures instead of inventing another one.
What changes once it is in place
The monthly reconciliation argument goes away, because the reports resolve to the same measure and that measure ties back to the source. New reports get faster to build, since the hard part, agreeing what the numbers mean, is already done. And the Monday meeting goes back to being about what the business should do, rather than whose spreadsheet to believe.
If your reports disagree today, it is worth finding out whether the cause is the data or the definitions before you spend another cycle checking the source. In our experience it is almost always the definitions, and that is a fixable problem.