Somewhere in almost every plant, there’s a spreadsheet or a support ticket titled something like “quantities don’t match between SAP and the line.” Someone opens the ERP, sees a production order for 5,000 units. Someone else opens the MES, sees three dispatch records adding up to 4,850. Nobody’s lying, nothing’s broken in the way people assume — the systems are just talking about different objects that happen to share a name. “Work order” is doing the job of four separate concepts, and until you pull them apart, you’ll keep chasing reconciliation bugs that aren’t really bugs.
This confusion has gotten more expensive lately. Plants mid-renewal on platforms like Plex or FactoryTalk, or wiring up newer AI-assisted layers like SAP Joule on top of existing ERP data, are hitting work-order status mismatches as one of the most common go-live defects. Not because the software is bad, but because nobody explicitly modeled which system owns which piece of the truth.
The four objects hiding under one word
Let’s name them properly, borrowing structure from ISA-95, which is the closest thing this industry has to a shared vocabulary for the ERP-to-MES boundary.
1. The ERP production order
This lives in SAP, Oracle, Infor, or similar, and represents a business commitment: make this quantity of this material, by this date, consuming this bill of material, costed against this order. It’s a planning and financial object. It doesn’t know anything about which machine will run it or how many setups it takes. It exists so finance, planning, and procurement can agree on what’s being made and what it should cost.
2. The MES/MOM dispatch record
This is the execution instruction handed to the floor — sometimes called a dispatch list entry, a job, or an execution order depending on your MES vendor. It’s the thing an operator or a scheduler actually clicks “start” on. Critically, a single ERP production order routinely explodes into multiple dispatch records: one per shift, one per lot split, one per line if the same order runs across two cells because of capacity. The ERP doesn’t split; the MES does, because the MES is the one dealing with real constraints — line availability, crew size, tank capacity.
3. The routing/operation step
Underneath the dispatch record sits the routing, inherited from ISA-88 (for batch) or a discrete routing table: the sequence of operations — mix, react, fill, or mill, drill, assemble, test — each with its own standard time, resource requirement, and quality checkpoints. The operation step is where you track “which step is this unit currently on,” which is a different question from “is this dispatch record open or closed.”
4. The equipment job
Finally, at the control layer, there’s the actual job or recipe instance running on a PLC, DCS, or batch control system — the phase logic executing on the reactor, the program loaded on the CNC. This is the layer OPC UA or a Sparkplug B MQTT broker is actually reporting on in real time. It has no concept of cost center or due date. It knows tank temperature and cycle count.
A worked example: batch and discrete side by side
Take a batch plant making a coating in a stirred reactor. The ERP production order says: 2,000 kg of Product X, due Thursday, order number 40001523. That single order becomes two MES dispatch records because the reactor only holds 1,000 kg per batch — Batch A and Batch B, each its own dispatch record with its own actual yield, actual raw material consumption, and its own timestamp. Under Batch A, the ISA-88 recipe has operation steps: charge, heat, react, cool, transfer. The equipment job is the S88 phase state machine running on the DCS, cycling through those exact same named steps but reporting temperature setpoints and valve states, not “operation complete” business events.
Now the discrete case: an ERP production order for 500 units of an assembled part. MES may or may not split it — if the line runs it as one continuous dispatch, you get one dispatch record; if there’s a changeover mid-run for a component substitution, you might get two. The routing has operations like kit, assemble, torque, test, pack, each with a standard cycle time. The equipment job is the program running on the robot cell or the torque wrench controller, reporting cycle counts and torque values that eventually roll up into “operation complete” events at the routing layer.
In both cases, notice the direction of information flow. Quantity and due-date intent flow down from ERP. Actuals — what really got consumed, what really got produced, what really happened at each step — flow up from the equipment job, through the routing step, into the dispatch record, and finally get aggregated back to the ERP production order as a completion confirmation.
Where each object should actually live
- ERP production order: owns planned quantity, due date, BOM version, cost collection. Should not own real-time status beyond “released / in process / confirmed / closed” at a coarse level.
- MES dispatch record: owns the split logic, actual start/stop, actual yield per split, operator or crew assignment, and the mapping back to one or more ERP order numbers.
- Routing/operation step: owns sequence, standard time versus actual time per step, in-process quality holds, and genealogy at the step level.
- Equipment job: owns real-time parameters, phase or program state, and machine-level events — the layer that OEE calculations and SPC charts actually draw from.
Why the mismatch shows up, and how to debug it
Almost every “quantities don’t reconcile” ticket traces back to one of three root causes. First, a split happened in MES that ERP never learned about — the dispatch record divided a batch for capacity reasons, and the confirmation logic only posted one of the two splits back. Second, someone is comparing an in-flight number to a closed number — the ERP order shows planned quantity while MES shows actual-to-date, and both are “correct” for what they represent. Third, and most common in new integrations: the interface layer (whether it’s a point-to-point connector, an ERP adapter, or a newer conversational layer like Joule querying live data) is reading the dispatch-record status field and mapping it onto the ERP order-status field one-to-one, when the cardinality is genuinely one-to-many.
Before opening a ticket, ask which of the four objects each number actually came from. If you can’t answer that, that’s the real defect — not the number itself.
The rule worth teaching new engineers
If you inherit a work-order model someone else built, the fastest way to get oriented is to draw four boxes — production order, dispatch record, operation step, equipment job — and trace one real order through all four. Wherever the trace breaks or a mapping is ambiguous, that’s where your next go-live defect is already waiting. The word “work order” will keep getting used loosely in meetings, and that’s fine. Just don’t let the loose language leak into your data model. The systems don’t need to agree on a word. They need to agree on which object each field actually describes.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
