When Two Reports Disagree,
the Model Is Why
Revenue defined three times in three files by three people, each of whom made a defensible decision. The fix is a semantic layer, and it is as much a governance job as a technical one.
Symptoms
The signs you have
a model problem
Both built competently from the same warehouse. Nobody can say which is right, so leadership trusts neither.
Somebody spends two days a quarter finding a difference that turns out to be intercompany. Then it happens again.
Usually a ratio stored as a calculated column. Correct at every row, wrong at every total, and plausible enough that nobody checks.
No descriptions, no documentation. The definition exists only in the head of whoever wrote it.
Faster than untangling the existing one, which is exactly why the number of definitions keeps growing.
Almost always a date table with gaps, or one that was never marked as a date table.
Why It Happens
Nobody decides to define
revenue three times
It accumulates. A report is built for finance using the definition finance uses. Six months later operations needs something similar, and rather than untangle the finance model, someone builds a fresh one. The second build is faster, which is precisely why it keeps happening.
Self-service tooling accelerates this, and that is not an argument against self-service. The ability for capable people to build their own reports is genuinely valuable. It just means the number of independent definitions grows with the number of capable people, and nothing in the tooling prevents that.
The fix is a layer where business meaning is defined once and reports consume it rather than restating it. The technical work is straightforward. The part that takes time is getting finance and operations to agree what revenue means — and no consultant can do that part for you, only facilitate it.
What We Do
What we build
and hand over
Every measure currently in use and the file it lives in. This alone usually surprises people.
We facilitate the conversation that settles contested definitions, and write down what was agreed including the edge cases.
Facts and dimensions structured for the engine rather than for whoever built it first. Usually a large size reduction as a side effect.
Written in the semantic layer with descriptions, so both people and Copilot get the right answer.
Reports repointed one at a time, each validated against what it replaces until the numbers tie.
Published somewhere readable without opening Power BI, so the agreement survives staff turnover.
Engagement
Timeline
and Cost
A semantic model rebuild for a single subject area typically runs four to six weeks. Multi-subject environments run longer, and we would scope them as phases rather than one engagement. The definition workshops are the variable — if your organisation already agrees what its metrics mean, this moves considerably faster.
FAQ
Questions
We Get Asked
Yes, and you should not accept an approach that requires it. We build the new model alongside the existing reports, validate until the numbers tie, then repoint reports one at a time starting with the least politically sensitive.
Then the honest output is a documented decision that they mean different things, with two clearly named measures rather than one ambiguous one. Net Revenue and Gross Revenue, both defined, both visible. That is better than pretending to a single number nobody believes.
Usually, as a side effect. A star schema compresses better than a flattened table, often by more than half, and the engine is built for it. Speed is not the goal here though — correctness is.
Rarely. The semantic layer sits between your warehouse and your reports. We work with what you have unless the warehouse itself is the problem, which we would tell you rather than quietly work around.