Two departments, two revenues: definitions before dashboards

The monthly review opens with two slides. Sales reports one revenue figure for September; finance reports another, a few per cent lower. The next forty minutes go on reconciling them, the meeting ends without a decision, and somebody is asked to “build a single dashboard so this does not happen again”.
The dashboard gets built. It shows both numbers, side by side, in the company colours.
The real cause is not the tool
Both numbers are correct. Sales counts revenue when the contract is signed; finance counts it when it is invoiced, net of credit notes, in the period the service was delivered. Each department chose the definition that fits the decisions it makes, and neither was wrong to do so.
What is missing is not data and not software. It is an agreement about which definition answers which question, and somebody whose job it is to keep that agreement. No BI platform supplies that. A new one, bought to solve the problem, usually reproduces it faster and with better visuals.
How definition problems hide
The name is shared, the meaning is not. Customer, active user, order, margin — the words are in every report and mean something slightly different in each. Nobody notices until two reports end up on the same slide.
The logic lives where nobody reviews it. A filter in a spreadsheet, a join in a report somebody built three years ago, an exclusion in an export script. The definition exists; it is just scattered across tools and written by people who have since moved on to other things.
Reconciliation becomes a job. Somebody, usually in finance, spends days each month explaining why the numbers differ. That work is real, invisible on the org chart, and the first thing lost when that person leaves.
Dashboards multiply instead of converging. Every disagreement is solved with another report, so the number of versions grows. Ten dashboards showing “revenue” is not transparency. It is the same problem with more surface area.
AI inherits the ambiguity. Point a model or an agent at this data, ask about revenue, and it will pick one of the definitions — fluently, confidently and without telling you which. Undefined processes are the subject of the article on AI agents; undefined metrics are the same problem one level down.
What to do instead
Start with the ten numbers that drive decisions. Not a complete data dictionary; those become documents nobody maintains. The handful of metrics that appear in management meetings, budgets and bonus schemes.
Write each definition in one paragraph a manager can read. What is counted, what is excluded, at what moment, and from which system. If it cannot be written in plain language, it has not been agreed yet.
Give each metric one owner. One person who decides what the definition is and approves any change to it. Not a committee: committees produce compromises that serve no particular decision.
Allow more than one definition, under different names. “Booked revenue” and “recognised revenue” can both exist, as long as nobody calls either of them just “revenue”. A surprising number of disputes end the day the two numbers get two names.
Keep the definition in one place and compute it once. In whatever the company already has — a data warehouse, the semantic layer of the BI tool, even a single controlled spreadsheet at first. Every report reads from there instead of recalculating. Which technology does this is a secondary question, and we have no stake in the answer.
Change definitions on purpose. When one changes, write down when and why, and either restate the history or mark the break. A metric that silently changed meaning in April makes every year-on-year comparison quietly wrong.
None of this is glamorous, and it is usually a few weeks of work rather than a programme. It is also the part that decides whether anything built on top — dashboards, forecasts, AI — is believed. That is why data foundations sit among the six things VUCALE does, next to pilots and AI rather than after them.
A test you can run this week
Take the three numbers that appeared in your last management meeting. For each one, ask two people from different departments, separately, to write down in one sentence how it is calculated and which system it comes from.
Then compare the sentences.
If they match, you are in better shape than most, and the next step is writing them down where everyone can find them. If they do not, you have found the cheapest problem in your data estate to fix — and the one most likely to be undermining everything else. It costs an afternoon to discover, and no software demo will ever show it to you.
- data foundations
- BI
- metrics
- definitions