Why Power BI Reports Show Different Numbers - and How to Fix It

When the same metric shows different numbers in different dashboards, trust in data collapses. Here's the architectural fix.

You've seen it before. The finance dashboard says revenue is £4.2m. The sales dashboard says £4.6m. Someone pulls an Excel file and gets a third number. The Monday morning meeting grinds to a halt while three people argue about whose figure is right.

This is not a data quality problem. It's an architecture problem - and it's fixable.

Why the numbers disagree

Power BI makes it very easy to build reports quickly. That's a strength. It's also the root cause of most governance failures. When each report developer writes their own DAX measures, connects directly to source systems, and applies their own business logic, the results diverge - sometimes in small ways, sometimes dramatically.

• Finance includes deferred revenue. Sales doesn't.
• One report filters out cancelled orders. Another doesn't.
• The date logic uses order date in one report, invoice date in another.
• Currency conversion is applied at different points in the pipeline.

None of these are mistakes. They're judgment calls - made independently, without coordination, because there was no agreed standard.

The architectural fix: a governed semantic model

The solution is a single, certified semantic model that every report connects to. In Power BI terms, this is a shared dataset (now called a semantic model) published to a certified workspace and endorsed as the authoritative source for a given business domain.

When all reports pull from the same semantic model, they all use the same metric definitions, the same business logic, and the same security rules. The numbers agree because they come from one place.

What a governed semantic model contains

• Agreed metric definitions (revenue, margin, headcount) documented and versioned
• Relationships between tables defined once and reused across all reports
• Row-level security applied at the model layer, not in individual reports
• Certified and endorsed status so users know which dataset to trust
• Change control - updates go through a review process, not ad hoc edits

How to get there

Most organisations with this problem don't need to start from scratch. They need to identify the one or two reports that leadership relies on most, extract the business logic into a shared semantic model, and then rebuild those reports to connect to it.

1. 1Audit your existing reports and identify every place where the same metric is defined differently
2. 2Agree the correct definition with the business - this is a conversation, not a technical decision
3. 3Build the semantic model with the agreed definitions and publish it to a certified workspace
4. 4Rebuild the priority reports to connect to the shared model
5. 5Deprecate and retire the old reports on a planned timeline

The hardest part is not the technical work. It's getting agreement on definitions. 'Revenue' means different things to finance, sales, and operations. The semantic model forces that conversation - which is uncomfortable but necessary.

What you should expect after

Organisations that implement a governed semantic model typically see three things happen quickly. First, the Monday morning data arguments stop - not because everyone agrees on everything, but because there's one number and one place to challenge it. Second, report development accelerates, because developers no longer build the same logic repeatedly. Third, new starters ramp up faster, because the model documents how the business thinks about its data.