Your dashboard is right. Your definitions are wrong.
Every disputed number in a management meeting traces back to a definition nobody wrote down. Here is the reconciliation test that settles the argument in a week instead of a quarter.
The most expensive sentence in an SME is "that is not what I get". It is expensive because it ends the meeting. The decision stalls, the analyst gets asked to re-check the numbers, and the next month the same conversation happens with a different page.
When we are called in after that conversation, the dashboard is almost never broken. Both figures are usually correct. The problem sits one layer underneath: two people are calculating two different things and both have been calling them gross margin.
The three definitions that disagree most often
- Gross margin: whether inbound freight sits in cost of goods sold or in overhead. This single choice can move a reported figure by two or three points, and most companies decide it per country.
- Revenue: order date, delivery date or invoice date. All three are defensible. Only one can be the number in the board pack.
- Customer count: anyone who has ever bought, anyone who bought in the last twelve months, or anyone with an open contract. A sales bonus usually depends on which one is published.
Each of those is a business decision, not a technical one. That is why a data team cannot settle it alone, and why the argument restarts whenever the person who made the call leaves.
The reconciliation test
Take one metric, the one that causes the most argument. Write its definition as a formula in plain language, in the form you would use to explain it to a new hire. Then test it against a closed period your finance team has already signed off.
Metric Gross margin, group, per market Definition (Net revenue - COGS - inbound freight) / Net revenue Grain Market x calendar month Owner Group CFO Source of record Finance system, account group 4000-6499 Test Reproduces FY25 audited group margin within 0.2pts Decision Pricing review, monthly
The test line is the whole point. If your definition cannot reproduce a number your auditor has already accepted, you do not have a definition, you have a preference. Most disputes end at this line, because one of the two competing definitions fails it and everyone can see that without it becoming a personal argument.
Why it has to be code, not a page in a wiki
A definition in a wiki drifts from the definition in the report within one quarter. There is no malicious intent involved, just a new page built by someone who did not know the wiki existed. The fix is to move the formula into the semantic layer so the report cannot express a different one.
- One function per metric, versioned, with the owner named in the file.
- A test that fails the build when a metric stops reconciling to the finance system.
- A changelog entry for every definition change, with the date and the reason.
- Row-level security applied on the same model, so the definition and the access rule travel together.
What this costs and what it saves
On an SME estate we usually spend five to ten working days before the first dashboard page is redesigned. That fortnight feels slow, and it is the cheapest part of the year. Every subsequent page inherits the arithmetic, so the marginal cost of the next dashboard drops sharply, and the arguments do not come back.
The alternative is what most companies do: build the dashboard, discover the disagreement at the review meeting, patch the report, and discover it again next quarter with a different pair of people.
If two reports disagree, one of them is not wrong. They are answering two questions that were never written down.
If this is your situation
The metric audit is five working days and produces the definition sheet, the reconciliation test and the gap list described above. It is scoped and quoted for your systems before we start, and if it turns out you do not need the rest, we will say so in writing.