Why Your ERP Reports Are Lying to You

The finance director presents Q4 numbers in the board meeting. The operations director challenges them. Both are right - from their own system. That is what ERP data latency produces: confident reports built on yesterday's state, presented as today's reality.

ERP systems were designed for transaction integrity - to ensure every purchase order, goods receipt, and invoice is recorded correctly and in the right sequence. That design priority is exactly why they fail as reporting platforms. Most enterprise ERPs run batch processes overnight: master data synchronisation, posting runs, allocation routines. By the time the plant manager opens the morning report, they are looking at data that is 8 to 14 hours old.

In fast-moving operations - high-throughput manufacturing, distribution centres, FMCG replenishment - 14 hours is not acceptable. A production line that ran at 60% OEE due to a tooling issue at 2 AM has already missed four shift cycles before the data surfaces. The decision window is gone.

This isn't a configuration issue. It is architectural. ERPs use OLTP (Online Transaction Processing) database designs - optimised for writing individual records quickly, not reading thousands of records simultaneously for analysis. When you run an analytical query across three years of sales history joined to production orders and inventory movements, you are fighting the database's fundamental design.

The consequence is twofold. First, heavy queries degrade transactional performance - which is why IT blocks them or schedules them overnight. Second, when those queries do run, they return point-in-time snapshots of a single system, not a cross-domain operational picture.

Most plants have five to fifteen operational systems beyond the ERP: MES, SCADA, CMMS, WMS, QMS, PLCs. None of them talk to the ERP in real time. The ERP sees a narrow slice of operational reality, 12 hours late.

The cost of data latency isn't felt as a line item - it is felt as decisions made on wrong information. Operations directors making replenishment calls based on yesterday's inventory. Sales teams quoting delivery dates against capacity that no longer exists. Finance teams closing the month on accruals that do not match what physically shipped.

In a manufacturing environment processing 200,000 transactions per day, a 12-hour data lag means every decision made in that window is potentially built on stale foundations. Compounded over a year, the total cost - in misdirected production runs, missed stockouts, incorrect invoicing - typically exceeds the cost of the data infrastructure that would have prevented it.

One of our clients in FMCG distribution was consistently running 8% stockout rates despite adequate inventory on hand - because their replenishment system was ordering based on stock data 16 hours stale. The product was in the warehouse. The system did not know it.

The answer is not to upgrade the ERP. It is to stop asking the ERP to do what it was never designed to do. A unified data layer - a data lakehouse or operational data platform - sits alongside the ERP and every other operational system, consuming their data in near real-time via change data capture (CDC) or API streaming.

This layer does not replace the ERP. It reads from it - and from the MES, WMS, SCADA, and every other source - and creates a single governed version of operational truth that is queryable in seconds, not hours.

The key architectural components are: a streaming ingestion layer (Azure Event Hubs, Kafka, or equivalent), a governed storage layer (Delta Lake, OneLake), and an analytical query layer (Databricks, Synapse, or Power BI Direct Lake). Together, they turn 12-hour-old batch data into a 15-minute refresh cycle - or in some cases, true real-time.

At one of our FMCG manufacturing clients, ERP data latency was driving a 6–8 day FP&A cycle. Finance could not close faster because they were waiting for production, inventory, and sales data to align - and each system ran on its own batch schedule. By building a unified Delta Lake ingesting from all three operational systems, we collapsed that FP&A cycle to same-day. The finance team now sees live production actuals against plan by 9 AM.

The same pattern applies across functions. Operations teams that previously had to pull three reports from two systems and reconcile them in a spreadsheet now see a single dashboard refreshed every 15 minutes. Not because we replaced any system - but because we stopped asking systems to do things they were not built for.

If your organisation is running monthly closes that take two weeks, or operational decisions that lag by half a shift, the problem is almost certainly data latency - not the quality of the people making the decisions.

On a Microsoft estate the unified layer has a concrete shape. Azure Data Factory reads the ERP through change data capture — SAP via the CDC (ODP) connector, Dynamics 365 via its native connector — so after the initial load you stream only changed records, not an overnight full extract. MES, WMS, SCADA, and QMS land the same way, into a Bronze zone in OneLake on a Microsoft Fabric foundation. The point is that the ERP keeps doing transaction processing undisturbed, while a separate platform does the reading — which is the whole architectural fix in one sentence.

Medallion layering turns those raw feeds into trusted numbers: Silver reconciles and conforms keys across systems, Gold holds the governed KPIs. A Power BI Direct Lake semantic model then serves a 15-minute refresh — sometimes true real-time via Fabric Eventstream off the SCADA historian — with one definition of inventory, OEE, and on-time delivery that finance and operations both read from. That shared definition is what ends the boardroom argument where two directors quote different numbers from different systems, each correct from their own batch.

Building it once on a single governed foundation is what makes it economic. The same OneLake layer that collapses the FP&A cycle also feeds manufacturing analytics and the replenishment signal without a second integration project. You connect each source once through data integration and reuse it everywhere, rather than standing up a fresh pipeline for every report.

The layer is only as fresh as its slowest feed. CDC from the ERP is near-real-time, but a legacy MES that only exposes a nightly file, or a PLC with no digital output, still gates the refresh on that domain — and no architecture invents data the source never sends. The honest move is to map each source's true latency and represent stale domains as stale, not to imply a live picture the slowest feed cannot support.

And near-real-time is not the same as real-time. A 15-minute Direct Lake refresh suits replenishment and shift reporting; genuine sub-minute shop-floor OEE needs a streaming path (Eventstream into a KQL database) alongside it. Promising true real-time across the whole estate when half of it updates every 15 minutes is exactly the overclaim that erodes trust once the dashboard is live.

The deeper limit is that the unified layer surfaces conflicts it does not resolve. When two systems genuinely disagree on a number, the platform makes the disagreement visible — it does not adjudicate it. That is a governance decision about which source is authoritative for which field, and it has to be made by people, not inferred by the pipeline. Skip that and you have built a faster way to show two contradictory truths.

The cost of latency is not a line item — it is decisions made on stale information, and it compounds. A 12-hour lag across a 300-SKU portfolio can quietly generate USD 200,000–800,000 a year in stockout and overstock losses, while the infrastructure to close the gap typically costs less than a quarter of that. The FMCG client running 8% stockouts on adequate inventory was not short of stock; the replenishment system was acting on data 16 hours stale. The fix paid for itself out of recovered service level.

It also does not require an ERP replacement or an 18-month programme. A six-week build can stand up CDC from the ERP plus one or two operational systems into OneLake and serve a single governed dashboard on Power BI — first value in 6 weeks, the FP&A cycle collapsing from days to same-day on the domains you connect first. Prove it on the decisions that lag most, then extend coverage.

Stop asking the ERP to be an analytics platform. Unify the operational data in a layer built for reading, govern which source owns which number, then serve it where the decision is made. The ERP is not broken — the expectation that one transaction engine could also be your real-time analytics layer is what is costing the shifts.