Skip to content

Data

A shared language for your metrics: making "sales" mean the same thing everywhere

Sales and finance report different numbers for "sales" and nobody is wrong. When to write down what each metric means and the minimum every definition needs.

5 MIN READ

In the monthly review, the sales team presents one revenue figure and finance presents another. Nobody is lying and nobody has made a mistake: each side means something different by "sales" — confirmed orders, invoiced amounts, cash collected. The argument that follows isn't about the business, it's about vocabulary, and it comes back every month because it never gets settled properly. That's the decision this article is about: stop refereeing the same dispute over and over, and write down — once — what each metric that runs the company actually means. A metrics dictionary: what it is, what every entry needs, and how to build one without turning it into a project.

Two different numbers aren't always a data problem

When two systems hold different versions of the same record — a customer with two addresses, an order that exists in one place and not the other — the problem is unification: deciding which source wins and connecting the pieces. That case is real and serious. But there's a more common one, and far cheaper to fix: the data is the same, and correct, and the numbers still don't match — because each department applies a different definition to the same data.

"Margin" — before or after shipping costs? "Active customer" — inactive since when, exactly? "Sales" — with or without VAT, counted at order confirmation or at invoicing, net of returns or not? None of those questions can be answered by looking at the database. They are decisions about meaning, and until somebody makes them in writing, everybody makes them on their own. It isn't a technical problem: it's a language problem.

What a metrics dictionary is (and isn't)

A metrics dictionary is a short document, accessible to anyone in the company, with one entry per metric that's actually used to make decisions. Nothing more. It can live in a shared document; it needs no new tooling, no BI project, no consultants to get started.

It's worth being equally clear about what it isn't. It's not a procedures manual, nor a wiki of everything the company measures. It doesn't decide which system is right when sources disagree — that's unification work, and a glossary is no substitute for it. And it doesn't fix bad data: if a figure comes from incomplete records, defining it precisely only tells you precisely what's wrong.

The minimum entry: four fields

Every metric in the dictionary needs to answer four things. If one is missing, the entry is incomplete:

  • Definition. What it measures, in one or two plain sentences, explicitly including what's left out. "Sales: total invoiced in the period, excluding VAT, net of credit notes" says more than three paragraphs.
  • Formula. Exactly how it's calculated, with the awkward decisions in plain sight: what's included, what's excluded, how the edge cases are treated. If two people can't reach the same number by following the formula, it isn't a formula.
  • Source. Which system and which field the number comes from. If it could come from several places, which one wins for this metric — even while the broader unification work stays pending.
  • Owner. One person — not a committee — who answers for the definition and settles disputes. When a case comes up that the entry doesn't cover, someone has to decide quickly and update it.

Where to start without launching a project

Don't inventory every metric in the company: most of them don't deserve it. Start with the ones that have already caused an argument — those have proven demand — and the ones that appear in leadership meetings. A handful of well-written entries clears most of the noise.

The hard part isn't writing the entries: it's deciding. And there's a trap worth knowing about. When two departments defend different definitions of the same metric, it's almost never because one of them is wrong — it's because each needs to measure something different. Sales needs to know what's been sold; finance, what's been invoiced; treasury, what's been collected. The fix is usually not to crown one definition and defeat the rest, but to give them different names. "Confirmed orders" and "invoiced sales" can sit in the same report without conflict. What can't coexist are two meanings behind the same word.

How it stays alive (and how it dies)

A dictionary dies in one of three ways: it lives where nobody looks, nobody owns it, or it turns into bureaucracy and you need sign-off just to propose a metric. Any of the three quietly reduces it to a decorative document.

It stays alive through small habits: reports cite the definition they use (or link to the entry); new metrics are born with an entry or not born at all; and when two figures clash in a meeting, the first question is no longer "who's right?" but "are we using the same entry?". The day that question comes up on its own, the dictionary is doing its job.

Three questions before arguing about a number

Next time two figures don't match in a meeting, before looking for someone to blame:

  1. Are we using the same definition, or does each number answer a different question?
  2. Do they come from the same source, calculated with the same formula?
  3. Who settles it if we still disagree?

If the answer to the first two is yes and the numbers still don't match, the problem is no longer vocabulary — it's data or systems, and the dictionary has done its work by showing you where to look. That's the kind of thread a data & systems assessment pulls on. But many companies find that, with definitions in order, half of their "data problems" were language problems all along.

After reading

Does this sound like your case?

If this describes something sitting on your desk, tell us about it. We'll come back with a first read before proposing anything.

Tell us about your case

A first 30-minute call with direct senior interlocution — no commitment and no sales pitch.