By Edris Yaghob//3 min read
End the 'our numbers don't match' meeting for good
Two teams, one metric, two numbers, every quarter. The meeting repeats because the fix was wrong. One question tells you whether you have a data quality problem or a contested-meaning problem, and which fix actually ends it.
You know the meeting. Two teams, one metric, two different numbers. Everyone is sure their figure is right. Someone asks you, the data steward, to "fix the data." You write a rule. Next quarter, same meeting, same two numbers.
The meeting repeats because the fix was wrong. Not wrong work, wrong kind of work. Before you touch anything, there is one question that tells you which problem you actually have.
The question
If both values were perfectly correct, would the numbers still disagree?
That question splits every "numbers don't match" problem into two, and the two need completely different fixes.
Case one: the values are wrong
If correcting the values would settle it, you have a data quality problem. A field is missing, stale, in the wrong format, or genuinely incorrect at source. This is the case where a rule is the right tool. Catch the breakage where it enters and flag it for repair.
This is also the case everyone reaches for first, which is why it gets over-applied to the other case, where it does nothing.
Case two: the values are fine, the meaning is not
Often both numbers are correct, and the teams are simply not measuring the same thing.
Two teams report "active customers." Both fields are populated correctly. One team means "ordered in the last 90 days." The other means "has a non-cancelled subscription." Same word, different concept. No rule fixes this, because nothing is broken. The values are right. The meaning is contested.
Or the teams agree on the word but not the method. Both report "order total." Sales calculates it including discounts and excluding tax. Finance does the reverse. They agree what order total is. They disagree on how it is produced. Again, no rule helps, because no value is wrong.
What actually ends the meeting
Once you know which case you are in, the fix is obvious and the meeting stops repeating.
- Values wrong: route it to a data quality rule, built around the consequence it prevents.
- Same word, different meaning: route it to a definition that says what counts, what does not, and which other words the team uses for the same thing.
- Same meaning, different method: route it to a short agreement on where the trusted version comes from and how it is calculated, with an owner.
Three different rooms, three different sets of people, one decision up front about which one you are in. That decision is the whole game. Skip it and you keep writing rules at a problem that was never about the values.
Why the question is hard to ask under pressure
The team wants the number fixed today. Asking "is this even a data quality problem" feels like stalling. So the question gets skipped, the rule gets written, and two months later you are back in the room. The diagnostic itself takes thirty seconds. Holding the discipline to run it before you act is the hard part, because the pressure to do something drowns out the moment to think.
That is what enabledat is built to protect: it makes you classify the problem before any fix is attempted, so the element at risk gets routed to the remedy that actually ends the argument.
Ask the one question first. The meeting stops coming back.