Six Reports, Six Different Revenue Numbers

The giveaway is always the same. Half a dozen reports, all technically live, none of them agreeing with each other, and a Teams channel full of people asking which number is right this week.

Somebody eventually builds a seventh report to settle it. That never works. You end up with seven.

The instinct is to treat this as a Power BI problem, because Power BI is where you can see it happening. It almost never is. It is an ownership problem a few layers down, and it is fixable in an afternoon of unglamorous work, which is probably why nobody does it.

The short version: when several reports disagree about the same figure, the cause is that the figure has never been defined in one place. Each report carries its own version of the logic, built by a different person at a different time from a different brief, and all of them are internally consistent. To find out which one is right, write the definition down first, then trace each report back to source and see which one matches the definition. Then move the winning logic into one shared semantic model and delete the rest.

Start with the definition, not the reports

The temptation is to open all six files and start comparing DAX. Do not. You will find six differences and no way to judge any of them, because you have no standard to judge against.

Instead, get the people who use the number in a room and write down what it means, in a sentence, in English. Revenue is a good one to practise on, because everybody assumes it is obvious and nobody agrees.

Does revenue include intercompany sales? Does it include freight and carriage recharged to the customer? Is it net of credit notes, and if so, credit notes in the period they were raised or the period of the invoice they relate to? Does it include unposted invoices? Is it before or after settlement discount? Which company, in a group?

Six questions. Two to the power of six is sixty four possible definitions, and you have six reports. Frankly the odds were never good.

Write the answer down. One paragraph. Get somebody senior enough to be annoying about it to agree to it. That paragraph is now the standard, and it is the single most valuable artefact of the whole exercise, because everything else can be rebuilt from it.

Then trace each report to source

Now open the reports, one at a time, and answer the same six questions from what the report actually does rather than what it is called. Not what the developer intended. What the code does.

Put it in a table, which is dull and works:

Those are illustrative rows, but that is the shape it comes out in every time. And look at what the table does to the conversation. Nobody is wrong any more. The board pack is not a broken sales dashboard, it is a different question, correctly answered. The argument stops being about competence and becomes a decision about scope, and decisions about scope are ones a business is quite good at making.

Usually one report matches the agreed definition, sometimes none of them do, and occasionally the one everybody distrusted turns out to be the accurate one. That last case is my favourite and the most awkward to deliver.

The reason it happened, so it stops happening

Six reports containing six copies of the same logic is not carelessness. It is the natural end state of a perfectly reasonable process repeated over four years.

Someone needs a report. The person who can build it builds it, from whatever is nearest, under time pressure, with a definition that lives in their head and in a Teams message that has since scrolled away. They do a good job. They leave, or move team, or simply move on to the next thing. Then it happens again, four times, and none of those four people ever had a reason to talk to each other.

Which is why building a seventh report does not fix it. It adds a seventh definition and a seventh person who will eventually leave.

The fix is that the definition stops living in reports. It lives in one shared semantic model, once, and every report reads it from there. That is the whole job of the semantic model, and it is the part of Power BI nobody wants to do and everybody pays for skipping. Get it right and the measures write themselves. Get it wrong and you are firefighting DAX for the life of the report.

Alongside it, somebody has to own the definition. Not the report. The definition. One named person who gets asked before revenue means something new. Without that, you have simply moved the sprawl into one file and bought yourself two quiet years.

What this looks like when it is working

You know it has landed when the meeting changes shape. People stop opening with "is this number right" and start opening with "why did this number move". The second question is the one that makes money.

There is also a plainer test. Ask three people in three different teams what revenue means and see whether you get the same sentence back. If you do, your model is doing its job. If you get three sentences, you already know which project comes next, and it is not a new dashboard.

Where to start if this is you

Pick one number. The one that gets argued about most, which is usually revenue, margin or headcount. Do the definition paragraph, do the table, and see how far six reports have drifted apart. It takes an afternoon and it will tell you more about the state of your reporting than any tool will.

If you want the same exercise run across the whole estate rather than one figure, the Report Trust Checklist is free and covers twelve checks you can score yourself, and the Power BI Health Check is the paid version of the same instinct: six areas scored, the issues ranked, and a roadmap you can hand to a developer.

Either way, write the definition down first. Everything else is easier afterwards.