A reporting dispute often looks like an analytics problem. In an illustrative case, one dashboard says 1,240 customers, another says 1,198 and a spreadsheet says 1,311. The instinct is to fix the report. But all three outputs may be faithfully representing three different definitions or data paths. Nobody made an arithmetic mistake; the organisation simply never agreed what it was counting.
Poor data quality is widely recognised as an obstacle to getting value from digital initiatives, and the practical lesson is that reporting trust is built upstream, long before anyone opens a dashboard.
If two reports disagree, do not start by asking which chart is wrong. Ask what each system believes the number means.
Why the disagreement is expensive
Conflicting numbers rarely cause a single dramatic failure. The cost accumulates quietly. Management meetings open with twenty minutes of reconciliation before any decision is discussed. Analysts spend the days before a board pack adjusting spreadsheets rather than analysing anything. Departments stop sharing reports because each one has to be defended, and leaders begin to make decisions on instinct because the evidence is contested.
The deeper cost is that disagreement erodes the authority of every number, including the correct ones. Once people learn that the dashboard "is never quite right", they ignore it even when it is.
Five common causes
Different definitions
"Customer", "active account", "revenue", "qualified lead" and "completed order" can mean different things across departments. A metric without a controlled definition is an argument waiting to happen. Sales may count a customer from the signed contract; finance from the first paid invoice; operations from the first delivery. Each definition is reasonable. The problem is that all three are published under the same label.
Different systems of record
Sales may trust the CRM while finance trusts the accounting platform. If ownership of the underlying data is unclear, both can be locally correct and operationally incompatible. This is the condition described in when your CRM knows something your finance system does not.
Different timing
One report may be real-time, another refreshed nightly and another manually exported on Friday. Apparent data-quality problems can actually be synchronisation problems. The UK government's Data Quality Framework treats timeliness as its own dimension of quality, describing it as the degree to which data reflects the period it represents and is up to date. Two accurate reports taken at different moments can still disagree.
Manual reconciliation
When people copy, clean and reshape data in spreadsheets, undocumented logic enters the reporting chain. That may be necessary temporarily, but it creates another transformation layer that needs ownership. A filter applied to remove test accounts, or a formula that excludes credit notes, becomes part of the definition of the number without ever being written down.
Bad capture at source
A dashboard cannot repair information that was never captured, captured inconsistently or stored in free text when structured data was required. The same framework lists consistency, completeness, uniqueness, validity and accuracy alongside timeliness, and notes that problems can enter at every stage of the data lifecycle, including through system changes causing inconsistencies and a lack of documentation. A duplicate customer created at the point of entry will be counted twice by every report downstream.
An illustrative example
The following scenario is illustrative and does not describe a specific organisation. A services business asks how many active customers it has. The CRM report counts accounts with an open opportunity or a contract marked "live". The finance report counts accounts invoiced in the past twelve months. The operations spreadsheet counts sites with a scheduled visit, so a customer with three sites appears three times. The CRM figure is also inflated by duplicates created when a web form and a salesperson each registered the same company.
None of the three teams is wrong about its own question. But the board was shown one number labelled "customers", and the following quarter it was shown a different one. The resulting conversation was about whose system was broken, when the real gap was that nobody owned the definition. That gap is explored further in when nobody owns the definition of a business metric.
Warning signs
- Management reports carry footnotes explaining why they differ from last month's figure in another report.
- The same metric name appears in several dashboards with no shared definition behind it.
- One person is the only one who knows how a key spreadsheet is "fixed" before it is circulated.
- Teams quote numbers from their own system rather than from a shared report.
- Questions about a figure are answered with "it depends which report you look at".
Trace the number backwards
Reliable reporting begins with lineage. For an important metric, identify its definition, source system, source fields, transformation rules, refresh timing, exclusions and owner. Then trace the number from the report back to the operational event that created it.
This exercise frequently reveals that the organisation does not have a dashboard problem. It has an operating-definition problem or a systems-architecture problem.
A practical diagnostic
Choose the three numbers that most often cause argument and, for each one, answer the following:
- What is the written definition, and who approved it?
- Which system is authoritative for the underlying facts?
- Which fields, filters and exclusions produce the figure?
- When is the data refreshed, and is that visible on the report?
- Where is the number touched manually between source and report?
- Which operational event creates the record, and who captures it?
- Who is accountable when the figure is challenged?
Where an answer is "nobody knows" or "it depends", the reporting problem has been located.
Do not create a "single source of truth" by slogan
Centralising data can help, but declaring one database the source of truth does not settle which business process owns each fact. Customer identity may originate in a CRM, invoice status in finance and fulfilment status in an operations platform. The architecture needs explicit authority by data domain, as set out in how to decide which system owns which data.
Reporting tools can support that discipline, but only if the organisation uses them deliberately. Microsoft's documentation on Power BI endorsement distinguishes content that any owner can promote from certified content, which only a select group of reviewers can mark as meeting the organisation's quality standards. The feature matters less than the principle: someone has to be accountable for declaring a dataset authoritative, and that decision needs criteria.
That distinction becomes more important as AI consumes operational information. Agents and automated workflows need governed, reusable data they can interpret and trust. If humans cannot reconcile a metric, an autonomous workflow inherits the ambiguity and acts on it at speed, a risk examined in why bad data becomes more dangerous when AI can take actions.
Trade-offs
Agreeing definitions has a cost. Some departments will lose a figure that flattered them, and some reports will change value overnight when a definition is corrected. It is often better to publish two clearly named metrics, such as "contracted customers" and "invoiced customers", than to force one definition that suits nobody. Not every number deserves this effort either; governance should concentrate on the figures used to run the business, allocate money or report externally.
What better looks like
Trusted reporting has controlled metric definitions, explicit systems of record, known refresh timing, visible transformation logic and named ownership. Exceptions are explainable rather than mysterious. Manual reconciliation is reduced or at least documented. When a figure changes, people can see why.
The goal is not perfect data everywhere. It is sufficient reliability around the information used to operate and make decisions.
When to act
Repeated meetings to reconcile numbers, spreadsheet adjustments before every management report, departments maintaining private definitions and executives hesitating to trust dashboards are signs that reporting has become an operational control issue. At that point, a better dashboard will not help; the definitions, ownership and data flows behind it need attention.
Digital Operations Improvement can address the workflow and ownership problems that create unreliable reporting. For cross-system data design, see Systems Implementation & Integration.
Sources and further reading
- The Government Data Quality Framework (last verified 10 October 2026)
- Promote and Certify Power BI Content with Endorsement - Power BI (last verified 10 October 2026)