The production dashboard says 960 units. The ERP report says 920. Both systems are working and healthy, both reports are internally consistent, and yet the numbers do not match. For a manufacturing team trying to understand performance, that disagreement is more than a reporting inconvenience. It can delay decisions and undermine confidence in the data.
Before replacing a dashboard or commissioning another integration, it is worth asking a simpler question. Are both systems measuring the same thing, over the same period, using the same rules?
Different systems answer different questions
An Enterprise Resource Planning (ERP) system typically supports business planning, orders, inventory and financial processes. A Manufacturing Execution System (MES) focuses on manufacturing operations and the execution of production. These domains are connected, but their data is not necessarily recorded at the same moment or for the same purpose.
For example, an MES may count a unit when a production step is completed. ERP may register that unit only after confirmation, a quality decision, a stock movement or another business transaction. A discrepancy does not automatically mean that one system is wrong. It may reveal that two valid events, in two different contexts, are being compared as though they were identical.
Four common reasons for conflicting figures
Definitions: Does ‘produced’ mean started, completed, accepted by quality or booked into inventory? Does a rejected unit remain in the count? The label may be identical while the underlying business rule differs.
Timing: MES may update close to the production event, while ERP may receive transactions later or in batches. Shift boundaries, time zones, late confirmations and backdated entries can create apparent gaps.
Granularity: One system may track machine cycles or individual serial numbers; another may aggregate production orders, batches or finished goods. Mapping one level to another requires explicit transformation rules.
Ownership and corrections: Who is authorised to change a production quantity? Where are scrap, rework and reversals recorded? If corrections are applied in only one system, reports can drift over time.
A practical reconciliation example
Imagine a line that physically completes 1,000 pieces during a shift. The MES records 1,000 completed operations, including 30 pieces subsequently rejected and 20 awaiting final quality release. ERP records 950 accepted pieces available for the next business step. In this illustrative scenario, neither number is inherently incorrect. The error would be calling both values ‘finished production’ without explaining their different definitions.
A useful reconciliation table would record the source event, business definition, timestamp, equipment or order identifier, quality status, transformation logic and accountable owner. Once these fields are visible, the team can explain the difference rather than repeatedly arguing over which dashboard is right.
How to investigate before changing technology
Begin with one KPI that matters to operations. Write down its intended definition and identify each system that publishes it. Trace a small sample of records from the original production event through intermediate applications to the final report. Check where values are filtered, aggregated, delayed or corrected.
Bring production, quality, IT and business stakeholders into the same conversation, and ideally gathered around the same “demo” environment to make the example tangible. Agree which value is appropriate for which decision: it may be the first one, the second one, or may be both! Then document the mapping and the exceptions. Standards such as IEC ISO 62264 (aka ISA-95) provide a useful common language for the relationship between enterprise and manufacturing operations; ISO 22400 addresses definitions of manufacturing operations KPIs. Neither replaces the need for site-specific agreement, for this very specific context.
Where FactoVia fits
FactoVia’s role is not to declare that every system must show the same number. It is to help teams establish shared definitions, understand data flows and determine which architecture and governance decisions will make information reliable and useful. That work can reveal whether the next step is a data-model change, an integration adjustment, a process decision or a more focused pilot. We have designed a specific 7-step method to ensure we have removed misalignments, and our tangible Lab further helps on complex situations where decisions are to be made to de-risk the creation of a new modern factory, or to upgrade your existing one, and complement potentially “Industry 4.0” tools.
