Finance says last month closed at 412k. The dashboard on the office screen says 398k. Both were built by people who know what they're doing, and now the Monday meeting is a debate about arithmetic instead of a decision about the business.
This is the most common data problem we get called about, It is almost never a broken query. Dashboards showing different numbers usually means two teams answered two slightly different questions, then gave the answers the same name.
Nobody is wrong. You're asking two different questions
"Revenue" sounds like one thing. In a typical company it's at least four: gross bookings, revenue net of refunds, revenue recognised in the period, and cash actually received. Finance answers the third. The sales dashboard usually answers the first. Both are defensible; neither is the other.
That same fracture runs through every metric a business argues about. An "active customer" might mean anyone who logged in, anyone who bought in the last ninety days, or anyone with a live subscription. A "lead" might include the form fills your team disqualifies in ten seconds. Pick one and someone else is quietly working from another.
So the first move is not to open the query. It's to ask each side to say out loud what they think they're counting. Half the time the gap closes right there, and the remaining half you now know precisely what you're reconciling.
Why two dashboards show different numbers
When definitions genuinely match and the figures still diverge, it's nearly always one of five things.
Timezone. One tool buckets by UTC, the other by the office's local time. Every day is shifted by a few hours of orders. That mostly cancels out, until you look at a single day or a month boundary and it doesn't.
Refresh timing. The warehouse job runs at 4am. The CRM dashboard is live. At 10am they cannot agree, and by the next morning they do, which is why this one survives so long undiagnosed.
A filter someone saved. Somebody excluded test accounts in one dashboard three years ago and never wrote it down. This is the single most common cause we find. It never shows up in the SQL you're staring at, because it lives in the tool's UI.
Late-arriving and edited rows. A refund posted today against an order from last month changes last month's total. If one system snapshots and the other recomputes, they drift apart permanently.
Deleted or merged records. Two CRM contacts get merged, and the deal count drops by one everywhere except in the export somebody already downloaded.
All five have the same root. The calculation exists in more than one place, so it can drift in more than one place.
Write the definition down before you touch the tooling
Whatever holds up over time is boring. For each metric that matters, write one paragraph that a non-technical person could check:
- The plain-English question it answers.
- The source table or system it comes from.
- The exact filters, including the exclusions someone would otherwise apply silently.
- The date field it buckets on, and the timezone.
- Who is allowed to change this definition.
Ten metrics usually covers most of the arguments a company actually has. Do those ten and stop. A comprehensive metric dictionary nobody maintains is worse than five definitions that are true.
Then encode them once. In practice that means the calculation lives in your warehouse, in a modelled table or a semantic layer that every tool reads from, rather than being rewritten in each dashboard by whoever built it. That's most of what our data engineering work actually is: agreeing the definitions, then making them the only path to the number.
Give every number an owner
Definitions decay when no one is responsible for them. In dbt Labs' 2026 State of Analytics Engineering Report, 41% of data professionals named ambiguous data ownership as a persistent obstacle. That's a governance problem, not a tooling one.
Ownership here is a small commitment, not a job title. One named person per metric, who approves changes to the definition and gets asked first when the number looks odd.
If a metric can't be given an owner, that tells you something. It probably isn't driving a decision, and it can come off the dashboard.
Reconcile once, in public
When two numbers disagree, resist the urge to fix them in a DM. Build a reconciliation that lives somewhere the team can see: start from the higher figure, subtract each difference as its own line, and land on the lower one.
Gross bookings 412k. Less refunds, 9k. Less test accounts still in the CRM, 3k. Less two December deals recognised in January, 2k. Net revenue, 398k.
Two things happen when you do this. The disagreement stops being a matter of trust and becomes a list of four line items, each with an owner. And each line usually points at something worth fixing anyway. Those test accounts should have been excluded upstream, not in a dashboard filter.
Keep that reconciliation as a saved query and re-run it monthly. When a new line appears, something changed upstream, and you've found it before it reaches a board pack. That's the same instinct behind building pipelines that don't break at 3am: catch the discrepancy at the source, not in the meeting.
This gets more expensive when AI reads the same tables
An analyst who sees an odd number pauses and checks with a colleague. An agent querying your warehouse does not. It picks whichever table matches the column name and reports the figure with complete confidence.
The same dbt Labs survey found that 71% of data professionals are concerned about incorrect or hallucinated outputs reaching stakeholders. Trust in data as an organisational priority jumped from 66% to 83% year over year, the steepest rise of any objective they measured. That shift is what happens when companies start pointing language models at warehouses where "revenue" still means four different things.
If you're planning anything agentic on top of your data, and most of the businesses we talk to are, the metric definitions are not a tidy-up task for afterwards. They're the input.
Do this tomorrow
Take the number that caused the last disagreement. Ask each person who reports it to write, in one sentence, what they think it counts and which filters they apply. Put the sentences side by side.
You'll either find the gap in fifteen minutes, or you'll find that nobody can state the definition without opening a dashboard to check. Same finding. More urgent.
