𝗔 𝘁𝗶𝗻𝘆 𝘀𝘁𝗼𝗿𝘆
A stakeholder messaged me at 10:17 AM.
"Power BI is showing the wrong number again."
I opened the report.
Checked the measure.
Checked the relationships.
Checked the DAX.
Nothing.
So I rewrote the measure.
Still nothing.
Then I asked:
"What number are you expecting?"
He sent me an Excel file.
That was the moment I realised I had been debugging the wrong problem.
𝗧𝗵𝗲 𝗾𝘂𝗲𝘀𝘁𝗶𝗼𝗻 𝗴𝗮𝗽
The problem wasn't Power BI.
It was a mismatch between the dashboard definition and the stakeholder's definition.
I call this the question gap.
Analysts often hear "the number is wrong" and immediately start fixing the calculation.
But "wrong" usually means "different from what I expected."
Those are not the same thing.
𝗪𝗵𝘆 𝗶𝘁 𝗸𝗲𝗲𝗽𝘀 𝗵𝗮𝗽𝗽𝗲𝗻𝗶𝗻𝗴
We are trained to solve technical problems.
So when someone questions a number, we open DAX.
The stakeholder is usually thinking about the business definition.
We are thinking about the formula.
Both people can be completely reasonable.
And still disagree for 45 minutes.
𝗧𝗵𝗲 𝗳𝗿𝗮𝗺𝗲𝘄𝗼𝗿𝗸
𝘙𝘶𝘭𝘦 1: 𝘈𝘴𝘬 𝘧𝘰𝘳 𝘵𝘩𝘦 𝘦𝘹𝘱𝘦𝘤𝘵𝘦𝘥 𝘯𝘶𝘮𝘣𝘦𝘳
"Which exact number were you expecting, and where did it come from?"
Before, I would start debugging immediately.
After, I had a reference point.
Sometimes the difference is obvious in two minutes.
Sometimes the Excel number is wrong.
Either way, you know what you're actually investigating.
𝘙𝘶𝘭𝘦 2: 𝘋𝘦𝘧𝘪𝘯𝘦 𝘵𝘩𝘦 𝘮𝘦𝘵𝘳𝘪𝘤
"How exactly are you defining this metric?"
Don't accept "revenue" as a definition.
Ask whether it's gross revenue, net revenue, invoiced revenue, recognised revenue, or something else.
One word can hide five calculations.
𝘙𝘶𝘭𝘦 3: 𝘊𝘰𝘮𝘱𝘢𝘳𝘦 𝘢𝘵 𝘵𝘩𝘦 𝘴𝘢𝘮𝘦 𝘭𝘦𝘷𝘦𝘭
"Are we comparing the same date range, filters, grain, and exclusions?"
A monthly total in Power BI won't necessarily match an Excel total built from transaction rows.
Check the grain.
Check the dates.
Check the filters.
Then compare.
𝘙𝘶𝘭𝘦 4: 𝘊𝘩𝘢𝘯𝘨𝘦 𝘋𝘈𝘟 𝘭𝘢𝘴𝘵
"Only modify the DAX after validating the business definition, filters, and source data."
This rule saved me the most time.
Before, every complaint became a coding session.
After, DAX became the fourth step instead of the first.
Sometimes the measure needs fixing.
Sometimes your understanding does.
𝗢𝗻𝗲 𝘄𝗮𝗿𝗻𝗶𝗻𝗴
Don't use this framework as an excuse to avoid technical debugging.
If the definition is clear and the filters match, investigate the model.
Fix: validate the business question quickly, then move on.
𝗙𝗼𝘂𝗿 𝗮𝗰𝘁𝗶𝗼𝗻𝘀 𝘁𝗵𝗶𝘀 𝘄𝗲𝗲𝗸
✅ Before changing a Power BI measure, ask where the expected number came from.
✅ Write down the business definition of your three most important KPIs.
✅ Compare one disputed number using the same date range, grain, and filters.
✅ Track how often a "DAX problem" turns out to be a definition problem.
𝗖𝗹𝗼𝘀𝗶𝗻𝗴
I eventually found the issue.
The dashboard wasn't broken.
My assumption was.
That Excel file saved me from another hour of unnecessary DAX surgery.
The best Power BI analysts don't just know how to fix numbers.
They know when the number was never the real problem.
Before you debug the calculation,
debug the question.
𝗥𝗲𝗽𝗹𝘆 𝘄𝗶𝘁𝗵 𝗼𝗻𝗲 𝘄𝗼𝗿𝗱:
DAX if you keep debugging measures first.
DEFINITIONS if KPI arguments happen often.
POWERBI if you want more practical Power BI lessons.
I reply to every single one.
