Debugging in Power BI: The Complete Guide

TL;DR

80% of “bugs” are forgotten filters, not DAX errors
2-minute checklist: visual filters → page → report → slicers → bookmarks
If filters are fine: compare dashboard vs direct query vs source
The discrepancy is usually in ETL or definitions, not Power BI

The situation

You get a message from the client:

The dashboard numbers don’t match the system. We’re seeing 3,039 orders but the ERP shows 3,134.

Your first instinct: check the DAX measure.

Stop. Breathe. Don’t touch anything yet.

Part 1: The 80% rule

80% of the “bugs” reported to me aren’t bugs. They’re forgotten filters.

The 2-minute checklist

Before opening DAX Studio, before questioning your model:

1. Visual filters

Select the problematic visual. Filters pane. Is there something there that shouldn’t be?

2. Page filters

Check the page section in the filters pane. Did someone add a global filter to that page?

3. Report filters

At the very top of the filters pane. These affect EVERYTHING in the report. They’re the sneakiest because they’re not immediately visible.

4. Slicers

Are there slicers with active selections? Are there hidden slicers? Yes, they exist, and yes, people use them.

5. Bookmarks

Is the visual associated with a bookmark that has saved filters? Bookmarks can save filter state and activate it without you noticing.

Real case: The phantom filter

The chart doesn’t show 2024 data.

I check the measure. Perfect. I check the model. Correct. I check the page filters. I find:

Page filter:
Year is not 2024

Someone had added that filter for a demo and left it there. Five seconds of cleanup, one hour of debugging saved.

The rule: Spend 2 minutes checking filters before spending 2 hours checking DAX.

Part 2: Dashboard vs DB vs Source

If filters are fine, the next step is locating WHERE the problem is:

Dashboard	Database	Source System	The problem is in…
❌	❌	✅	ETL (data not getting from source to DB)
❌	✅	✅	Power BI (incorrect measure or model)
❌	❌	❌	Multiple places, good luck

Step 1: Direct query to the database

Replicate your measure’s logic in SQL and run it directly:

SELECT COUNT(DISTINCT order_id) as total
FROM orders
WHERE site = 'SITE_X'
  AND YEAR(date) = 2025
  AND status = 'COMPLETED'

Compare the result with what the dashboard shows.

Step 2: Interpret results

Typical example:

Dashboard showed: 3,039
Direct DB query: 3,089
ERP per client: 3,134

After refreshing the dashboard: 3,089 = DB. Zero difference between Power BI and the database.

The discrepancy wasn’t Power BI. It was missing records in the ERP-to-database sync.

Step 3: Investigate the gap

When analyzing the ERP data, it turned out there were records with null fields that the source system counted but semantically weren’t “completed orders.” They weren’t ETL errors—it was a definition difference.

Summary: The debugging flow

1. Are there active filters?
   → Yes → Check if they're correct
   → No ↓

2. Does Dashboard = Direct DB query?
   → Yes → Problem is in ETL or source
   → No → Problem is in Power BI (measure or model)

3. Does DB = Source System?
   → Yes → Definition difference or timing
   → No → Sync problem

The most common causes

80% of the discrepancies reported to you are NOT a Power BI problem. They’re:

Forgotten filters (80% of the 80%)
Data that hasn’t arrived at the DB yet
Different filters between the ERP and your query
Sync timing (client looks in real-time, you look at a snapshot)
Different definitions of what “counts” as completed

Before touching DAX, verify with the filter checklist and a direct query. You’ll save yourself hours of unnecessary debugging and avoid “fixing” something that wasn’t broken.

If it turns out the problem IS in your model, understanding how VertiPaq compresses your data might help identify if it’s a data model issue. And if you find weird filters that you don’t understand why they’re there, check out my post on documenting the why in Power Query—those filters exist for a reason someone forgot to document.