Why Two Dashboards Show Different Revenue Numbers
(Debugging with SQL)

The question

A stakeholder asks:

“Why does the Finance dashboard show $0 revenue in August while the Marketing dashboard shows strong performance?”

At first glance, this looks alarming. If revenue is zero, then something must be broken. This is a common analytics problem. Two teams can report different results, but it doesn’t necessarily mean either one is wrong. They likely are measuring the same business using different definitions or timelines.

In this post, I’ll walk through how I’d debug the mismatch with SQL using a sample database (Pagila).

What we actually know

At the beginning, we only know:

  • Two dashboards show different revenue numbers
  • Finance shows $0 revenue for August
  • Marketing suggests activity in August is strong

Before writing any complex queries, I want to confirm three basic facts about the dataset:

  1. What tables exist
  2. Which tables contain revenue signals (orders, payments, amounts, etc.)
  3. What date range the data covers

If the dataset doesn’t include August payments, then Finance showing $0 could be expected.

Definitions and timelines

When two metrics don’t match, the issue usually is not the query, but the definition and/or timeline. This is the first thing I’d want to check.

I’d ask:

  • How does each team define “revenue” (e.g., gross vs net, cash vs accrued, etc.)?
  • Are refunds included?
  • Is revenue recorded at order time or payment time?
  • What filters are applied (e.g., completed only, excluding certain customer types, etc.)?

Dashboards often answer these differently, even when they use similar labels. The Pagila dataset does not include “refunds” and “orders” the way a modern e-commerce dataset would, but it does include “rentals” and “payments.” This gives us a clean way to illustrate a common issue, which is different timelines.

A simple place to start in SQL

I start by creating basic versions of the metrics to understand the data better.

First, I want to know the date range for rentals and payments. If these timelines do not align, a mismatch will occur.


SELECT
  MIN(rental_date) AS min_rental,
  MAX(rental_date) AS max_rental
FROM public.rental;

SELECT
  MIN(payment_date) AS min_payment,
  MAX(payment_date) AS max_payment
FROM public.payment;

From this, I see that:

  • Rental dates range from February 12, 2022 to August 23, 2022
  • Payment dates range from January 23, 2022 to July 27, 2022

This implies that rentals exist in August, but payments do not. So, if one dashboard groups by rental_date and the other groups by payment_date, then August will look very different.

Next, I want to check the payment months and amounts recorded for each.


SELECT
  DATE_TRUNC('month', p.payment_date)::date AS month,
  SUM(p.amount) AS revenue
FROM public.payment p
GROUP BY 1
ORDER BY 1;

This returns payments from January to July 2022. There is no payment data for August. This doesn’t mean the business didn’t earn money in August. It simply means no payments were recorded this month. We need to investigate further to understand why.

Now I look for common sources of mismatch

With date ranges confirmed, I move on to the common causes of mismatch.

1. Different data logic

Marketing dashboards often report based on activity (rental). Whereas finance dashboards often report based on when cash was received (payment). One dashboard might group by rental_date. The other might group by payment_date. This alone can shift revenue across months.

So, I build two versions of “monthly revenue.”

  • Marketing dashboard based on rental activity
  • Finance dashboard based on payment activity

Here is the side-by-side comparison:


WITH marketing_view AS (
  SELECT
    DATE_TRUNC('month', r.rental_date)::date AS month,
    SUM(p.amount) AS revenue_assigned_to_rental_month
  FROM public.payment p
  JOIN public.rental r ON r.rental_id = p.rental_id
  GROUP BY 1
),
finance_view AS (
  SELECT
    DATE_TRUNC('month', p.payment_date)::date AS month,
    SUM(p.amount) AS revenue_by_payment_month
  FROM public.payment p
  GROUP BY 1
)
SELECT
  COALESCE(m.month, f.month) AS month,
  COALESCE(m.revenue_assigned_to_rental_month, 0) AS marketing_revenue,
  COALESCE(f.revenue_by_payment_month, 0) AS finance_revenue,
  COALESCE(m.revenue_assigned_to_rental_month, 0) - COALESCE(f.revenue_by_payment_month, 0) AS difference
FROM marketing_view m
FULL OUTER JOIN finance_view f
  ON f.month = m.month
ORDER BY month;

This replicates the exact two dashboard views:

  • Marketing’s view reflects a large number in August
  • Finance’s view shows $0 in August

This is the gap we are trying to explain.

2. Why didn’t Finance record revenue in August?

If Marketing shows a big August and Finance shows zero, when are the payments recorded?


SELECT
  DATE_TRUNC('month', r.rental_date)::date  AS rental_month,
  DATE_TRUNC('month', p.payment_date)::date AS payment_month,
  SUM(p.amount) AS dollars
FROM public.payment p
JOIN public.rental r ON r.rental_id = p.rental_id
WHERE DATE_TRUNC('month', r.rental_date)::date = '2022-08-01'
GROUP BY 1,2
ORDER BY 3 DESC;

This returns something surprising, but useful for this walkthrough.

Payments for August rentals were recorded in the months from January to July. This means that Marketing recognizes those payments in August, while Finance has already accounted for them earlier.

So, Finance is not missing money in August. It’s using a different calendar.

3. Filters that look harmless, but aren’t

In a real company dataset, the next layer of debugging would usually include:

  • Filters (status, test accounts, exclusions)
  • Join paths (which tables are used)
  • Net vs gross logic (refunds, chargebacks)

Pagila doesn’t directly reflect all these realities, but the process remains the same. Make the logic clear and verify the data structure before relying on any dashboard.

What I’m trying to answer

At this point, I am not trying to decide who is “wrong.”

I’m trying to answer:

  • Are these dashboards measuring the same thing?
  • If not, how exactly do they differ?
  • Are they using the same timestamp?
  • Which definition matches the business question being asked?

In this case:

  • The rental timeline continues in August
  • The payment timeline ends in July
  • August rentals are recorded as paid in earlier months

If two dashboards have different date fields, they will not align.

The likely outcome

In real business settings, this pattern shows up in several common ways:

  • One dashboard groups by activity date, another by billing date
  • Revenue is posted at invoice time, not usage time
  • Refunds and adjustments are posted in different periods
  • Filters and exclusions differ across reports

The key point is consistent. Two dashboards both can be internally correct and still disagree because they are measuring different things on different timelines.

The takeaway

When metrics don’t match:

  • Don’t assume a bad query
  • Start by confirming definitions and timelines
  • Use SQL to make differences visible
  • Decide which definition best answers the business question

Good analytics isn’t about finding the number. It’s about understanding which number answers the question.

Full walkthrough on GitHub

If you want to follow along exactly, I’ve published the full SQL walkthrough on GitHub, including:

  • Dataset checks
  • Marketing queries
  • Finance queries
  • Reconciliation comparison and drill-downs

You can find it here: sql-reconcile-two-dashboards

Upcoming posts

  • How I’d Answer, “Why Did Churn Increase?”
  • A Hiring Manager Asks for “Top Customers”
  • Cleaning a Broken CSV Export with Python

If you want more walkthroughs like this, you can subscribe below.

Get practical SQL & Python examples by email

No spam. Unsubscribe anytime.