One Metric, Five Answers: Why Organisations Lose Trust in Their Own Reporting
Ask five departments to report the same number and, in most organisations, you will get five different answers. Not because anyone is careless, and not because the dashboard is broken — but because “revenue,” “active customer,” or “on-time delivery” has never actually been defined once, in one place, for everyone to use. This piece looks at why that happens, why buying another BI tool rarely fixes it, and what it actually takes to get an organisation back to a point where people trust the numbers in front of them.
The Meeting Every Data Leader Has Sat Through
It usually happens in a monthly performance review. Finance opens with a revenue figure. Three slides later, Sales presents a different one for the same period. Someone from Operations has a third number in a spreadsheet they built themselves, because neither of the other two “felt right.” The meeting stalls. Twenty minutes are spent reconciling numbers that should never have needed reconciling, and the actual discussion — what to do about performance — gets pushed to next week, if it happens at all.
This is not a rare, one-off failure. In our experience working with mid-market and enterprise clients across retail, financial services, and professional services, some version of this meeting happens every single month in a large proportion of organisations that consider themselves data-mature. They have a modern BI stack. They have skilled analysts. They still cannot agree on what “revenue” means.
The instinctive response is to blame the dashboard. Replace Tableau with Power BI. Consolidate onto one BI tool. Buy a more powerful platform. We have watched organisations spend six-figure sums doing exactly this, only to find themselves in the same meeting eighteen months later, with the same argument, on a different screen.
The dashboard was never the problem. It was just the place where the problem became visible.
The Real Cause Is Rarely the Tool
When we are brought in to diagnose a reporting trust problem, we almost never find a technology failure at the root. We find one or more of three things:
Unclear metric ownership. Nobody in the organisation is formally accountable for what “active customer” means. Finance calculates it one way for revenue recognition. Marketing calculates it another way for campaign attribution. Both are internally consistent. Neither knows the other exists.
Conflicting business definitions. Different teams have genuinely different — and genuinely valid — reasons to define the same word differently. The problem is not that the definitions differ. It is that nobody has agreed which definition applies when, and the differences are invisible until two numbers collide in the same meeting.
Duplicated transformation logic. The calculation for a metric has been written multiple times, in multiple places — a SQL query buried in a scheduled report, a DAX measure inside a Power BI model, a spreadsheet formula someone built three years ago and everyone still trusts. Each version was correct when it was written. None of them have been touched since, and they have quietly drifted apart.
None of these is a dashboard problem. All three are structural. And structural problems do not get fixed by swapping the visualisation layer.
Why the Same KPI Gets Calculated Five Different Ways
It helps to see this concretely. Here is what “monthly active customer” looked like at a mid-sized subscription retailer we worked with recently — five departments, five defensible answers, one number:
| Department | How They Defined “Active Customer” | Why It Made Sense to Them |
|---|---|---|
| Finance | Made a payment in the last 30 days | Ties directly to recognised revenue |
| Marketing | Opened an email or visited the site in the last 30 days | Measures engagement, not just spend |
| Customer Success | Has an open, non-cancelled subscription | Reflects contractual relationship, regardless of usage |
| Product | Logged in and used a core feature in the last 14 days | Measures genuine product engagement |
| Executive dashboard | An average of whichever figure was pulled most recently | No one had actually chosen a definition |
Every one of those definitions is reasonable on its own terms. Finance genuinely does need a revenue-linked view. Product genuinely does need a usage-linked view. The failure was not that these differences existed — differences like this are normal and, in some cases, necessary. The failure was that nobody had agreed which definition was authoritative for company-wide reporting, documented why the others existed as legitimate variants, or built the calculation logic so it lived in one place instead of five.
The result, in this case, was a board pack that reported active customer growth of 4% according to Finance and 11% according to Marketing in the same quarter. Both were “correct.” The business spent most of a board meeting arguing about which one to believe, instead of discussing what either number meant.
The Role of a Governed Semantic Layer
This is where the concept of a semantic layer earns its place — not as a product to buy, but as an architectural principle to adopt.
A semantic layer sits between your raw data and the tools people use to view it — Power BI, Tableau, Looker, a finance report, an AI assistant, whatever the front end happens to be. Instead of every tool calculating “revenue” or “active customer” independently, using its own logic, the calculation is defined once, in the semantic layer, and every tool downstream simply asks for it.
Practically, this means the SQL or DAX for “monthly active customer” is written and approved a single time. Power BI does not have its own version. The finance spreadsheet does not have its own version. The AI copilot answering an executive’s question pulls from the same governed definition. If the definition changes, it changes in one place, and every report downstream inherits the change automatically.
The value is not really about the calculation being “correct” in some abstract sense — reasonable people can and do disagree about the right definition. The value is that the disagreement gets resolved once, deliberately, and visibly, rather than being re-litigated informally every time two departments compare numbers.
Importantly, a semantic layer does not mean forcing every department onto a single number. It means making explicit which number is authoritative for which purpose, and ensuring that when Marketing needs its own engagement-based view of “active customer,” that variant is also defined once, documented, and traceable — not quietly rebuilt in a spreadsheet by whoever needed it this quarter.
Metrics Need Owners, Not Just Definitions
A definition without an owner decays. Someone writes it down, six months pass, the business changes, and nobody notices that the definition no longer matches how the business actually operates — because nobody was responsible for noticing.
The organisations that maintain trust in their reporting over time treat metrics the way a well-run product team treats a product: with a named owner, a change process, and an approval step before anything is altered.
In practice, that looks like:
A named owner per metric. Not “the data team” as a catch-all, but a specific person — typically someone who sits close to the business function the metric serves. Revenue might sit with a Finance lead. Active customers might sit with a Head of Customer Success. The owner is the person who can authoritatively answer “what does this mean and why,” and the person accountable when the metric stops reflecting reality.
A visible register of what exists. Every metric that appears on a board pack, a departmental dashboard, or a recurring report should exist in a single register — a name, a definition, an owner, and where the logic lives. This does not need to be a sophisticated data catalogue on day one. For many of our clients, this starts as a well-maintained spreadsheet. The value is in the discipline of maintaining it, not the sophistication of the tool.
An approval step before a metric changes. If Finance wants to change how “revenue” is calculated — say, to include a new product line — that change should go through the metric’s owner and be communicated to every team relying on it, before it goes live. Without this step, definitions drift silently, and by the time someone notices, three-quarters of reports have been quietly wrong.
This is a governance discipline, not a technology purchase. It costs almost nothing to start, and it is, in our experience, the single highest-leverage step an organisation can take toward trustworthy reporting.
Centralised Versus Decentralised: Choosing Where Logic Lives
Once ownership is clear, the next question is architectural: where does the actual calculation logic live, and who is allowed to touch it?
There are two common models, and most organisations land somewhere between them rather than choosing one purely.
Centralised reporting logic means all core metric calculations are built and maintained by a single team — often a central analytics engineering function — and every downstream report or dashboard consumes those pre-built metrics rather than calculating its own. This gives strong consistency and makes it easy to trace where a number came from. Its risk is speed: if every new metric request has to go through a central team, business units start finding workarounds, usually in the form of shadow spreadsheets that recreate exactly the fragmentation the centralised model was meant to prevent.
Decentralised reporting logic means individual teams build and own their own metrics, close to the business context they understand best. This is faster and more responsive to local needs, but without a shared layer underneath it, this is exactly the model that produces five different versions of “active customer.”
The organisations we see succeed generally adopt a hybrid: a small number of genuinely company-wide metrics — revenue, active customer, churn, the numbers that appear on a board pack — are centrally defined, owned, and governed through the semantic layer. Everything else is left to individual teams to define locally, with the freedom to build metrics that serve their specific context, provided those local metrics are clearly labelled as such and never presented as if they were the company-wide, board-level number.
The goal is not maximum centralisation. It is clarity about which handful of numbers must never be ambiguous, and confidence that everything else can flex without causing damage.
How to Introduce Metric Contracts
The most practical mechanism we have found for making all of this concrete is what we call a metric contract: a short, structured document — one per critical metric — that makes the definition, ownership, and logic explicit and impossible to quietly ignore.
A metric contract typically answers five questions:
| Field | What It Captures |
|---|---|
| Definition | The exact business meaning, in plain English, with no ambiguity |
| Calculation logic | Where the underlying SQL, DAX, or transformation lives — one canonical location |
| Owner | The named individual accountable for the metric’s accuracy and relevance |
| Approved consumers | Which reports, dashboards, and teams are authorised to use this metric |
| Change process | Who must approve a change, and how downstream consumers are notified |
For example, a metric contract for “Monthly Recurring Revenue” might state plainly that it is calculated as the sum of active subscription values as of the last day of the month, excluding one-off charges and pending cancellations; that the logic lives in a single dbt model or equivalent transformation layer; that the Finance Director owns the definition; that it feeds the board pack, the CFO dashboard, and the investor reporting pack; and that any proposed change requires sign-off from Finance and a two-week notice period to consuming teams before it goes live.
None of this requires new software. It requires discipline, a template, and a habit of writing the contract down before a metric is allowed to appear in a company-wide report. Many of our clients start with five to ten metric contracts — the numbers that actually appear in board packs — rather than attempting to formalise everything at once. The discipline compounds: once a handful of contracts exist and the arguments they prevent become visible, the practice tends to spread on its own.
Rebuilding Trust Without Replacing Every BI Tool
The organisations most anxious about this problem often assume the fix requires ripping out their existing BI investment and starting again. It rarely does.
A semantic layer, a metric ownership model, and a set of metric contracts can sit on top of almost any existing stack — Power BI, Tableau, Looker, or a combination of several, which is itself common in organisations that have grown through acquisition or simply adopted different tools in different departments over time. The point of this work is not to consolidate tools. It is to ensure that whichever tool someone opens, the number they see for “revenue” or “active customers” was calculated the same way, by the same logic, traced back to the same owner.
In practice, rebuilding trust tends to follow a consistent, low-drama sequence:
Start by identifying the five to ten metrics that actually appear in board packs and senior leadership reporting — not every metric in the business, just the ones where disagreement is expensive. Write a metric contract for each one. Assign an owner to each. Locate every place the calculation currently exists — every spreadsheet, every dashboard, every scheduled report — and consolidate the logic into a single, governed location that every tool then references. Retire the duplicates, one at a time, communicating clearly as each one goes.
This is deliberately incremental. We do not recommend attempting to govern every metric in the organisation at once — that stalls, because it tries to solve a political and organisational problem with a single technical project. Starting with the handful of numbers that actually cause boardroom arguments delivers visible value quickly, and gives the organisation a working template to extend at its own pace.
The Real Return on This Work
The organisations we have taken through this process do not describe the outcome in terms of technology. They describe it in terms of time. Board meetings that used to open with twenty minutes of reconciling conflicting numbers now open with the actual discussion. Finance and Operations stop having separate, quiet versions of the same KPI. New analysts spend their first weeks understanding the business, not reverse-engineering which of six versions of “revenue” is the real one.
That is the actual return on metric governance: not a more impressive dashboard, but a business that can trust the number in front of it, argue about what to do next, and move on.
If your organisation recognises the meeting described at the start of this piece — or has quietly stopped scheduling that discussion because everyone already knows how it ends — the underlying fix is very rarely a new BI tool. It is almost always a smaller, more deliberate piece of work: naming who owns each number, writing down what it actually means, and making sure it is calculated in exactly one place.
Be Data Solutions works with Heads of Data, CFOs, and operations leaders to design and implement exactly this kind of analytics engineering and reporting architecture — governed semantic layers, metric ownership models, and metric contracts that sit on top of the BI tools you already use, not instead of them. If your reporting has quietly stopped being trusted, we would be glad to help you understand why, and what it would take to fix it.
Explore Be Data Solutions’ analytics engineering and reporting services →
About Be Data Solutions: Be Data Solutions is a data engineering, software engineering, analytics, and ML & AI agency headquartered in London, with an engineering hub in Dhaka. ISO/IEC 27001 and ISO/IEC 42001 certified. We work with scale-ups, enterprises, and public sector organisations across retail, healthcare, media, manufacturing, and professional services.
