When two reports disagree, the cause is almost never a bug. It is that the same metric was defined twice, slightly differently, by two people who both did reasonable work. A semantic model is where each measure gets defined once, so every report inherits that definition instead of recreating it.

Everyone who has worked with company data has been in the meeting. Two people, two dashboards, two different revenue figures, and nobody can say which is right. It usually ends with someone exporting to Excel to check by hand - which is how a reporting system quietly stops being trusted.

Why the numbers disagree

Because "revenue" is not one thing.

Ask two competent people to build a revenue report from the same database and they will make a dozen small decisions each. Include VAT or not. Deduct credit notes or not. Book on invoice date or payment date. Count unpaid invoices. Exclude intercompany. Remove test orders. Convert currency at transaction rate or month-end rate.

Each choice is defensible. Neither report is wrong. They answered slightly different questions and neither says which question it answered.

That is the actual failure: the definition lives inside the report rather than beside the data. Change the person, change the report, change the number.

What a semantic model is

A layer between raw tables and reports where business meaning gets written down.

Instead of every report in your Power BI environment calculating revenue from raw columns, there is one definition of net revenue. One definition of active customer. One definition of gross margin. Reports reference those. When the definition changes, it changes once and everything follows.

Three things live in it:

Measures. The calculations - net revenue, margin, churn rate, average deal size. Written once, in DAX or in the warehouse, referenced everywhere.

Relationships. How tables connect, so a filter on one flows correctly to another. This is also what makes reports fast - see why Power BI reports get slow, where the same structure does double duty.

Names people recognise. `ord_hdr.amt_2` becomes "Net revenue". Not cosmetic - it is what lets someone build their own report without asking which column to use.

Semantic model versus data model

The terms get used interchangeably and they are not the same.

The data model is structure: which tables exist, how they join, what the keys are. It is a technical fact about your data.

The semantic model is meaning: what those structures represent in business terms. It is a set of agreements about language.

You can have a perfect data model and still get two revenue figures, because nobody agreed what revenue means. Structure without meaning is where most reporting problems actually live.

The hard part is not technical

Writing a measure takes minutes. Agreeing what it should say takes weeks, because it means finance, sales and operations settling on a single definition when each has a working one already.

Sales counts a deal when it is signed. Finance counts it when it is invoiced. Operations counts it when it ships. All three are right for their purpose, and all three have been reporting their own number for years.

A semantic model forces that conversation. Which is uncomfortable and is also the entire value - the software problem was never the problem.

Practically: pick the five most-argued-about metrics, get the people who own them in a room, and write down what each one means. That document is the start of the model and it is useful even if you never build anything.

Where the model should live

In a Power BI dataset. Fine for one team with one main report. Fast to build, no extra infrastructure. Limit: the definitions only exist inside Power BI, so anything else reading your data does not get them.

In a data warehouse. Definitions sit in the data itself, usually built with dbt, and Power BI reads finished tables. More setup, and it means Excel, another BI tool and an AI assistant all inherit the same definitions rather than each inventing their own.

Small company, one reporting tool: start in Power BI. Several tools reading the same data, or an AI in the picture: the warehouse is where it belongs.

The part that matters more now than it used to

Two people disagreeing is an old problem, and companies have lived with it for decades by having a person adjudicate.

Connecting an AI assistant to your data removes the adjudicator. Ask it for revenue against raw tables and it makes those same dozen choices - silently, and possibly differently each time. You get a number with no person behind it and no way to know which question it answered.

A semantic model is what stops that. The assistant reads the same definitions your dashboard does, so the two agree, and when they do not you know the model has a gap rather than the AI having invented something. We wrote about that in detail in why AI gets your numbers wrong.

Where to start

Take the metric your company argues about most. Ask three people to write down what it means, separately, in one sentence.

If the three sentences match, you do not have this problem. If they do not, you have found both the reason your reports disagree and the first entry in your semantic model.

Frequently asked questions

What is a semantic model in Power BI?

The layer between raw tables and reports where business meaning is defined - what counts as revenue, what an active customer is, how margin is calculated. Reports read those definitions rather than each recalculating from raw columns.

Published · Updated · Last reviewed