When two reports from the same business give different numbers

Why the same KPI returns different results depending on who runs it, how to know if your company has a data governance problem, and what to do about it without a six-month project.

The operations director opens the CRM report on a Monday morning: 1,240 active customers. The CFO walks into the meeting with the ERP number: 1,087. Nobody knows which one is right. The meeting turns into a debate about data sources instead of about the business.

This isn’t a story about a chaotic startup. It’s the everyday reality of most mid-sized companies in Latin America running more than two operational systems in parallel.

And the problem isn’t that they have many systems. It’s that nobody defined the rules.

What data governance actually means

Before getting into symptoms and solutions, it’s worth pulling this term out of the academic territory where it usually lives.

Data governance isn’t software. It’s not a certification. It’s not the three-year program that a consulting firm pitches with slides full of framework diagrams.

It’s the answer to three very simple questions:

1. What does this data point mean? (the definition)
2. Where does it come from? (the source and the process that generates it)
3. Who is responsible for keeping it correct? (the owner)

When those three questions have documented answers for your key business indicators, you have data governance. When they don’t, you have the two-reports problem.

The symptoms that show up most often

Reports that give different numbers for the same question

We already described this. What causes it is almost always some combination of:

• Different definitions of the same concept. “Active customer” in the CRM might mean anyone who bought in the last 12 months. In the ERP it might mean anyone with an invoice issued in the quarter. Both are “correct” by each system’s logic — but they’re not talking about the same thing.

• Undocumented calculation logic. Someone in IT built the report three years ago. That person is no longer around. Nobody knows exactly what the query does. Everyone uses it.

• Data that gets transformed in different places. The same field gets cleaned, grouped, or filtered differently in each system that touches it.

The KPI that “we always use this way”

Every company has a number that nobody questions because “it’s always been this way.” The real margin, the cost per operation, the service level. At some point someone calculated it a certain way, put it in a report, and it’s lived there ever since.

The problem shows up when the business changes — a new product line gets added, a process gets modified, a new system gets integrated — and nobody updates the indicator’s logic. The number keeps coming out, keeps looking reasonable, and it can take months of wrong decisions before anyone realizes it no longer measures what it should.

Dashboards that break without warning

This is especially visible in teams that already have some technical maturity: they built a dashboard in Power BI or Metabase, it’s been working, and one day it stops working or starts showing strange results. The reason is usually that someone renamed a column in the source database, or changed the logic of an ETL process, without knowing that three reports depended on it.

Without data contracts — explicit agreements about what can change and what can’t, and who notifies whom when something does change — every production modification is a time bomb.

The report that takes two weeks

“I need to know how many patients with diagnosis X we had in Q1, broken down by location.”

If the answer is “let me check, I have to cross the HIS with the billing system and the spreadsheet that admin keeps,” the problem isn’t technical capacity. It’s data architecture: the information exists, but it’s fragmented across silos that don’t talk to each other, and the process of integrating it is manual and fragile.

That’s also a consequence of absent governance: when there’s no integrated, documented data layer, every business question requires archaeological work.

Why this happens in mid-sized companies

Large corporations have solved this problem (or are in the process of solving it) because they have dedicated teams and budgets. Small startups don’t have it yet because the data volume doesn’t justify it.

Mid-sized companies — 50 to 500 people — are at the worst point in the spectrum: they already have enough systems and enough data volume for the chaos to be real, but they don’t have the internal muscle to organize it, and the problem grew organically without anyone seeing it coming.

Nobody decided to have bad data governance. They simply never decided to have good data governance.

The typical progression looks like this: the ERP gets implemented, the CRM gets added two years later, someone gets hired to build reports in Excel by crossing exports from both, those reports become “the official source,” then an analyst replicates them in Power BI with slightly different logic, and at some point there are four versions of the same number living in four different places.

What to do, and in what order

The good news is that resolving this doesn’t necessarily require a long-term transformation project. There are concrete steps that can be taken in weeks, not years.

Step 1: Identify the five indicators that generate the most arguments

You don’t have to document the entire business at once. That’s paralyzing. Start with the indicators that show up in every board meeting and always generate debate about which number is correct.

For each of those five indicators, document:

• Exact definition: what it includes and what it excludes
• Source: which system the base data comes from
• Calculation process: what transformations are applied
• Update frequency: how often it refreshes
• Owner: who is responsible for keeping it accurate

That’s a minimum viable data glossary. It doesn’t require special software — it can live in a Google Doc or Notion. What matters is that it exists and that everyone knows where it is.

Step 2: Establish one source of truth per indicator

Once the indicators are documented, define which system is the official source for each one. If “active customers” comes from the CRM, it comes from the CRM — and the ERP can have its own number for its own purposes, but they don’t compete in the same meeting.

This sounds obvious, but it requires an explicit, communicated decision. Without that decision, each department keeps using the number it’s comfortable with or most familiar with.

Step 3: Audit existing reports

With the documentation in hand, review the reports that are used regularly and verify whether their logic matches the agreed definitions. In most cases, discrepancies will surface — that’s normal and expected. The goal of this step isn’t to judge; it’s to identify which reports need to be updated to align with the source of truth.

Step 4: Add visibility to production changes

This is the most technical step, but also the one that prevents the most future problems. When someone modifies a database table or changes the logic of an ETL process, there needs to be a mechanism to know which reports depend on it.

In more mature environments this gets solved with data lineage tools. In simpler environments, a convention is enough: before modifying something in production, check a dependency registry. If that registry doesn’t exist, the prior step is to create it.

When this isn’t enough

If data is completely fragmented across silos that can’t be integrated without manual work, the steps above relieve the symptom but don’t resolve the root cause. In that case, the conversation to have is about architecture: what integration layer is needed so that data from different systems can talk to each other reliably.

That’s an engineering project, not a documentation exercise. But documentation is still the first step — because without knowing what you want to integrate and under what definitions, any architecture you build will reproduce the same chaos at a different layer.

The sign that you’re on the right track

When someone at the company can answer “how many active customers do we have?” in under two minutes, with a single number, and can explain exactly where that number comes from and what it includes — that’s data governance working.

It’s not a perfect state. It’s not the complete absence of ambiguity. It’s the ability to have business conversations about the business, rather than about which report to believe.

For most mid-sized companies, getting there doesn’t require a six-month project. It requires three meetings, a shared document, and the willingness to make a decision about which system is authoritative for what.

The hard part isn’t technical. It’s organizational: someone has to make that decision and hold it when the department that “loses” pushes back to use their number.

---

Does your company have this problem but you’re not sure where to start? The Smart Blueprint is a 10-hour diagnostic that maps where your data layer is breaking and what to prioritize first. Fixed price, no surprises — reach out here.

---

Related articles:

• Your company doesn’t have an AI problem. It has a data problem.
• Your ERP now has AI: what the vendor doesn’t tell you before you turn it on