Digital Transformation

Why a Unified Data Layer Is the Real Work After ERP Consolidation

Blue icon of a person with a gear, representing user settings or account configuration.
Pamela Sengupta
Blue calendar icon with a grid representing days and two rings at the top.
July 8, 2026
Consolidating onto a single ERP is a significant achievement. But for many large organisations, it is also where the hard part begins. The systems are unified on paper. The data, in practice, is not. Making AI work at enterprise scale depends on solving the problem that ERP consolidation alone does not.

The Consolidation Illusion

Most large enterprises treat ERP consolidation as the moment data becomes unified. The programme runs for years. Multiple systems are decommissioned or migrated. Reporting is eventually centralised. The project closes, and leadership marks data unification as done.

What they discover subsequently is that the data is not unified at all. Each business unit or brand that was migrated onto the single ERP brought its own conventions, export routines, metric definitions, and workarounds. The underlying system is now the same. The way different teams describe and use the data within it is not.

This distinction matters enormously when AI enters the picture. AI models do not care which ERP the data came from. They care whether the data is consistent, whether the same term means the same thing across every source, and whether the pipeline delivering data to the model is clean, continuous, and trusted. ERP consolidation addresses the system layer. It leaves the data layer, and the semantic layer above it, largely unsolved.

DATAVERSITY's 2024 Trends in Data Management survey found that 68 per cent of organisations cite data silos as their top concern, up seven per cent from the prior year. This is happening in organisations that have, in many cases, already completed ERP consolidation programmes. The consolidation solved the system problem. The data problem remained.

60-70% of AI project time in most enterprises is spent on data preparation, which is the most reliable indicator that the data foundation is not yet AI-ready. This overhead is not a reflection of AI complexity. It is a reflection of data that has not been structured, governed, and made accessible in a way that AI tools can consume reliably. (NexusOne Enterprise AI Readiness Research, 2026)

What ERP Consolidation Actually Delivers

It is worth being precise about what ERP consolidation does and does not achieve, because the gap between the two is where most post-consolidation data problems live.

ERP consolidation typically delivers a single transactional system of record, standardised financial processes and controls, common master data management for customers, suppliers, and products at a configuration level, and a shared infrastructure that reduces IT overhead and improves audit capability.

What it does not automatically deliver is a consistent set of business metric definitions across the organisation, a unified data access layer that AI tools and analytics platforms can query reliably, continuous data pipelines that move information from the ERP to downstream systems without manual extraction and transformation, and a governed semantic layer that resolves the naming, unit, and definitional conflicts that accumulate when multiple teams, brands, or regions are brought onto the same platform.

Those gaps exist because ERP consolidation projects are, by necessity, focused on making the system work. The data layer work, the work of defining what the data means and making it consistently accessible, is typically deferred. In a pre-AI environment, that deferral was manageable. Planning cycles absorbed the manual reconciliation. Finance teams developed workarounds. The system worked, imperfectly but acceptably.

In an AI environment, those deferred gaps become blockers. AI models that receive inconsistent data return inconsistent outputs. Pilots stall not because the models are wrong but because the input data contradicts itself depending on the source. The technical debt of deferred data layer work becomes visible and urgent in a way it was not before.

Also Read: Making Your ERP AI-Ready Without Replacing It

The Three Layers That Actually Need to Be Built

The ingestion layer

The first requirement is continuous, governed data pipelines from the ERP and all connected operational systems into a unified data platform. This means replacing batch exports and manual extracts with change-data-capture or streaming pipelines that keep the data current.

The ingestion layer is often where the true complexity of a multi-brand or multi-region environment becomes visible. Different divisions have built different export routines. Some systems push daily batch files. Others require API connections that did not exist at the time of the original ERP implementation. Legacy integrations that were built as temporary workarounds have become permanent dependencies.

Getting this layer right is unglamorous work. It does not produce visible AI outputs. But it is the foundation that everything else rests on, and organisations that skip it or rush it consistently find themselves rebuilding it later at significantly higher cost.

The golden record layer

The second requirement is master data resolution: creating a single, authoritative record for each product, customer, supplier, and other key business entity, which resolves the conflicts that accumulate across brands, markets, and divisions.

