Different teams get different numbers from the same data because they are pulling from different sources, applying different business logic, and working with data that has never been formally aligned. Without a shared data foundation, each team builds its own version of the truth, and those versions inevitably diverge. The sections below unpack exactly why this happens and what it takes to fix it.
Why does the same metric show different values across teams?
The same metric shows different values across teams because each team calculates it independently, often using different source tables, different date filters, and different definitions of what counts. Revenue might exclude returns in one report and include them in another. Headcount might include contractors in one system and exclude them in a second. The metric name is shared; the logic behind it is not.
This is not a technology problem at its core. It is a coordination problem made worse by technology. When teams have direct database access, self-service BI tools, and no agreed-upon definitions, divergence is the natural outcome. Each analyst optimises for their own use case, and over time the gap between reports widens until the moment a CEO or board member spots two slides with contradictory numbers in the same meeting.
The deeper issue is that most organisations treat data as a byproduct of their systems rather than a product in its own right. When data is not owned, defined, and tested like production software, inconsistency is not a bug. It is the expected result.
What causes data silos to form in the first place?
Data silos form when teams build or adopt systems independently, without a shared data strategy. A sales team implements a CRM, operations deploys an ERP, and the factory floor runs a manufacturing execution system. Each system serves its users well, but none of them were designed to talk to each other. Over time, each team exports what it needs and builds its own local logic on top.
Organisational structure accelerates this. When business units have their own budgets, their own IT support, and their own reporting deadlines, the incentive to invest in shared infrastructure is low. It is faster to build a local spreadsheet than to wait for a central data team to prioritise your request. That local spreadsheet becomes the source of truth for the team, even if it contradicts every other source in the company.
In manufacturing, energy, and agritech environments, silos have an additional layer of complexity. Operational technology systems like SCADA platforms, IoT sensors, and historian databases sit entirely outside the traditional IT data landscape. Bridging that OT-IT gap requires specialist data engineering work that most organisations have never formally resourced. Investing in robust software and data solutions is often the most effective way to close that gap sustainably.
What’s the difference between a data warehouse, data lake, and lakehouse?
A data warehouse stores structured, processed data optimised for reporting and analytics. A data lake stores raw data in its original format, structured or not, at low cost and high volume. A lakehouse combines both approaches, adding a structured metadata and governance layer on top of lake storage so that raw data can be queried with warehouse-like reliability and performance.
Data warehouse
Warehouses enforce schema on write, meaning data must be cleaned and structured before it enters. This makes querying fast and reliable but creates a bottleneck: every new data source requires transformation work upfront. Warehouses work well for stable, well-understood business metrics but struggle with the volume and variety of modern operational data.
Data lake
Lakes accept data as-is, which makes ingestion fast and flexible. The cost is that without discipline, a lake becomes a data swamp. Raw files accumulate, lineage is unclear, and analysts spend more time finding and cleaning data than analysing it. Many organisations that invested in lakes in the early 2020s now have exactly this problem.
Lakehouse
The lakehouse architecture, supported by open table formats and modern query engines, attempts to resolve this tension. It gives data teams the storage economics of a lake with the governance and query performance of a warehouse. For organisations dealing with both structured business data and high-volume operational or sensor data, the lakehouse pattern is increasingly the practical choice in 2026.
How does poor data governance lead to conflicting reports?
Poor data governance leads to conflicting reports because without agreed definitions, ownership, and quality standards, every team fills the gaps with its own assumptions. Governance is not documentation for its own sake. It is the mechanism that ensures a metric means the same thing in every system, every report, and every conversation.
When governance exists only as a PDF policy document that no one reads, it has no operational effect. Definitions drift. New data sources are added without lineage tracking. Columns get renamed or repurposed without notice. An analyst who joined six months ago has no way of knowing that the order_date field in one table refers to the date an order was placed, while in another it refers to the date it was shipped.
Effective governance enforces rules in code, not in documents. Data quality checks run automatically in the pipeline. Column definitions live in a data catalogue that is updated as part of the deployment process. Ownership is assigned at the dataset level, not the department level. When governance is operationalised this way, conflicting reports become detectable and correctable before they reach a stakeholder.
What does a single source of truth actually require?
A single source of truth requires four things working together: a shared data platform, agreed metric definitions enforced in code, clear data ownership, and automated quality monitoring. Remove any one of these and the single source of truth becomes a single source of opinion that teams will eventually stop trusting.
The platform layer is the foundation. All teams need to read from the same underlying data, whether that is a lakehouse, a cloud data warehouse, or a federated mesh architecture. The right choice depends on the organisation’s scale, data volume, and team structure. What matters is that the choice is made deliberately and that raw source data flows into it reliably.
Metric definitions need to live in a transformation layer that is version-controlled and tested, not in individual BI tool calculations that differ from one dashboard to the next. Tools in the modern data stack make it possible to define a metric once and have it serve every downstream report consistently. Pairing strong metric governance with managed data services ensures that the platform remains reliable and well-maintained as your organisation scales.
Ownership matters because data without an owner degrades. Someone needs to be accountable when a pipeline breaks, when a definition changes, or when a new business unit needs onboarding. Without clear ownership, the single source of truth becomes everyone’s problem and therefore no one’s priority.
How can teams stop data disagreements from recurring?
Teams stop data disagreements from recurring by treating data reliability as an engineering discipline, not a governance exercise. That means building pipelines with observability built in, defining metrics in a shared transformation layer, establishing ownership at the dataset level, and running automated data quality checks that alert on failures before they reach end users.
The practical starting point is usually a data audit. Map every report that matters, trace it back to its source, and identify where definitions diverge. Most organisations discover that the same five or six core metrics are being calculated in a dozen different ways. Aligning those definitions and encoding them in a shared layer eliminates the majority of disagreements immediately.
From there, the focus shifts to pipeline reliability. A metric can be perfectly defined and still produce wrong numbers if the pipeline feeding it breaks silently at 2am. Alerting, lineage tracking, and automated freshness checks are not optional extras for mature data teams. They are the minimum standard for a platform that stakeholders can trust.
If your team is spending most of its time firefighting pipelines and reconciling conflicting reports rather than delivering analytical value, the architecture and governance layer underneath needs to be rebuilt, not patched. Talk to our data engineers about where to start. We work hands-on with organisations in manufacturing, energy, and agritech to build data platforms that teams across the business can actually rely on.
Frequently Asked Questions
How long does it typically take to build a single source of truth from scratch?
The timeline depends heavily on the number of data sources, the complexity of existing pipelines, and how much alignment work is needed across teams. A realistic starting point is a focused 6–12 week engagement to audit existing reports, align core metric definitions, and establish a shared transformation layer for the most critical business metrics. Full platform maturity — including automated quality monitoring, data cataloguing, and broad team adoption — typically develops over 6–18 months. The key is to start with the five or six metrics that cause the most disagreement and build outward from there.
What if different teams genuinely need different versions of the same metric?
This is more common than most organisations admit, and it is a legitimate business need rather than a governance failure. The solution is not to force a single rigid definition but to define a canonical base metric in the shared transformation layer and then create clearly named, documented variants for specific use cases — for example, ‘revenue_gross’ versus ‘revenue_net_of_returns’. Each variant should be version-controlled, owned, and visible in the data catalogue so that every consumer knows exactly what they are using and why it differs from the base definition.
How do we get business stakeholders to agree on shared metric definitions?
Start by making the cost of disagreement visible. Pull two conflicting reports into the same room and show exactly where the numbers diverge and why — most stakeholders are far more motivated to align once they see a concrete example of how conflicting data has affected a real decision. From there, run structured definition workshops with representatives from each team, document the agreed logic in plain language before encoding it in code, and assign a named owner to each metric. Stakeholder buy-in is significantly easier when people feel they participated in the definition rather than having it imposed on them.
Is a data mesh a better alternative to a centralised data platform for avoiding silos?
A data mesh distributes data ownership to domain teams rather than centralising it, which can reduce bottlenecks and improve accountability in large organisations with mature engineering capabilities. However, it introduces its own coordination challenges: without strong federated governance standards, a mesh can replicate the same inconsistency problems it was designed to solve. For most mid-sized organisations in manufacturing, energy, and agritech, a well-governed centralised or hybrid lakehouse architecture delivers more practical value faster than a full mesh implementation. The right architecture depends on team size, engineering maturity, and how independently different business units genuinely need to operate.
What tools are commonly used to enforce metric definitions in the transformation layer?
dbt (data build tool) has become the de facto standard for defining, testing, and documenting transformations in the modern data stack — it allows metric logic to be written once in SQL, version-controlled in Git, and tested automatically on every run. Semantic layer tools such as MetricFlow, Cube, or LookML sit on top of the transformation layer to serve consistent metric definitions to every downstream BI tool. For data quality monitoring, tools like Great Expectations, Soda, or Monte Carlo provide automated checks and alerting. The specific stack matters less than the principle: metric definitions should live in code, not in individual dashboard calculations.
How do we handle data quality issues coming from operational technology systems like SCADA or IoT sensors?
OT data sources introduce quality challenges that traditional data governance frameworks were not designed for, including missing readings due to connectivity loss, sensor drift, timestamp misalignment, and high-frequency data volumes that overwhelm standard pipeline tooling. The practical approach is to build a dedicated ingestion and validation layer specifically for OT data — one that handles late-arriving records, flags anomalous readings against expected ranges, and normalises timestamps before the data enters the shared platform. This OT-IT bridging work requires specialist data engineering expertise and should be scoped and resourced separately from business data integration work.
What is the minimum viable first step for a team that is just starting to address data inconsistency?
The most impactful first step is a structured data audit focused on your highest-stakes reports. Identify the three to five reports that leadership relies on most, trace each metric back to its source table, and document every place where the logic differs across teams. This exercise alone typically surfaces the root causes of 80% of recurring disagreements. From there, pick the single most contentious metric, agree on one definition with all stakeholders, encode it in a shared transformation layer, and retire the conflicting versions. Proving the model works on one metric builds the organisational trust needed to scale the approach across the rest of the business.