One KPI. One definition. Fewer dashboard arguments.
A KPI contract turns a familiar label such as revenue, margin or active customer into an owned, testable business rule that every report can reuse.
Customer invoices, net of returns and discounts, in GBP
Approved definition
Migration in progress
Example governance indicators, not measured customer performance.
A technically correct dashboard can still answer the wrong business question
Finance may recognise revenue when an invoice is posted. Sales may count an order when it is won. Operations may exclude cancellations only after fulfilment. Every calculation can be internally consistent while the meeting still contains three incompatible answers labelled “revenue”.
The label stays the same while the hidden assumptions change
Most reporting disputes are not caused by chart colours. They come from decisions that were never made explicit.
Different scope
One report includes credits, internal trading or provisional records while another quietly removes them.
Different time logic
Order date, invoice date, posting date and service date place the same transaction in different periods.
Different source
A spreadsheet adjustment, finance system and CRM pipeline can each become an unofficial system of record.
Make every important metric specific enough to test
A contract is a concise agreement between business owners and data teams. It records what the KPI means, how it behaves and who can approve change.
Purpose and decision
State the question the KPI answers, the decisions it supports and situations where it must not be used. A measure without a decision purpose becomes a decorative number.
Calculation, grain and scope
Record the numerator, denominator, aggregation, record grain, filters, status rules, currency treatment and handling of blanks, duplicates, returns and late corrections.
Time and comparison behaviour
Define the governing date, calendar, timezone, closed-period rules, refresh expectation and valid comparators. “Last month” must mean the same thing on every report.
Ownership and quality controls
Name a business owner who decides meaning, a data steward who maintains evidence and a technical owner who implements and monitors the measure.
Source, lineage and approved implementation
Link the definition to its authoritative source, semantic model measure, endorsed content and dependent reports. Record the version and change history.
Turn “total revenue” into a reviewable business rule
The example below demonstrates the level of precision required. Every entry is illustrative and must be adapted to the organisation’s accounting policy.
| Contract field | Illustrative definition | Evidence required |
|---|---|---|
| Decision purpose | Monitor recognised customer revenue by trading month and operating unit | Finance-owner approval |
| Formula | Posted customer invoice value less posted credit value, excluding VAT and internal trading | Reconciliation to finance ledger |
| Grain | Posted invoice or credit line | Unique document and line key |
| Date basis | Accounting posting date within the approved financial calendar | Calendar and closed-period rules |
| Currency | GBP using the approved accounting conversion method | Rate source and conversion date |
| Data owner | Finance Director | Named delegate and review cadence |
| Implementation | Explicit measure in the certified Finance semantic model | Model reference, tests and endorsement |
| Change policy | Impact review, owner approval, version note and consumer communication before release | Change record and affected-report list |
Separate who defines, implements, assures and uses the metric
A data team should not be forced to invent accounting, customer or workforce policy through DAX. Business accountability and technical delivery are different responsibilities.
Business owner
Approves meaning, scope, acceptable use and material changes. Resolves policy disputes.
Data steward
Maintains the contract, quality evidence, review dates and glossary relationships.
Model owner
Implements the approved logic once, tests it and manages semantic-model releases.
Report owner
Reuses the approved measure, explains context and avoids local redefinition.
Move from proposal to trusted reuse without creating bureaucracy
Use a short evidence-based workflow. Higher-risk KPIs need stronger review; local exploratory measures can remain clearly labelled as ungoverned.
Capture the decision need
Describe the requested measure, intended audience, current conflicting definitions and business risk. Search for an existing contract before creating another.
Resolve policy before implementation
Run a focused workshop with the business owner, steward and model owner. Use real edge cases such as cancellations, back-dated transactions and missing classifications.
Build once in the approved semantic model
Create an explicit measure, document it, reconcile expected totals and test filter behaviour. Reuse it rather than recreating the logic in each report.
Review evidence before certification
Confirm ownership, reconciliation, quality thresholds, security, refresh behaviour, descriptions and downstream impact. Certification should mean more than “the report looks right”.
Monitor adoption and change
Track dependent reports, retirement of duplicates, issue trends and review dates. Use lineage and impact analysis before changing shared semantic models.
Judge the model by business confidence and reuse
Targets should be set from a baseline. These are measurement categories, not universal performance promises.
Critical KPIs contracted
Decision-critical KPIs with an approved definition, owner, implementation and review date.
Reports on endorsed models
Priority reports consuming approved semantic models rather than rebuilding local logic.
Changes with impact review
Material metric changes assessed for downstream consumers before release.
Definition disputes
Time lost reconciling competing answers and the number of unresolved metric-definition incidents.
Can your most important KPI survive a challenge in the boardroom?
Select each statement that is true for one decision-critical KPI. This is an illustrative readiness check, not an audit.
Questions teams ask before standardising metrics
Do we need to govern every measure?
No. Prioritise measures whose disagreement could change a financial, customer, workforce, operational or regulatory decision. Local exploratory measures can remain flexible when their status and limitations are clear.
Who should own a KPI: finance, IT or the data team?
The accountable owner should come from the business function that owns the meaning and decision. Data and IT teams implement, test and operate the measure, but should not invent business policy alone.
Is a Microsoft Purview glossary enough?
A glossary provides valuable business context and can connect terms to governed assets. The operating model must still include ownership, calculation evidence, semantic-model implementation, change control and adoption.
Does Power BI certification guarantee a correct KPI?
No. Certification indicates that content has met the organisation’s quality standards. Those standards must be defined and supported by evidence; the badge cannot replace business approval, reconciliation or testing.
Should every report calculate the KPI itself?
No. For important reusable measures, implement the approved calculation in a governed semantic model and let reports consume it. Local copies create drift and make controlled change harder.
How should we change an established KPI?
Record the reason, assess downstream impact, test the revised logic, obtain owner approval, version the contract, communicate the effective date and decide whether historical values will be restated.
Turn disputed dashboard numbers into owned, reusable business definitions
Smart Statistics helps UK businesses design KPI catalogues, governed Power BI semantic models, reporting controls and practical ownership structures. Start with the measures that create the most debate or carry the greatest decision risk.
Technical references
Microsoft documentation checked on 20 September 2026. The KPI contract, ownership model, lifecycle, example and assessment are illustrative Smart Statistics recommendations.