One metric, one owner, one definition

The meeting that is really about data

Finance says revenue was one number. The commercial team says another. Half an hour goes on reconciling before anyone discusses the business. If that is familiar, you do not have a reporting problem. You have a definition problem.

Why the versions multiply

Nobody sets out to build four definitions of revenue. They appear because each team needed an answer before a shared one existed, and each made a reasonable local choice about refunds, intercompany sales or the date to use.

The logic then gets copied into dashboards, spreadsheets and a notebook, and the original reasoning is lost.

A semantic layer is an agreement, not a tool

The technology is the easy half. The work is getting people in a room to decide, once, what the metric means, and writing that decision somewhere the pipeline reads.

Each metric needs three things:

• A definition in plain language, not just SQL
• An owner by name, not by team
• One place it is calculated, referenced everywhere else

What changes afterwards

At one bank we defined forty metrics this way. The reporting cycle got faster, but the bigger change was that disagreements became specific: not “your number is wrong” but “this definition excludes intercompany and it should not”. That is a five-minute conversation.

Where to start

Pick the metric that causes the most arguments, not the easiest one. Getting the contentious definition agreed proves the process works on something that matters.