In a multi-brand environment, the same physical product may exist under different SKU codes in different systems, with different naming conventions, different unit-of-measure definitions, and different attribute sets. This is not a failure of the ERP. It is the natural consequence of multiple brands operating independently before consolidation and being brought onto the same system without the master data work being completed.

Golden record creation is a data engineering and business process exercise. It requires someone who understands both the technical conflicts and the business context well enough to resolve them correctly. A product classified as a unit in one brand's records and a pair in another's cannot be reconciled algorithmically without knowing what the correct definition is for the business. That knowledge lives with the people who manage the product, not just the people who manage the data.

The semantic layer

The third and most strategically important requirement is the semantic layer: a governed set of business metric definitions that resolves the definitional conflicts between teams and makes those definitions queryable by AI tools, analytics platforms, and any other system that needs to work with the data.

The semantic layer answers questions like: what does net sales mean, and is that before or after returns, before or after discounts, and which discount types are included? What does available stock mean, and does that include goods in transit, goods in quality hold, and goods reserved against open orders? What does a completed order mean, and at which point in the fulfilment process does an order transition from open to complete?

These definitions vary across teams, functions, and brands in almost every large enterprise. In a reporting environment, those variations create confusion and require manual reconciliation. In an AI environment, they produce outputs that different teams cannot agree on and will not trust. The semantic layer is what transforms a unified data platform into a usable intelligence layer.

80% of enterprise AI initiatives that fail to scale do so because AI agents cannot see consistently across the ERP, CRM, and operational systems they need to query. Without a unified data layer, each agent queries its own siloed view, producing incomplete or inaccurate outputs. Data unification is the infrastructure investment that makes every subsequent AI use case more reliable and faster to deploy. (Hexalytics Enterprise AI Research, 2026)

Why This Work Is Done Before AI, Not Alongside It

The most common sequencing mistake in enterprise AI programmes is treating the data layer as a parallel workstream that can be completed while AI use cases are being built. The evidence against this approach is substantial.

AI models trained on inconsistent data do not learn to work around the inconsistencies. They learn from them. A demand forecasting model trained on data where available stock means four different things across the team that built it will produce forecasts that reflect all four definitions, producing outputs that none of the four teams finds reliable.

Gartner estimates that 60 per cent of AI projects will be abandoned through 2026 because they are not supported by AI-ready data. That abandonment happens after investment, after build, and after the expectation of value has been created and not met. The cost of discovering data readiness issues in production is consistently higher than the cost of addressing them in advance.

The practical implication is that the data layer work, including ingestion pipelines, golden record creation, and semantic layer definition, should be scoped and resourced as a precondition for AI deployment, not as a concurrent initiative. This is a harder conversation to have with stakeholders who want to see AI in production quickly. But it is the conversation that protects the programme from the most common and most expensive failure mode.

How the Investment Compounds

The business case for the data layer investment is not just defensive. It is compounding.

Once the ingestion layer, golden record layer, and semantic layer are in place, every subsequent AI use case is faster and cheaper to deploy. The data integration work that consumed the majority of the first AI project's timeline does not need to be repeated. New models connect to the same governed data foundation. New analytics capabilities query the same semantic definitions. The organisation builds on what it has rather than rebuilding from scratch for each initiative.

The shift in planning cycle frequency that becomes possible when reconciliation overhead is removed is one of the most immediately visible outcomes. Decisions that were previously made monthly because the data was not trusted or available more frequently can be made weekly or in real time. AI forecasting models that were blocked by data quality issues go live within weeks of the foundation being completed. The data layer is not just a technical prerequisite. It is the capability that unlocks everything that follows.

About VE3

VE3 is a UK-based enterprise AI, data, and digital transformation consultancy and Microsoft Solutions Partner. We specialise in building the data foundations that make enterprise AI reliable at scale, including unified ingestion layers, golden record architecture, and semantic layer design across SAP, GCP, Microsoft, and hybrid environments. Our MatchX platform accelerates the master data unification work that sits at the heart of this challenge.

Woman sitting on couch wearing a white cable-knit sweater and blue jeans, holding a phone with one hand.
  • © 2026 VE3. All rights reserved.
LinkedIn logo in white on a gray circular background.Facebook social media icon with white f on a gray circular background.Gray circle with white X symbol, indicating a close or cancel button.Gray play button icon within a rounded square with a subtle drop shadow on a white background.