Sales, Product, and Finance Use the Same Metric Name for Different Things
Sales, Product, and Finance Use the Same Metric Name for Different Things
Three people send you three numbers for the same label. Sales says five. Product says three. Finance says three. The slide has one slot, and the deck goes out Thursday.
None of these numbers is necessarily wrong. That is the part that makes the situation hard. If one team had simply mis-keyed a join, you could find the bad row and move on. More often the label — "active account," "customer," "user," "revenue" — is doing three different jobs, and the three figures are the honest output of three different questions that nobody wrote down.
So the order matters. Compare definitions and source records before you choose a number. Then rename them, select one, or hold the figure until the records support it. What you should not do is average three incompatible quantities into a fourth number that belongs to no population, or quietly adopt whichever definition produces the strongest story.
Get each owner's definition before comparing totals
Before any number moves, ask each function five questions about its own figure: what unit is counted, what event qualifies it, over what period, what is excluded, and which record supports it. Get the answers from the person who owns the definition, not only from the person who built the dashboard. Those are frequently different people, and when they disagree with each other you have found your first real finding.
The unit question does most of the work. An account, a contract, a user, a workspace, a transaction, and an invoice are not variations on a theme. A company with three workspaces and one signed agreement can contribute three to one count and one to another, with no error anywhere. A single invoice can cover four quarters of service, or one, depending on how the contract was written.
Ask for the definition as it is actually used, not as it should ideally read. If product's query includes trial workspaces, write that down before you decide whether it ought to. Normalizing the definitions in your notes — smoothing out the awkward boundary, dropping the exclusion you find embarrassing — destroys the only evidence you have. You will end up comparing three tidy descriptions and wondering why reconciliation still fails.
Here is the distinction worth holding onto through the rest of this work: a discrepancy can come from meaning, from timing, from identity matching, or from a genuine data error. A dashboard title identifies none of those. Four causes, one symptom, and the remedies are different.
Follow the differences into a small eligible record set
The record set below is invented for this exercise. It is not drawn from a company, and no query was run against it. What it is meant to show is the shape of the problem at a scale you can check by hand.
Three systems hold three different keys. Sales keeps contracts, keyed to a legal entity:
- Alder Freight — signed 2026-02-04
- Brindle Works — signed 2026-01-12
- Cairn Optics — signed 2026-03-05
- Dunlin Health — signed 2025-11-14
- Eastgate Supply — signed 2026-02-27
- Fenwick Research LLC — signed 2026-01-30
Product keeps workflow events, keyed to a workspace. The qualifying event is "published a report":
- Alder Freight — 2026-02-19
- Brindle Works — 2026-01-27
- Dunlin Health — 2026-02-11
- Eastgate Supply — 2026-01-15, workspace created 2026-01-09, converted to paid 2026-02-27
- workspace "fenwick" — 2026-02-08 and 2026-03-14, not linked to any contract record
Finance keeps payments, keyed to a billing entity:
- Alder Freight — invoice 1041, paid 2026-03-02
- Cairn Optics — invoice 1052, paid 2026-03-21
- Dunlin Health — invoice 0998 (renewal), paid 2026-02-28
- Fenwick Labs Ltd. — invoice 1067, paid 2026-03-18
- Brindle Works — invoice 1071 sent 2026-04-02, unpaid as of March 31
Now map each account into each measure under its stated rule.
Sales counts five. Every account that signed during the quarter: Alder, Brindle, Cairn, Eastgate, Fenwick Research LLC. Dunlin signed in November and drops out. This is a clean definition applied cleanly. Its number is small only because the period is short.
Product counts three with confidence. Alder, Brindle, and Dunlin each had a publish event in the quarter and can be matched to a contract. Two further events cannot be placed yet. Eastgate's published report came on 2026-01-15, six weeks before the contract was signed, from a workspace that was still a trial — whether the account's history begins at conversion or at the trial is a boundary decision product has to make, and the answer moves the count to four. The "fenwick" workspace has events in February and March that belong to some entity, and the accounts table does not say which.
Finance counts three with confidence. Alder, Cairn, and Dunlin paid within the quarter. Brindle's invoice exists but was not paid until April, so it is out under finance's own rule — no error, just a period boundary. Fenwick Labs Ltd. paid invoice 1067 in March, but that name appears nowhere in the contract table. The closest contract record is Fenwick Research LLC, signed in January, which has no payment under its own name.
Three of the differences are ordinary definitional differences and need no repair. Cairn paid but shows no recorded product use: it is a paying account that is not yet an engaged one, and both statements are true. Brindle used the product but has not paid: a real customer with an uncollected invoice. Dunlin signed before the quarter and paid inside it: an existing account doing normal things. Sales, product, and finance are each answering a different question correctly.
The Fenwick record is a different kind of problem. Answer it one way and you have two entities — a research arm and a separate billing subsidiary — in which case the difference is definitional and you simply need to say which entity each slide means. Answer it the other way and you have one company entered twice under two names, the payment and the contract belong together, and the mismatch is a data error in the accounts table. Until that is settled you cannot classify the discrepancy, which means you cannot count it.
Note that the unanswered question is not the same as the Eastgate boundary question. Eastgate is a definition the owner has not yet stated. Fenwick is an identity the records have not yet established. The first you resolve by asking product one question. The second you resolve by going back to the source record and finding out which entity actually paid.
One practical limit before this grows: you need very little data to answer any of it. Three columns of an authorized export — identifier, qualifying date, amount — settle every question above. Do not paste the customer list into a deck appendix to prove a count of five. When you need to teach the method, an invented set like this one costs nothing and exposes no one.
Choose among a shared definition, distinct names, and a held result
You have three moves, and they are not ranked by prestige.
Use one shared definition when the intended question really is the same question for all three owners. This is rarer than it sounds. "How many accounts paid us this quarter" is one question, and finance's rule answers it. "How many accounts are we serving" is not one question, and no shared definition will answer it — you will end up writing a rule long enough to include everyone, which is a polite way of counting everything and measuring nothing.
Rename them. This is usually the right answer, and it costs nothing but the discomfort of a longer slide. The three measures become: new contracts signed, 5. Accounts with a completed publish event, 3 confirmed with two open items. Accounts with payment received, 3 confirmed with one open item. Each name is checkable against the rule that produced it. What you lose is the single large figure. What you preserve is the ability to say what happened.
Hold or qualify the number. When the records cannot yet be reconciled, present the figure as provisional and name the open item beside it. "Three confirmed, four if the trial workspace counts, with the Fenwick identity unresolved" is a usable statement. It has a deadline attached — someone resolves the identity, product states the boundary — and it tells the reader what would change the number.
Now the arithmetic temptation. The three headline figures are 5, 3, and 3. Their average is about 3.7, which rounds to 4 — uncomfortably close to a number somebody could plausibly defend, which is exactly what makes it dangerous. No reported measure equals four; product's reaches four only if Eastgate's trial boundary resolves that way. Averaging counts across different qualifying events produces a quantity that is arithmetically valid and referentially empty, and its nearness to a real candidate makes it likelier to survive review.
Summing is worse. Five plus three plus three is eleven account-measures drawn from six distinct accounts, four of which appear in more than one measure. Alder is counted three times.
And the sixth account, Fenwick, is the reason the union itself is provisional: six distinct accounts if the two Fenwick records are one entity, seven if they are two. A union across incompatible definitions is occasionally the thing a slide needs — "we touched these accounts in some way this quarter" — but say so explicitly, because it is a much weaker claim than any of the three measures it combines.
One process note that will save you an argument. Decide which question the slide answers before you compute the alternatives. If you find yourself with all three numbers on the table, comparing them, and then choosing, you have inverted the sequence, and the definition you land on will be the one that looked best rather than the one that fits.
Keep comparisons consistent through time and across slides
A metric that changes rule between periods will show movement that no customer produced. If product decides in Q2 to include trial workspaces, product's count rises in Q2 with no corresponding change in behavior. The line goes up. The chart looks like good news. Nothing happened.
So when someone proposes a redefinition, ask one question first: does this change the population or the qualifying event behind a number already reported? If it does, you have two options. Recalculate the comparable history under the new rule, if the source records support it and the owner agrees to own the restated series. Or leave the history as it was reported, label the break, and restrict the comparison so it does not span the change. What you must not do is draw a continuous line across a definitional seam. That line implies a trend the records do not establish, and it will be read as one.
Some measure of guidance exists on this, with sharp limits. US SEC guidance on MD&A key performance indicators and metrics, effective February 25, 2020, calls for clear metric definitions and calculation explanations and addresses disclosure of consequential methodology changes — for its own regulated-reporting context, not as a rule imposed on your internal deck. It is not authority on how to treat the Fenwick record, and it does not tell you which of your three measures belongs on the slide. What it offers is a bounded standard worth borrowing: if a methodology change is consequential enough that a reader encountering the number without the break would be misled, the change needs to be visible. Your Fenwick and Eastgate decisions are that kind of change for product's series, whatever jurisdiction you file in.
Show the measure the decision actually needs
The definition belongs with the claim, not in a speaker notes column nobody opens. If the slide says "5 new contracts signed in Q1," the rule that produced 5 should be legible on or beside it — signed agreement, period, keyed to legal entity, excludes renewals. The reconciliation detail with every unmatched record can live in an appendix or a link for whoever asks. What cannot live there is the definition itself, because the definition is what the number means.
Have finance or the relevant measurement owner confirm anything that touches accounting or calculation. Paid invoices, recognized revenue, and product activity are not interchangeable, and the difference between them is not a naming preference. This article is about aligning evidence and naming measures. It is not an accounting policy, and it is not a cleaning recipe you can run against a warehouse and trust.
End the work with three things written down: the measures by their new names, the definition choice and who owns it, and whatever remains unresolved. For the invented set above that reads as — new contracts signed, 5, sales. Accounts with a completed publish event, 3 confirmed, product to state the trial boundary. Accounts with payment received, 3 confirmed, Fenwick identity unresolved, owner to confirm by a named date.
That is a smaller and less comfortable slide than the one you started with. It is also the only version where the number on it means something a reader could check. Six accounts, three names, one open question. Agreement on the label alone was never reconciliation; it was just three teams using the same word.
Frequently asked questions
Why can Sales, Product, and Finance report different numbers for the same label?
The label may be doing different jobs. The unit counted, qualifying event, period, exclusions, and source record can all differ. A company with three workspaces and one signed agreement can contribute three to one count and one to another, with no error anywhere. None of the numbers is necessarily wrong.
What five questions should be asked of each metric owner before comparing totals?
Ask what unit is counted, what event qualifies it, over what period, what is excluded, and which record supports it. Get the answers from the person who owns the definition, not only from the person who built the dashboard. Record definitions as they are actually used, not as they ideally should read.
What are the possible causes of a metric discrepancy, and why does the cause matter?
A discrepancy can come from meaning, timing, identity matching, or a genuine data error. A dashboard title identifies none of those, and the remedies differ. For example, Cairn paid but had no recorded product use is a definitional difference; Brindle used the product but paid later is a period boundary; Fenwick may be two entities or one entered twice, which changes whether it is definitional or a data error.
When should you rename metrics rather than force one shared definition?
Use one shared definition only when the intended question really is the same for all owners. Otherwise rename them: new contracts signed; accounts with a completed publish event; accounts with payment received. Each name is checkable against the rule that produced it. You lose a single large figure but preserve the ability to say what happened.
Why is averaging or summing the three headline figures dangerous?
Averaging 5, 3, and 3 gives about 3.7, which rounds to 4, but no reported measure equals four; Product reaches four only if Eastgate’s trial boundary resolves that way. Averaging counts across different qualifying events produces an arithmetically valid but referentially empty quantity. Summing is worse: five plus three plus three is eleven account-measures from six distinct accounts, with Alder counted three times. The union itself is provisional depending on whether the two Fenwick records are one entity or two.