A semantic model is one agreed set of definitions for your business numbers, held in one place. It contains three things: your data organised into tables, the relationships that say how those tables connect, and your calculations, called measures, defined once. Every report then reads from that model, so "gross margin" means the same thing on every page, in every report, for every person.
That's the whole idea. The rest of this post is what it means for you as a buyer, because the model is the most important thing in a Power BI project and the least visible thing in a Power BI demo.
What is a semantic model, without the jargon?
Think of the difference between a company's published accounts and the ledger behind them. You can print the accounts in a dozen formats for a dozen audiences, but there's one ledger, and every format has to agree with it.
A semantic model is the ledger. It says: here is our sales data, here is our customer data, here is how a sale connects to a customer, and here, written down once, is precisely what we mean by revenue, margin, active customer and on-time delivery. A report is just a way of looking at that. Change the model and every report changes with it. Get the model wrong and every report is wrong in the same confident-looking way.
If you've heard the term "dataset" in Power BI, it's the same thing: Microsoft renamed datasets to semantic models in late 2023, partly to make the point that they're more than a pile of data.
Why should a buyer care what the model is called or contains?
Because it decides which of two situations you end up in.
In the first, every report was built on its own private copy of the logic. Someone wanted a sales report, so they pulled the data and wrote a margin calculation. Someone else wanted a board pack, so they pulled the data again and wrote a slightly different margin calculation. Nobody did anything wrong, and two years later the business has six reports showing six different numbers and a monthly meeting about which one to believe.
In the second, there's one model. Margin was defined once, argued about once, written down once. Every report reads it. When the definition needs to change, it changes in one place and every report follows. Disagreements between reports become impossible by construction rather than being policed by hand.
That's why I say the model is the product and reports are windows onto it. It's also why a cheap build that skips the modelling isn't a cheaper version of the same thing. It's the first situation with a nicer font.
What lives in the model, and what lives in the report?
This split is worth understanding before you buy anything, because it tells you where the real work in a quote should be going.
| The thing | Where it lives | Why it matters to you |
|---|---|---|
| What "margin" or "revenue" actually means | The model | Defined once, so every report agrees. This is where trust comes from |
| How customers connect to sales and to invoices | The model | Wrong relationships give answers that are confidently wrong |
| Who is allowed to see which rows | The model | Row-level security is set once, not rebuilt per report |
| Documentation of what each number means | The model | The definitions survive the person who wrote them |
| Which charts appear, and where | The report | Cheap to change; a new page takes hours, not weeks |
| Colours, branding and layout | The report | The visible part, and honestly the easy part |
| Which questions a page answers | The report | Different audiences get different windows onto the same truth |
The pattern in that table is the point: everything that makes numbers trustworthy lives in the model, and everything that makes them pretty lives in the report. A supplier whose proposal is all pages and visuals, with nothing about modelling, is quoting for the bottom half of the table.
How can you tell if a semantic model is any good?
You don't need to read code. Four questions do most of the work.
Does the same measure give the same answer everywhere? Ask to see gross margin on two different pages, filtered two different ways. If the totals reconcile, the logic is shared. If someone has to explain why they differ, it isn't.
Can a number be traced back to source? Pick a figure and ask them to walk it back to the system it came from. A well-built model makes that a five-minute demonstration. This is exactly what the logic and traceability area of my Health Check scores.
Are things named in your language? A model that says "Gross Margin %" and "Active Customers" can be read by your team and, increasingly, by AI tools. One that says "msr_gm2_final" can be read by one contractor, who has left.
Is it documented? Every measure should carry a description a human wrote. This used to be good manners; it's now load-bearing, because Copilot and similar tools answer questions using exactly those names and descriptions. A model that explains itself is most of what AI-ready means, and it's why Copilot readiness is really a modelling question wearing an AI costume.
Does a small business need a semantic model?
Yes, and this is the question I'd most like to rescue from the consultants. A semantic model isn't an enterprise luxury bolted onto Power BI for big companies. It's just the place where your definitions live, and a five-person business has definitions the same as a five-thousand-person one.
What a small business doesn't need is a sprawling one. A model with four or five tables, a dozen well-named measures and descriptions on each is a genuinely good model, buildable in days, and it'll quietly outperform the 40-table monster a larger firm would have sold you. Small and correct beats big and impressive every time I've seen the two compared.
What does getting one built properly involve?
The work runs in an order that surprises people: the questions come first, the model second, the reports last. A builder has to know which decisions the reporting supports before they can know what the model must contain, which is why a good one starts by asking about your business and a poor one starts by asking which charts you'd like.
In my Reporting System Build, the £9,500 three-week sprint includes exactly one modelled semantic layer, documented, underneath up to eight report pages, and the model is the deliverable I'd defend hardest. The reconciliation pack that proves the numbers match source is really a proof about the model. Pages can be added forever afterwards, cheaply, precisely because the layer underneath them is sound.
That's also the economics of it in one line: the model is where the cost is, and the model is where the value is. Paying less by skipping it doesn't reduce the price, it defers it, with interest, to the month you stop trusting the numbers.
Common questions
What is a semantic model in Power BI, in one sentence?
It's the single, shared layer that holds your data, the relationships between your tables, and every business calculation defined once, so that all your reports read from the same definitions and therefore agree with each other.
What's the difference between a semantic model and a dashboard?
The model holds the data and the definitions; a dashboard or report is a view built on top of it. One model typically feeds many reports. If the model is sound, a new report is quick and cheap. If every dashboard carries its own private logic, you don't really have a model at all, just a collection of reports that happen to look related.
Is a semantic model the same as a dataset?
Yes. Microsoft renamed Power BI datasets to semantic models in late 2023. Older documentation, courses and consultants say dataset; newer material says semantic model. Same object, and the rename was partly to signal that it holds business logic, not just data.
What is a measure?
A measure is a saved calculation in the model: gross margin percentage, orders this month, revenue year to date. The point of a measure is that it's written once and reused everywhere, so the same question always gets the same arithmetic. When two reports disagree, the cause is very often two hand-rolled versions of what should have been one measure.
How many semantic models should a business have?
As few as honestly cover the ground, and for many SMEs that's one, or one plus a finance-specific model. Every extra model is another place definitions can drift apart. What you want to avoid is the accidental version: dozens of models because every report shipped with its own, which is how businesses end up unable to say what their own revenue number is.
Does Copilot need a good semantic model?
It needs one more than a human does. A person can ask a colleague what "msr_gm2_final" means; Copilot answers from the model's names, descriptions and relationships as they stand. Clear naming, documented measures and correct relationships are the difference between an AI answer worth reading and confident nonsense delivered quickly.
Can each report just have its own model?
It can, and that's how most messes start, because it's the path of least resistance: each new report pulls its own data and writes its own logic. It works for a while, then definitions drift, reports disagree, and trust goes. One shared model is slightly more work on day one and much less work every day after.
If you want to know whether the model you already have would pass the four questions above, that's what the £950 Health Check scores, in writing, within five working days. Prices for my services are as published on the linked pages, September 2026.