Why Your Dashboard Disagrees With Your Database

The meeting everyone has had

Two people present the same metric. The numbers differ by eleven percent. The next twenty minutes are spent reconciling rather than deciding, and the actual decision is deferred to a follow-up that may or may not happen.

The instinctive response is to distrust the dashboard. Usually the dashboard is reporting faithfully; it is reporting a different definition.

Where the divergence actually starts

In almost every case we investigate, the discrepancy traces to one of a small number of causes, none of which are visualisation bugs.

• Different filters. One view excludes internal accounts, cancelled orders or test records. The other does not.
• Different time boundaries. Booking date versus invoice date versus recognition date, or a timezone difference that moves transactions across a month end.
• Different grain. One counts orders, the other counts line items, and the ratio between them is not constant.
• Stale extracts. A cached copy refreshed at a different time from the source, so both are correct at different moments.
• Silent upstream change. A field's meaning changed at source, nothing downstream was told, and the historical series quietly stopped comparing like with like.

Why adding a dashboard never resolves it

The common response is to build one more view, described as authoritative. This adds a fourth number to the argument.

The problem is not that the business lacks a view. It is that the definition lives in several places at once (in a spreadsheet formula, in a report filter, in an application query, in someone's head) and each copy drifts independently. Any fix that does not consolidate the definition simply relocates the disagreement.

The fix: define once, serve everywhere

A governed metric layer holds each definition in one place, under version control, with a named owner who decides when it changes. Every consumer (dashboard, report, export, model, AI assistant) reads from that layer rather than reimplementing the logic.

Three properties make it work in practice:

• Ownership. A named person, not a committee, decides what revenue means.
• Version control. Definitions live in the repository with the rest of the code, so changes are reviewed and reversible.
• Lineage. When a number looks wrong, you can trace it to source in minutes rather than days.

Testing data the way you test code

Pipelines that are treated as software behave like software. That means automated tests that run on every load and stop the pipeline when they fail.

The tests are not exotic. Row counts within expected bounds, no nulls in keys, referential integrity between tables, no future-dated records, no duplicate primary keys. These catch the silent upstream schema change: the failure mode that otherwise surfaces months later in a board meeting.

Key takeaways

• Conflicting numbers are almost always a definition problem, not a visualisation one.
• Another dashboard adds a number to the argument rather than settling it.
• Define metrics once, with an owner, under version control.
• Lineage turns a multi-day investigation into a short one.
• Test data on every load, and stop the pipeline when a test fails.

Frequently asked questions

What is a single source of truth in data?

A single source of truth is one governed layer where each business metric is defined once and owned by a named person. Every dashboard, report and model reads from that definition rather than reimplementing it, so downstream consumers cannot drift apart.

Why do two reports show different revenue figures?

Usually because they apply different filters, use different date fields, or count at a different grain: orders versus line items, for example. Both can be computing correctly from the same database while answering subtly different questions.