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

Companies often end up with multiple dashboards built from the same data source because different teams report around different business needs. Marketing dashboards may be designed to track campaign performance, lead generation, and ROI. Finance dashboards, on the other hand, might focus on revenue streams, expenses, and overall financial health.

Those different objectives can produce contrasting numbers even when both teams are working from the same underlying data. This can confuse stakeholders and lead to the wrong conclusions if definitions, filters, and timelines are not clear. Inconsistent numbers do not automatically mean there is an error. Sometimes both dashboards are right for the questions they are built to answer. At the same time, it is still possible that a true data or logic issue exists, so you don’t want to dismiss a mismatch without checking.

So, how do you respond to a stakeholder who asks why two dashboards show different numbers?

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

The question

A stakeholder asks:

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

This is a common analytics problem. Two teams can report different results. However, it doesn’t necessarily mean one is wrong and the other is right. They likely are measuring the same business using different definitions or timelines.

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:

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

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

I’m starting from scratch, so I first want to find tables that look like activity and tables that look like money. I start by scanning table names, then checking columns and a few rows to confirm what each table represents. Once I’ve identified the activity and money tables, I check the date ranges for each timeline before trying to reconcile anything.

Definitions and timelines

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

I want to know:

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

Dashboards often answer these differently, even when they use the same labels. Pagila 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 cause of mismatched dashboards, which is different timelines.

With those questions in mind, I start by listing tables and inspecting columns so I’m not guessing about which fields drive each timeline.

A simple place to start in SQL

I start by getting oriented with the dataset. First, I list tables, then I inspect columns for the most likely candidates.

-- What tables exist in public?
SELECT
  table_schema,
  table_name
FROM information_schema.tables
WHERE table_schema = 'public'
  AND table_type = 'BASE TABLE'
ORDER BY table_name;

-- What tables exist in public?
SELECT
  table_schema,
  table_name
FROM information_schema.tables
WHERE table_schema = 'public'
  AND table_type = 'BASE TABLE'
ORDER BY table_name;

-- What columns exist in the main tables?
SELECT
  table_name,
  ordinal_position,
  column_name,
  data_type
FROM information_schema.columns
WHERE table_schema = 'public'
  AND table_name IN ('customer', 'rental', 'payment', 'film', 'inventory')
ORDER BY table_name, ordinal_position;

-- What columns exist in the main tables?
SELECT
  table_name,
  ordinal_position,
  column_name,
  data_type
FROM information_schema.columns
WHERE table_schema = 'public'
  AND table_name IN ('customer', 'rental', 'payment', 'film', 'inventory')
ORDER BY table_name, ordinal_position;

Next, I want to know the date range for rentals and payments. If these timelines do not align, we should expect differences.

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;

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;

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 clocks

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;

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;

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 make the difference explicit.

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 evidence points to a timeline mismatch:

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: