Sit in enough leadership meetings and you will eventually watch this happen. Someone from sales says last month's revenue was one figure. Someone from finance says it was a different one. Both are reading off a screen. Both are, in a narrow sense, correct: they are just measuring slightly different things and calling them the same word. The next twenty minutes disappear into working out whose number is right, which nobody resolves, so the decision the meeting was called to make gets pushed to next week, by which point the numbers have changed again.
This is a data readiness problem, and increasingly an AI governance one: a structural property of how most companies' data is arranged, and the single biggest reason AI projects underwhelm in mid-sized businesses. You can buy the best model in the world. If it is answering questions against data where "revenue" means three different things depending on which system you ask, it will give you a confident, fluent, and unreliable answer, the same way your two colleagues did, only faster and with less accountability.
This post is about why everyone is looking at different numbers, why AI makes the problem worse before it makes it better, and what the fix actually is. The fix is not glamorous and it is not a model. It is integration and a semantic layer, in that order.
Why the numbers disagree
There are three reasons the same concept produces different answers in different places, and most companies have all three at once.
The data lives in silos. The average organisation runs an enormous number of separate applications and has integrated only a fraction of them. MuleSoft's 2025 Connectivity Benchmark, the most-cited figure in this space, put the average at roughly 897 applications per organisation with under a third connected to each other. The rest are islands. Your accounting system knows one thing, your CRM knows another, your operations tooling knows a third, and nothing reconciles them automatically. When someone needs a number that spans two islands, they do it by hand, which is slow, error-prone, and produces a different answer depending on who did it and when.
Each tool defines metrics its own way. Even where the data is reachable, the definitions are not shared. The finance team's "active customer" is computed one way in a spreadsheet. The CRM has its own logic baked into a report. The dashboard tool encodes a third version in its own modelling language. None of these definitions can see each other, so they drift apart silently. Industry write-ups on this are blunt about the symptom: the absence of shared definitions produces inconsistent numbers and long debates in executive meetings. That debate is not a personality problem. It is an architecture problem wearing the disguise of a personality problem.
Nobody owns entity resolution. Underneath the metrics sits a quieter issue: is this the same customer? The same product? The same supplier? When "Acme Pty Ltd", "Acme (Pty) Ltd" and "ACME" are three rows in three systems, any number that counts customers, sums their spend, or measures their profitability is built on sand. Resolving entities to a single canonical record is unglamorous, ongoing work that most mid-sized companies have never assigned to anyone. So it does not happen, and the numbers inherit the mess.
The compounding effect is corrosive in a way that does not show up as a line item. Teams stop trusting central reports and build their own shadow spreadsheets, which makes the fragmentation worse. Analysts spend the bulk of their week gathering and reconciling data rather than interpreting it. Decisions slow down. And the thing that erodes fastest is the most expensive thing to lose: confidence that the company's own numbers mean anything.
AI does not fix data readiness gaps: it amplifies them
The hope, reasonably, is that AI will sit on top of the mess and sort it out. Ask a question in plain language, get the answer, skip the reconciliation meeting. The reality is the opposite, and it is worth being precise about why.
Point a language model (or a text-to-SQL system) at your raw tables, and you are asking it to infer your business logic from column names. Which rows count as revenue? Which filters apply? How do these two tables join? The model guesses, using whatever it can read in the schema. Databricks' engineering team put the consequence plainly in their 2026 writing on semantic layers: querying raw tables means the model has to reconstruct business logic it cannot actually see, the results are inconsistent and ungoverned, and there is no way to audit whether the generated query reflects what the metric is supposed to mean. You have taken an already-ambiguous data estate and added a component that produces fluent, confident answers on top of it: answers that are now harder to challenge, because they did not come from a colleague you can argue with.
This connects directly to a point worth holding onto: a model should never be the source of truth for a number. But there is a deeper problem here than the model. Even a perfectly reliable model cannot give you a consistent answer if there is no consistent definition for it to ground against. The fix has to happen below the model, in the data layer, before the question is ever asked.
The fix, in two parts and a specific order
The companies that get past this do two things, and the order is not optional.
First, integrate. Get the data out of the silos and into one place (a data warehouse) through pipelines that run automatically, not weekly exports someone drops into a folder. As the data lands, map it to a canonical model: one definition of "customer", one of "product", one of "invoice", with entity resolution applied so the three spellings of Acme become one record. This is the layer that ends the "is this the same thing" ambiguity. It is genuine engineering work, it benefits from people who understand the cryptic schemas of the source systems, and there is no shortcut around it. But it is finite, and once done it compounds.
Second, put a semantic layer on top. A semantic layer (sometimes called a metrics layer) is the place where each metric is defined exactly once, in one governed location, and every tool that asks for it gets the same answer, whether the question comes from a dashboard, a spreadsheet, a notebook, or an AI assistant. The industry has converged on this hard enough that practitioners called 2025 "the year of the semantic layer", driven precisely by the arrival of AI tools that need unambiguous definitions to be trustworthy. The tooling is mature: dbt's Semantic Layer, Cube, AtScale and others let you define metrics as version-controlled, lineage-aware configuration: "revenue" is written down once, in readable form, and reused everywhere. In late 2025 dbt Labs, Snowflake and Salesforce went further and launched the Open Semantic Interchange initiative to standardise these definitions across vendors, so the logic is portable rather than trapped in one tool.
Notice what this buys you beyond consistency. Because the definition lives in one readable, versioned place, it is auditable. Anyone can open it and see exactly how "active customer" is computed. When the number changes, the change is in the version history. This is the same discipline that keeps a model out of your decisions: the truth lives in something a human can read and reproduce, not in logic scattered across forty reports and three people's memories. Integration plus a semantic layer is how "everyone is looking at different numbers" becomes "there is one number, and here is the definition behind it."
The work nobody budgets for is the work that matters
This is, admittedly, not the part of an AI project anyone is excited about. The model is exciting. The natural-language demo is achievable in an afternoon. Integrating six source systems and writing down every metric definition is slow, detailed, and impossible to make look good in a board deck.
It is also the precondition for everything else working. The pattern is consistent across the teams we see succeed: they treat the data layer as the foundation and build the application on top of it, rather than the other way around. The ones who skip it ship an impressive demo, watch it produce a wrong number in front of an executive within the first month, and spend the next quarter discovering that the problem was never the model.
There are real returns on the other side of the work. One widely-reported example: Bilt Rewards centralised their metric definitions and entity relationships in 2025 and cut their analytics costs by around 80% while materially improving trust in the numbers. The dramatic figure is less important than the shape of it: consolidating definitions does not just make reports consistent, it removes an entire category of recurring, expensive reconciliation work. The reward is not only a cleaner dashboard. It is the leadership meeting where nobody argues about whose figure is right, because there is only one figure and its definition is written down.
The discipline, plainly
If you take one operating principle from this, it is that "everyone is looking at different numbers" is an architecture problem, and you should treat it as one rather than papering over it with another spreadsheet or another dashboard tool.
- Integrate before you analyse. Pipelines into one warehouse, not exports into one folder. The data has to be in one place and updating automatically before any of the rest is real.
- Resolve entities once. Decide what counts as the same customer, product, and supplier, and apply it at the data layer. Every metric you build sits on top of this.
- Define each metric exactly once. In a governed semantic layer, version-controlled and readable. "Revenue" is written down once and reused everywhere: dashboards, spreadsheets, and AI agents included.
- Make AI query the definitions, not the raw tables. A model grounded in governed metric definitions is consistent by design. A model inferring logic from raw schemas is a faster way to be wrong.
- Treat the definition as auditable truth. If you cannot open the metric, read how it is computed, and see when it last changed, you do not yet have a single source of truth: you have a single dashboard.
The companies pulling ahead on AI in 2026 are not the ones who picked the cleverest model. In the mid-market especially, they are the ones who did the unglamorous work of making their systems agree on what the words mean. Once the company has one definition of its own numbers, almost everything else (reporting, analytics, and AI that you can actually trust) gets easier. If your organisation is still at the point of debating whose number is right, that is a data readiness question, and it is exactly where our AI data foundations work starts. Until it does, every new tool you add is just one more place for the numbers to disagree. The related trap, where the data you own gets mistaken for the record it ought to be checked against, is your data moat is not your source of truth.
References
- MuleSoft 2025 Connectivity Benchmark (average ~897 applications per organisation, roughly 29% integrated), reported in Speakwise, Information Silos Statistics 2026. https://speakwiseapp.com/blog/information-silos-statistics
- Integrate.io: Data Transformation Challenge Statistics: 50 Statistics Every Technology Leader Should Know in 2026. https://www.integrate.io/blog/data-transformation-challenge-statistics/
- QuickLaunch Analytics: What Are Data Silos? (And Why They're Costing You). https://quicklaunchanalytics.com/bi-blog/what-are-data-silos/
- Databricks: Semantic Layer Architecture: Components, Design Patterns, and AI Integration (March 2026). https://www.databricks.com/blog/semantic-layer-architecture-components-design-patterns-and-ai-integration
- Coalesce: Semantic Layers in 2025: A Catalog Owner and Data Leader Playbook. https://coalesce.io/data-insights/semantic-layers-2025-catalog-owner-data-leader-playbook/
- AtScale: What Actually Changed in 2025 and Why It Redefined the Semantic Layer. https://www.atscale.com/blog/why-ai-redefined-the-semantic-layer/
- dbt Labs: Unify Metrics and Accelerate Analytics with the dbt Semantic Layer. https://www.getdbt.com/product/semantic-layer
- Querio: Metrics Layer vs Semantic Layer: What's the Difference? (Bilt Rewards example). https://querio.ai/articles/metrics-layer-vs-semantic-layer-difference
- Improvado: The Metrics Layer: Your Single Source of Truth for KPI Definitions. https://improvado.io/blog/what-is-a-metrics-layer
- Open Semantic Interchange (OSI) initiative: announced 2025 by dbt Labs, Snowflake, Salesforce and others. https://www.atscale.com/glossary/semantic-layer/
Written by JP, Sixees Labs. Last reviewed June 2026.