Why every team in your company reports a different number

There's a moment most leadership teams know well. Someone pulls up three reports in a meeting. Revenue last quarter, active headcount, fill rate, whatever matters most to that room. Three different numbers. The conversation that follows is rarely productive. Each team defends their figure. Nobody agrees whose is right. Eventually someone says "we'll sort it out offline" and moves on.

The problem doesn't get sorted out offline. It comes up again in the next meeting, with different numbers.

I've been in that room many times, on both sides of the table. As a co-founder running operations for a coding bootcamp with 270 employees and 10,000-plus students moving through a pipeline from marketing to job placement, I needed reliable numbers on revenue, applications, and placements to run the business. I also spent years building the systems meant to produce those numbers. Both experiences taught me the same thing: mismatched numbers almost always come from the same three root causes, and the most important one is the one nobody talks about.

Three things are usually happening at once

When a company's numbers don't match across teams, it's almost always one or more of these:

Different systems with no shared identifiers. Your CRM has a record for a client. Your ATS has a record for the same client. Your payroll system has that client too. None of these records are connected by a common ID. One system calls them "Acme GmbH." Another has "ACME Germany." A third has an internal account number that nobody uses consistently. When you try to report on all activity for that client, you're doing fuzzy matching. Different people doing that matching will get different results.

Different definitions. Sales counts one thing. Finance counts something slightly different. Ops counts a third thing. They all call it "revenue" or "headcount" or "active clients," but they're measuring at different points in time, with different rules for what qualifies. More on this in a moment, because this one is the most important.

No record of who changed what. A number that looked right last month is different this month, and nobody can explain the change. Someone updated a formula. Someone added a row that shifted an aggregation. A spreadsheet got copied and the copy drifted from the original. There's no audit trail of any of it.

All three matter. But competing definitions is the one that creates the most conflict and gets the least attention.

The insight that surprises most executives

Here's what most discussions about "data problems" miss: when your sales team and your finance team report different numbers for the same metric, both numbers are usually correct.

Your sales team counts signed seats, because that's when they've done their job. Your operations team counts onboarded workers, because that's when the service started. Your finance team counts billed seats, because that's when money was collected. Three teams. Three valid measurements. Three different numbers.

No amount of cleaning, deduplication, or "better tooling" fixes a disagreement about what a metric means. You can have perfectly accurate data in every system and still produce three different headcount figures if three teams are measuring at three different points and calling the result by the same name.

  flowchart TD
      event["📋 New Client Contract\n'Acme GmbH'"]

      event -->|"Sales logs it"| crm["CRM\nID: C-1042\n'Acme GmbH'\nStatus: Signed"]
      event -->|"Ops logs it"| ats["ATS\nID: JOB-887\n'ACME Germany'\nStatus: Onboarding"]
      event -->|"Finance logs it"| erp["ERP\nID: INV-2291\n'Acme (Berlin)'\nStatus: Pending"]

      crm -->|"counts signed seats"| s_num["Sales: 42 clients"]
      ats -->|"counts active workers"| o_num["Ops: 38 clients"]
      erp -->|"counts billed seats"| f_num["Finance: 35 clients"]

      s_num --> meeting["🔴 Leadership Meeting\n'How many active clients do we have?'"]
      o_num --> meeting
      f_num --> meeting

      meeting --> chaos["42? 38? 35?\nAll three are correct.\nNone of them agree."]

This matters because most companies respond to mismatched numbers by looking for errors in the data. They run cleanup projects. They add validation. They build a new dashboard on top of the same broken sources. The underlying disagreement about definitions goes untouched, because it's not seen as a data problem. It's a conversation nobody thought to have.

Why it gets worse as you grow

At ten people, you mostly know what everyone means when they say a number. You were in the room when someone decided how to measure clients. You can ask.

At fifty, you're relying on systems that were set up with assumptions that were never written down. The person who configured the CRM two years ago is gone. The formula in the spreadsheet was written by someone in a role that no longer exists.

By a hundred people, each team has built their own reporting layer because the shared reports never showed what they needed. Marketing has their dashboard. Sales has their pipeline view. Ops has their tracker. Finance has their model. Each one was built to answer a specific question for a specific team, from whatever data that team had access to. Nobody designed them to agree with each other.

This isn't carelessness. It's what happens when a company grows faster than its data practices do. The informal coordination that worked at ten people doesn't scale to a hundred. Most companies don't notice until someone asks a question in a meeting and gets three answers.

What this means before you try to fix it

If your numbers don't match across teams, the first thing to understand is that this is not primarily a technology problem. Buying a better BI tool, migrating to a new CRM, or building a data warehouse will not fix it on its own, though some of those may be part of the answer eventually.

The problem is structural. It lives in how your teams have defined their metrics, how your systems are or aren't connected, and whether anyone has ever formally agreed on what a number means.

Before any of those fixes make sense, you need to understand why every previous attempt to fix this has either stalled or worked for a while and then stopped working. That's the next article.

next article: why every fix fails