Departments calculate the same KPI differently because each one builds its own measure in its own report, and nobody wrote down which version is right. The fix isn't a better data model. It's one agreed definition per KPI, one named business owner who can change it, and that definition shown on every report that uses the measure. Once readers can see which version they're looking at, the argument moves from the meeting to the owner.
Why the same KPI drifts between departments
Most teams treat conflicting numbers as a modelling or data quality problem. Usually it isn't. The data is often fine. What's missing is an agreement on what the number should count.
For example: Finance reports revenue on the invoice date, net of credit notes, without intercompany sales. Operations reports revenue on the shipment date, at gross order value. Both reports are called "Revenue". Both are correct by their own rules. Neither says which rule it uses.
In practice, drift creeps in through small, reasonable choices:
- A team copies a semantic model and adjusts one measure for its own needs.
- An analyst writes a local measure in Power BI Desktop because the shared one is "nearly right".
- Two reports use the same measure but filter it differently: another date, another scope, returns in or out.
- A field gets renamed in one report, so nobody notices it's the same thing.
None of these is a mistake on its own. Together, they give you three versions of one KPI and a management meeting that starts with "which number is right?".
Finance and Operations report different numbers for the same KPI. How do we fix that?
Start with the two numbers, not the data model. Most differences are explained in one working session.
- Put both reports side by side for the same period.
- Write out each calculation in plain words: what's counted, from which date, and what's left out.
- Find the difference. It's usually the date, the scope or an exclusion.
- Decide which version belongs on the management report. That's a business decision, not a technical one.
- Keep the other version if it's useful, but give it its own name and its own definition.
Two numbers can both be right. They can't both be called Revenue.
How do I get departments to agree on one definition for a KPI?
Don't aim for consensus in a large meeting. Aim for one decision by one person who has heard both sides.
- Agree the question first. Ask what the KPI is meant to answer. "How much did we sell this month?" and "How much cash will this bring in?" need different definitions.
- Let one owner decide. For financial KPIs that's usually someone in Finance. Others get a say, not a veto.
- Allow variants with their own names. "Revenue (shipped)" can live next to "Revenue" as long as each is defined.
- Write the decision down with a date. When the question comes back in a year, the answer is already there.
In practice, departments agree faster when they see their own version will survive under a clear name. The fight is usually about losing a number, not about the definition itself.
Where the definition lives decides whether it holds
Power BI gives you good tools to build one measure once. It does less to show readers which definition they're looking at.
| Approach | Stops duplicate calculations | Readers see which version | Who keeps it current |
|---|---|---|---|
| One shared semantic model | Mostly, if teams use it | No | The BI team |
| Certified dataset badge | No, it signals trust only | No | Whoever certifies |
| Glossary document or wiki | No | Only if they open it | Often nobody after launch |
| Definition shown on the report | No, but it makes drift visible | Yes | The named owner |
The first two stop the calculation drifting. The last one stops the meaning drifting. You need both.
A practical framework: Name it, Define it, Own it, Show it
- Name it: one name per KPI, used the same way in every report, with variants named differently.
- Define it: one plain-language sentence on what's counted, from which date and what's left out.
- Own it: one named business person who can change the definition, not a team or a department.
- Show it: the definition and owner visible on every report that uses the measure, where people read the number.
What to do first
Don't try to define every measure in your Power BI estate. Pick the five KPIs people argue about most, usually the ones on the monthly management report. Run the side-by-side comparison for each, get one owner to decide, and publish the definitions where the reports are read. Then add the next five.
Where dScribe fits
dScribe keeps each KPI's agreed definition and named owner in one place. Its browser plugin shows them on the Power BI reports your teams already open, so readers see which version they're looking at, and who to ask, without leaving the report. In dScribe you can also see which reports use a given measure definition. When an owner changes a definition, you know which reports it touches before anyone reads a different number.
In short
Conflicting numbers feel like a technical problem, so they get sent to the BI team. Most of the time, the real gap is a decision nobody made. Agree the definition, give it one owner, and put it on the report. The model can follow.
Frequently asked questions
Our management reports show different numbers for the same thing. Whose job is it to fix that?
A named business owner's, not IT's. For a financial KPI that's usually a finance lead, who decides what the number should count. The BI team then builds that definition once and makes sure every report uses it.
Can Power BI enforce one definition of a KPI?
Partly. A shared semantic model and certified datasets help teams reuse one measure. They don't stop someone writing a local measure, and they don't record who agreed the definition or why.
Is this a data quality problem?
Sometimes, but check the definition first. If two reports use different dates, scopes or exclusions, the data can be perfect and the numbers will still differ.
Should we allow more than one version of a KPI?
Yes, if each one answers a different question. Give each version its own name and its own definition, so nobody compares them as if they were the same number.
Where should KPI definitions be documented in Power BI?
In the semantic model as measure descriptions, so builders see them. And on the report itself, so readers see them. A separate document alone rarely gets opened.