Why Two Dashboards Show Different Numbers

Two dashboards, one question, two answers. The cause is almost never a broken report. It is usually that a field has no declared owner, and two systems are both writing it — which means both reports are correct within their own model and the disagreement is structural.

There are four causes, they occur in a predictable order of frequency, and a record-level diagnostic finds the responsible one in about twenty minutes.

The four causes

1. The field has no declared owner

Two systems both hold account owner, both consider themselves authoritative, and they disagree. Neither is wrong. Until one system is declared the writer for that field and the other made a consumer, the disagreement recurs after every manual fix — and the manual fixes themselves start to look like the problem.

The observable symptom, if you look for it, is a field that will not stay set: someone corrects it, it syncs, the other system overwrites it, and it syncs back.

2. Filters differ, invisibly

One report excludes closed-lost; the other does not. One filters test accounts; the other counts them. Filtering logic that lives in a saved view rather than in the report is invisible at the point the number is read, which is exactly when it matters.

3. The date basis differs

Created date, close date, last modified date, and the date a record entered a stage are four different questions. Two reports using different bases will diverge permanently, and neither is incorrect — they are answering different questions that happen to have similar titles.

4. Duplicates counted asymmetrically

Where deduplication is partial, an account-level count and a contact-level count will not reconcile, and the gap widens with the duplicate rate.

Method: the record-level diagnostic

Aggregates hide the mechanism. The fastest route to the cause is one row.

1. Find one record that appears in one report and not the other, or that carries a different value in each. Any single record will do.

2. Compare the two report definitions field by field: object, filters, date basis, and any saved view either inherits from. Write both definitions down side by side — the difference is usually visible immediately once they are adjacent.

3. If the definitions match, inspect the record's field history. Identify which system wrote the disputed field last, and whether any other system also writes it.

4. Check for a duplicate of that record. If one exists, establish whether each report counts one or both.

5. Name the cause explicitly before fixing anything. Fixes applied without a diagnosis tend to resolve the symptom on one report and move it to another.

The fix that holds

A one-off reconciliation buys a quarter at best, because nothing about the system changed. What holds is a written record of which system owns which field.

Review this record whenever a new tool is added. That is the moment a second writer is usually introduced, and it is invisible at the time because the new tool works correctly in isolation.

Where this fails

Two situations do not resolve with field ownership. Where two teams genuinely need different definitions — marketing counting engaged contacts, finance counting billable accounts — the answer is two clearly named metrics rather than one contested one. And where the disagreement is about a derived figure rather than a stored field, the cause is in the calculation rather than the data, and the field-ownership record will not contain it.

Why this matters beyond tidiness

The organisational cost is not the reconciliation time. It is that unresolved numerical disputes get settled by seniority instead of by evidence, and once that becomes the norm, the reporting layer stops being consulted for decisions at all.