Skip to content
DWKD
Lesson · The full series

Why two dashboards disagree

You will learn

Nobody is lying. Four ordinary causes account for nearly every mismatch, and knowing them turns a two-week investigation into a ten-minute conversation.

Beginner 20 min Data
Make the numbers hold up Lesson 1 of 5
Two printed dashboard reports side by side on a dark desk, a pen resting where one figure has been circled.

Finance says revenue was $2.4M. The sales dashboard says $2.6M. Everyone assumes someone is wrong, and two weeks disappear.

Almost nobody is wrong. Both queries usually return a correct answer to a question that was never written down, and the two questions differ by a word nobody said out loud. Almost every mismatch traces to one of four causes. Check them in this order; that is roughly how often each turns out to be the answer.

Different clocks

The most common cause by a wide margin. One report counts by order date, the other by ship date, invoice date, or payment date. A single transaction carries four or five dates and each is defensible as “when it happened.”

Timezones double it. A deal closed at 6pm Pacific on March 31 lands in Q1 for one system and Q2 for the other, because one stores local time and the other stores UTC. It only shows at period boundaries, which is exactly where numbers get reported.

Then the calendar itself. A finance system on a 4-4-5 fiscal calendar and a dashboard grouping by calendar month will disagree every month, forever. Weeks are worse: one tool starts the week on Sunday, another on Monday, and the chart shifts by a day of volume nobody can locate.

Ask: which date column is this filtered on, in which timezone, and on whose calendar? That resolves the disagreement more often than everything else combined.

Different populations

One report excludes internal test accounts. The other excludes canceled orders. A third excludes both but includes refunds as negative amounts rather than removing the original order. None of these are wrong; they are answering slightly different questions.

The exclusions you will not think to ask about are the ones applied somewhere other than the query. Row-level security means two people running the same dashboard see different totals, correctly, because one of them cannot see one region. A filter saved into the dashboard months ago, collapsed and still applied, is invisible to anyone reading the SQL. Currency is a population question too: a report summing a raw amount column adds dollars to euros.

Ask: what rows are excluded, and where is that written down? If the answer is “it’s in the query,” the filter exists but the definition does not. A definition living only in SQL gets copied into the next dashboard by someone who does not know why it is there.

That is the opening. The rest of the lesson — the remaining sections, the exercise and the check-your-understanding questions — is behind the gate below.

This lesson requires full access.

Create an account to explore the published free lessons. This lesson requires full access; signing up does not purchase access or enroll you in Academy.