🎯 Situation

During a board meeting, a client's CFO presented revenue of $1.1M for the quarter. The sales director had a different number — $1.2M — in their deck. The CEO asked IT to pull the "real" number. IT came back with $1.15M.

Three different numbers. One company. One quarter. All three teams were confident they were right.

👉 They were all right — and that was exactly the problem. Each team was measuring revenue differently, pulling from different systems, applying different filters. No one was wrong. But no one agreed. And decisions were made in the gap between those numbers.

This is one of the most common and most damaging data problems in growing companies. And SQL is one of the cleanest ways to fix it.

⚠️ Challenge

When different teams calculate the same KPI independently, you don't get one wrong answer — you get several defensible answers. Each one has a logic. None of them match.

📈 Sales revenue ($1.2M)

  • Pulled from CRM: all deals marked "Closed Won"
  • Includes deals invoiced in Q1 but paid in Q2
  • Uses contract value, not payment received
  • Excludes refunds processed after month-end

📊 Finance revenue ($1.1M)

  • Pulled from ERP: invoices with payment confirmed
  • Cash received during the quarter only
  • Includes refunds and credit notes
  • Excludes revenue from deferred contracts

Neither definition is wrong. But they answer different questions. The problem isn't the data — it's the absence of an agreed definition stored in one place that every report pulls from.

🔍 How SQL Solves This

SQL views are the standard solution to this problem. A view is a saved query — a named calculation that lives in the database and can be referenced by any tool that connects to it.

Instead of every team writing their own version of "revenue" in their own spreadsheet or BI tool, you write it once in SQL, store it as a view, and every dashboard, every report, and every analyst uses that single definition:

CREATE VIEW vw_quarterly_revenue AS
SELECT
    DATE_TRUNC('quarter', invoice_date)  AS quarter,
    SUM(invoice_amount)                  AS gross_revenue,
    SUM(refund_amount)                   AS total_refunds,
    SUM(invoice_amount - refund_amount)  AS net_revenue
FROM invoices
WHERE payment_status = 'confirmed'
  AND invoice_date >= '2026-01-01'
GROUP BY DATE_TRUNC('quarter', invoice_date);

Now the definition is documented, versioned, and shared. Sales, finance, and IT all query vw_quarterly_revenue. If the definition needs to change — say, the business decides to switch from cash to accrual — you update it in one place. Every report updates automatically.

The view doesn't just fix the number — it forces the business conversation that should have happened first: what does "revenue" actually mean for us? Once that conversation happens and the answer is written in SQL, the argument stops.

✓️ Best Practice: A KPI Layer in SQL

The most robust approach is to build a dedicated KPI layer in your central database — a set of views or materialized tables that define every business metric in one place:

  • One view per KPI — vw_revenue, vw_churn_rate, vw_avg_order_value, vw_margin_by_product
  • Consistent naming — prefix all KPI views with vw_kpi_ so analysts know exactly where to look
  • Comments in the SQL — document the business definition directly in the query using -- comments: what's included, what's excluded, and why
  • Power BI connects to the views — not to raw tables. The BI layer stays clean; the logic lives in SQL

When a new analyst joins the team, they don't need to ask "how do we calculate churn?" — they read vw_kpi_churn_rate and the answer is right there, with the business logic documented inline.

💡 Summary

Different KPI numbers across teams isn't a data quality problem — it's a definition problem. The data is usually correct. The definitions just aren't aligned.

SQL fixes this by making the definition part of the infrastructure:

  • Write the KPI definition once — as a SQL view in your central database
  • Have the business conversation first — what exactly does "revenue" mean? Get everyone to agree before writing a single line of code
  • Connect every report to the view — Power BI, Excel, any tool that queries the database uses the same source
  • Version and document it — if the definition changes, update the view and document why

The board meeting argument about revenue isn't a technology problem. It's a governance problem that technology can enforce once the business has decided what the answer should be.

👉 When two people look at the same data and see different numbers, the problem isn't the data.

It's the absence of a shared definition. SQL is where you write that definition down.