Reports come and go. The Power BI semantic model is the asset that lasts. One quick test tells you whether you have a model or fourteen lucky coincidences.

The report is the paint. The Power BI semantic model is the building.

For years the wrong half of Power BI got all the attention. The report was the deliverable, the thing people admired and signed off. The model underneath was something you assembled in a hurry to make the visuals work, then never opened again. That is backwards, and the bills come in slowly.

For more on this, see our Power BI service. It is also worth reading alongside You can build a dashboard in twenty minutes. That is the easy part if the topic is new to you.

The good news is that the tooling has finally caught up with the truth. The Power BI semantic model now stands on its own: built in the browser, kept under version control, and with Direct Lake able to sit straight on top of the data in OneLake. It is a first-class thing, separate from any report that draws on it. Which is exactly what it always should have been, because the model is where the value lives.

Fourteen versions of revenue

We picked up a client with nine reports and, when we counted, fourteen different definitions of revenue spread between them. Each had been built inside its own file, each was internally consistent, each looked entirely professional. Nobody had done anything obviously wrong.

It surfaced the week two of those reports landed on the same desk showing different numbers for the same month. The finance director did not lose faith in the two reports. He lost faith in all of them at once. That is how trust goes in a reporting estate, not one report at a time but the whole lot together, the moment two figures that should agree do not.

The real cost was not the afternoon it took us to find the cause. It was the half-year of decisions made on numbers that were quietly off, and the year afterwards when every report was treated as guilty until proven innocent.

One question tells you where you stand

Pick your most important measure. Total revenue will do. Now answer this: is it defined once, in one place that every report reads from, or is it written out in DAX inside more than one file.

Defined once, you have a semantic model doing its job. Written out in three files, you do not have a model. You have three coincidences that happen to agree today and will not forever, because someone will tweak one of them late on a Friday and you will be back to fourteen versions before anyone notices.

What good looks like, in one breath

Three habits separate the asset from the afterthought. Every measure defined once, in the model, never re-typed into a report. The model under version control, so you can see who changed what and when, which is the thing TMDL finally makes painless. And a named owner, so changes are deliberate rather than accidental. None of it is exotic. It is simply treated as optional far too often, usually right up until the day it is not.

So if your reports keep telling slightly different stories, leave the reports alone. Run the one-question test on your headline measure, and start wherever the answer points. Building and governing that model properly is the spine of our Power BI work, and the foundation everything else, including the wider Microsoft Fabric estate, ends up standing on. Repaint the building as often as you like. Just do not keep pouring the foundations twice.

If any of this sounds familiar, talk to us about your data.

Related reading

• Your semantic model just became more important, not less
• The Business Central reports a finance team needs
• Power BI Semantic Models: The Missing Layer Most Implementations Skip