The Report Is Correct. The Definition Is Not.

Two teams open two different reports.

Both are looking at the same KPI.

Both reports are technically correct.

And the numbers are different.

This is one of the most frustrating situations in reporting because the immediate assumption is usually that something is wrong with the data.

Very often, nothing is wrong with the data.

The reports are simply not measuring exactly the same thing.

One report may include an additional sales channel.

Another may exclude a certain market.

One may use a different period, customer status or product category.

A business rule may have been added because one team needs a more specific view of the business.

The calculation can be completely correct in both cases.

The problem starts when both reports use the same KPI name.

At that moment, users naturally assume they are looking at the same business definition.

They are not.

And this is where Data Governance becomes important.

The business must have the final word on what a KPI means.

It understands why the metric exists, which decisions depend on it and what should or should not be included in the calculation.

Data Governance should not invent that definition.

It's role is to make sure the definition is clearly documented, consistently governed and understandable across the organisation.

Every important KPI should therefore have its own formal definition.

Not only a name and formula.

The organisation should know its scope, included and excluded elements, business owner, source data, calculation logic and any relevant variations.

Even two very similar KPIs should be documented separately.

Similarity is not the same as equivalence.

Local variations can still exist.

A commercial team may legitimately need a slightly different version of Revenue than Finance.

That is not necessarily a governance failure.

The failure happens when the difference is invisible.

If the variation is relatively small, a clear disclaimer directly inside the report may be enough.

If the difference materially changes the business meaning, the KPI should probably have a different name.

The important part is that the user should never have to discover the difference by accident.

Documentation alone, however, is not enough when a KPI contains unusual exclusions or business-specific logic.

Those differences should be visible in the report itself.

A tooltip, information box or short explanation can prevent a long investigation later.

For standard KPIs, accessible and up-to-date documentation should normally be sufficient.

Users also have responsibility.

Data Governance can define, document and explain a KPI, but it cannot interpret every number on behalf of every person in the organisation.

Once users have been trained, know where the documentation is and have access to it, they are expected to use it.

The same principle applies when the business changes the KPI.

A new business rule cannot simply appear in a dashboard without anyone knowing how or why it changed.

For critical KPIs, the process should be formal.

The Data Owner initiates the change.

Data Governance assesses the impact and updates the documentation.

The BI or Data team implements the new logic.

The business confirms that the result reflects what was intended.

Only then should the change move into production.

Because when two technically correct reports show different numbers, the right question is not always:

“Which report is wrong?”

Sometimes the better question is:

“Are we actually measuring the same thing?”

And very often, that is where the real problem begins.