The two systems are not counting the same thing
The instinct is to look for lost messages, and messages are the least likely explanation. Before touching the interface, establish what each side means by a unit, because the two definitions differ in ways that account for most gaps of this size.
The MES counts units that completed an operation. Its natural unit is a piece, its natural timestamp is when the operator or the machine confirmed the step, and its natural scope is the work order and the operation within it. ERP counts stock: a quantity of a material, in a unit of measure, received into a storage location, on a posting date, inside an accounting period. Those are related quantities and they are not the same quantity, and the difference is not a bug. A unit can genuinely have completed final assembly and not yet be stock, because it has not been packed, or has not passed a release gate, or is sitting on a conveyor between the last station and the warehouse transfer point.
So the first question in the room is: a thousand of what, confirmed where, and nine hundred and sixty of what, received into which location, as at what time. Half of these investigations end there.
The four places forty units hide
Once definitions are pinned, the candidate suspects are enumerable and worth walking in order of likelihood rather than in order of technical interest.
| Suspect | What happened | How to confirm |
|---|
| Scrap and rework | Units completed the operation and never became good stock | Compare confirmed quantity against good, scrap and rework quantities separately |
| Unit of measure | Pieces confirmed, cases or pallets received, with a conversion applied somewhere | Check the material's conversion factors and the packing quantity used |
| Timing and period | Units received after the ERP cut-off, so they land in the next period | Re-run both sides over the same window rather than over the same calendar day |
| Confirmation model | Partial confirmations posted, final confirmation not yet made | Look at whether the work order is still open and what remains to confirm |
Scrap is the commonest and the most instructive. A line that confirms completions at the last operation and reports scrap through a separate quality flow will always show more confirmed than received, and the gap is not an error, it is yield. If nobody has reconciled the two before, the discovery that scrap was never subtracted is a legitimate finding rather than a defect in either system.
The unit-of-measure family is the one that produces the odd, suspiciously round discrepancies. Forty units on a thousand is four per cent, which is a plausible yield loss and also exactly what you get if one pallet of forty was counted in one system and not the other. Both hypotheses fit the number, which is why you must go and look rather than reason.
Timing is the one that resolves itself and wastes a day if you do not check it first. ERP postings are dated, and a posting date is not an event time. A shift that ends after midnight, an interface that batches overnight, or a period that closed on the second of the month will each put real units in the wrong bucket, and a query aligned to shifts rather than to calendar days makes the gap disappear.
Backflush is an assumption dressed as a transaction
The other half of the boundary is consumption, and it deserves separate treatment because it fails silently and expensively. Backflushing means that when you confirm production of a finished item, ERP automatically deducts the components the bill of material says were required. Nobody counted them. The deduction is derived from the recipe and the quantity produced.
That is a reasonable optimisation and it embeds two assumptions. The first is that the bill of material is right, including its allowances for expected loss, and the second is that what physically happened matched it. Neither holds when an operator substitutes a component, when a setup consumes more material than the standard allows, when a machine over-doses, or when a partial reel is scrapped. The result is an inventory balance that drifts away from the shelf without a single failed transaction, and the drift is discovered either at a stock count or when a line stops for a component the system said was available.
The design consequence is that backflush needs a counter-signal. Periodic physical counts of high-value or high-variance components, a comparison of standard against actual consumption per work order, and a visible variance report are what turn an assumption into a controlled one. Where a component genuinely matters, whether for cost or for traceability, it should be issued and confirmed rather than backflushed, and accepting the extra operator interaction is the price of knowing.
The boundary is about ownership, not about messages
Which brings the real architectural question underneath the discrepancy. The interface is easy to build and easy to argue about, and the durable decision is who owns each fact.
The workable split gives the MES authority over execution and the ERP authority over the commercial and financial record. ERP owns the demand, the material master, the bill of material, the routing as a costed object, and the inventory valuation. MES owns what happened on the floor: which unit, at which station, at what time, by whom, with what result. Each fact has exactly one system that can change it, and the other holds a copy it may not edit. When both sides can write the same quantity, you get a class of dispute that no reconciliation can settle, because there is no authority to appeal to.
The interface then carries a small, stable set of documents in each direction. Down to the floor: released work orders with quantities, dates and the routing to execute. Up to ERP: confirmations of quantity produced, scrapped and reworked, labour or machine time where it is costed, and goods movements. Keeping that list short is what keeps the boundary maintainable, because every extra field is a field two teams must agree on forever.
Two properties make it survivable in operation. Every message needs an identity so that a replay after an outage is a no-op rather than a second thousand units, and every message needs to be applied by its source event time rather than by its arrival time, because a batch that lands late must still land in the shift it belongs to. Those two properties are cheap to design in and effectively impossible to retrofit once a year of postings exists.
Closing the order makes the variance permanent
The point at which this stops being an investigation and becomes an accounting fact is the work order close. A closed order carries its final quantities and its variances into the cost record, and the difference between what the standard said and what actually happened becomes a number a controller sees. After that, correcting it is a journal entry rather than a data fix, and it involves finance.
This is why the reconciliation has to run daily rather than monthly, and why it needs an owner rather than a report. The useful design is a single boundary view, per line and per day, showing confirmed good, scrap and rework on the MES side against receipts on the ERP side, with the unexplained balance ageing. A threshold turns it into work: below it, tolerated and trended; above it, a named person looks before the order closes. That converts a class of problem which currently surfaces as an argument in a monthly meeting into a number somebody is responsible for while the evidence is still on the shop floor.
And the evidence is on the shop floor. Forty units either exist somewhere, in a buffer, on a rework bench, in a cage awaiting disposition, or they do not exist because they were scrapped and nobody posted it. Sending someone to look is not a failure of engineering rigour, it is the only measurement in the building that is not derived from something else.
A gap between MES and ERP is a definition mismatch far more often than a lost message, so the first move is to make both sides state what they counted, over what window, in what unit. The second is to make somebody responsible for the balance before the order closes.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).