The MES-ERP interface: which integration pattern holds up when

An MES-ERP interface carries four things: master data and production orders down from the ERP, confirmations and material movements up from the shop floor. Which integration pattern holds up — the ERP's own message format, a REST API, OPC UA, file exchange or middleware — depends less on the technology than on the transaction volume, the latency the process genuinely needs, and who keeps the interface running at three in the morning. This article gives you the decision matrix, and then what couplings actually fail on in daily operation: confirmation logic, duplicate messages and outages.

What actually flows across the MES-ERP interface

Four data streams run between MES and ERP: master data downwards, production orders downwards, confirmations upwards and material movements in both directions. Everything else — quality data, maintenance orders, labour times — is a variant of one of those or belongs in an interface of its own. A working definition is therefore short: an ERP interface is a defined channel with an agreed data model through which another system exchanges data with the ERP — and the decisive part is the data model, not the channel.

The standard for this is ISA-95, published internationally as IEC 62264. According to the ISA-95 committee, the standard defines the interface between control functions and the remaining enterprise functions on the basis of the Purdue model, initially the interface between its levels 3 and 4. IEC 62264-1:2013, as the IEC Webstore describes it, covers the manufacturing operations management domain (level 3), its activities, and the interface content and transactions within level 3 and between levels 3 and 4. For ISA-95 integration of ERP and MES that means: the standard supplies terms and object models, not a protocol and not a product recommendation.

Machines do not talk to the ERP. Anyone who wants to get machine data into the ERP needs a consolidation layer: counter readings, cycle times and fault messages from level 2 have to become a confirmation that refers to an order and an operation. An MES, a shop floor data collection system or a lean intermediate layer does that job — an ERP that accepts raw machine signals is no more than a database full of counter readings with no link to an order. Where those machine signals come from in the first place — and what to do when a machine has no interface at all — is the subject of retrofitting machine data in brownfield plants.

The five integration patterns compared

Five patterns are common for the MES-ERP interface, and none of them wins on every criterion. The decision comes down to seven questions: order volume per day, the latency the process genuinely needs, the type of ERP (an on-premise system with its own message format, or a cloud ERP with a released API), how often fields and processes change, the operating skills available in house, error visibility and lock-in.

Two notes on the table. First: an API interface to the ERP system sounds modern, but it is synchronous — if the ERP goes down, the caller is left without an answer, and the buffer has to sit in the MES or an intermediate layer. Second: OPC 10030, the OPC UA companion specification for the ISA-95 common object model, states that version 1.00 covers only a subset of the standard: the object models for personnel, equipment, physical asset and material. Operations schedule and operations performance — orders and confirmations — are explicitly left to later editions. OPC UA therefore carries the master data and resource view down to the machine, but it does not replace an order interface.

Data model and mapping: where projects really fail

Coupling projects rarely fail on the protocol and frequently fail on the mapping. The ERP item is named differently from the MES product, the machine knows nothing but a program number, and the same line carries three names: a cost centre in the ERP, a work centre in the MES, a station designation in the controller. As long as those assignments live in people's heads and in spreadsheets, the interface is not fit for operation.

A shared vocabulary helps, even if you never implement it in full. ISA-95 names four kinds of information exchanged between manufacturing operations management systems: properties of material, operational information about equipment, the composition of physical assets, and the qualifications and roles of personnel. Those are exactly the four object models that OPC 10030 maps onto OPC UA. B2MML in turn is the open XML implementation of the ISA-95 data models, maintained by MESA International — now also as a JSON schema variant that MESA itself marks as not yet formally verified.

The practical benefit: if your mapping document uses the terms Equipment, Material, Personnel and Operations Schedule, ERP consultants, MES vendors and automation engineers are talking about the same things — regardless of whether XML, JSON or a CSV file ends up carrying the data. What matters is that every field has exactly one owning system and that conversion factors are maintained as master data, not as constants in the interface code.

Confirmation logic: writing quantities, times and status back correctly

The production confirmation back into the ERP is the part of the interface where business errors are most expensive, because they distort stock, costs and delivery dates. Before a line of code is written, one question has to be settled: which system owns the truth about order progress? There are only two workable answers. Either the MES owns progress and the ERP adopts it unchecked, or the ERP owns it and the MES reports events only. Hybrids in which both systems may correct produce two truths after the first outage.

Partial confirmation

Reports quantity and time against an operation without closing it. Remaining quantity and remaining time are carried forward; several partial confirmations per shift are the normal case.

Final confirmation

Closes the operation. A partial confirmation that arrives late afterwards is a business error case and has to become visible — not quietly posted and not silently discarded.

Good quantity and scrap

Are reported separately, usually with a scrap reason. Good plus scrap plus rework equals the quantity produced; if one of the three is missing, either stock or the KPIs are wrong.

Rework

Depending on the ERP, this is either a separate quantity type or an operation in its own right. Establish which variant your ERP knows before mapping — the interface cannot reinterpret it afterwards.

Time confirmation

Setup and processing time referring to the operation and, where permitted, to the person. Machine time from the controller and person time from the terminal are two different quantities.

Correction posting

Never happens by deleting, always by a reversing entry that references the original message. Only that keeps the history traceable and makes a correction itself correctable.

Idempotency and duplicate protection

Every confirmation needs a unique business-level message ID, because sooner or later a connection drops at exactly the moment when the ERP has already processed the posting but has not yet sent the acknowledgement. The sender then does not know whether the message arrived, and repeats it. Without duplicate protection, the quantity in the ERP doubles. RFC 9110 puts the principle for HTTP like this: a method is idempotent if several identical requests have the same intended effect on the server as a single one — PUT and DELETE are idempotent, POST is not. A confirmation sent by POST without a business ID is therefore, by definition, not safe to repeat.

The same problem has a name in every messaging protocol. The OASIS standard MQTT 5.0 defines three delivery guarantees: with QoS 0 (at most once) a message may be lost, with QoS 1 (at least once) it certainly arrives but duplicates are possible, and with QoS 2 (exactly once) it arrives precisely once. The practical caveat: exactly once holds between client and broker, not between machine and ERP posting. As soon as an adapter, a database or a restart sits in between, you are back to at-least-once. What is robust is therefore the combination of at-least-once delivery with a receiver that recognises repeats by their ID and discards them.

{
  "messageId": "MES-4711-0020-2026-09-21T06:14:03Z-000917",
  "sequence": 917,
  "orderNo": "4711",
  "operationNo": "0020",
  "workCenter": "WP-120",
  "type": "PARTIAL_CONFIRMATION",
  "goodQty": 240,
  "scrapQty": 3,
  "scrapReason": "Q-07",
  "unit": "PCE",
  "machineTimeSec": 2880,
  "postedAt": "2026-09-21T06:14:03Z",
  "correctsMessageId": null
}

Four rules make that example fit for operation. The messageId is assigned in the MES when the message is created, not when it is sent — a retry carries the same ID. The ERP adapter keeps a table of processed IDs and acknowledges a duplicate with the same success response as the first time, without posting again. The sequence per operation makes gaps and reordering detectable. And a cancellation is a new message with its own ID that points at the original via correctsMessageId — never a deletion.

Failure cases: when MES, ERP or the network goes down

An interface that only handles the happy path is a prototype. In daily operation, what counts is the behaviour in the five situations described in table 04 — each with the question of who sees the error and who is allowed to resolve it.

The most important dividing line in that table runs between technical and business errors. A technical error — network gone, certificate expired, service restarted — goes away with a retry. A business error — order closed, item blocked, quantity above target — never goes away with a retry. Treating both alike either fills the log with a thousand repeats of the same rejection or discards technical errors far too early. The dead letter queue therefore belongs to production control, with a plain-language reason that somebody without access to the logs can understand.

Direct coupling or middleware?

A point-to-point coupling remains sensible as long as exactly two systems are involved, the formats stay stable and one team knows both sides. Middleware between MES and ERP — or, more generally, a unified namespace in which every system publishes to and subscribes from a broker — becomes the better answer as soon as one of the following conditions applies.

• —A third system wants the same confirmations — a quality system, energy monitoring, maintenance, a dashboard. With direct couplings the number of connections grows quadratically with the number of systems.
• —The ERP is facing a release upgrade or a migration; an intermediate layer keeps the manufacturing model stable while the ERP side changes.
• —The error handling from table 04 would otherwise have to be rebuilt in every single direct coupling.

The costs have to be named honestly: middleware is another system with licences, updates, certificates and a team that understands it. It shifts complexity, it does not remove it. Anyone taking that route should settle beforehand who owns the platform — IT or production — and what the topic or message schema looks like. A concrete ISA-95 topic schema and the question of the single point of failure are covered in the article on the unified namespace as an architecture for machine and order data.

A discussion guide for your ERP vendor

Most of the expensive surprises in an MES-ERP interface are known before the quotation — provided somebody asks about them. The list below belongs in the conversation with the ERP vendor or the internal ERP team, and the answers belong in writing in the requirements specification.

Approach and acceptance criteria

The sequence is the same in almost every project: master data first, then order supply, then confirmation, then material. Anyone who starts with confirmation because it promises the most visible benefit ends up posting neatly reported quantities against items and work centres that have not yet been reconciled.

1. 01

   Define the owning system and the mapping

   Name one owning system for every field in table 03, create conversion factors as master data, and file the mapping as a document with a version number. Without this step, no later test is reproducible.

2. 02

   Synchronise master data

   Transfer items, routings and work centres from the ERP into the MES and produce a reconciliation report: what is missing, what is duplicated, what has no counterpart. Only when that report is empty does the project move on.

3. 03

   Build order supply

   Transfer production orders including changes and cancellations. The critical test is not the new order but a date change on an order the MES has already started.

4. 04

   Introduce confirmation with duplicate protection

   Write partial and final confirmations, scrap and times back, set up message IDs and a dead letter queue, and provide monitoring for the shift supervisor — initially in parallel with the existing procedure.

5. 05

   Connect material movements

   Withdrawals and receipts come last, because they change stock and contain most of the business edge cases. Settle how the receipt itself is captured — from the delivery note through to the posting — before the interface writes its first movement.

6. 06

   Evaluate the parallel run and accept

   Run both procedures for at least one full planning cycle, evaluate deviations daily, and tie acceptance to the test cases below — not to a date.

If the interface replaces a spreadsheet maintained by hand, the parallel run also delivers the evidence of how many errors the manual transfer was producing. Record those figures per week: they are the argument for retiring the spreadsheet in production control in stages rather than all at once.

1. 01Partial confirmation: three partial quantities against one operation, then a final confirmation — totals in MES and ERP match and the remaining quantity is zero.
2. 02Duplicate: send the same message three times — exactly one posting exists in the ERP and the sender receives a success response three times.
3. 03Cancellation: cancel a posted partial confirmation and report it again with a corrected quantity — the history stays traceable and stock is correct.
4. 04ERP outage: stop the ERP test system for 30 minutes and generate 50 messages during that window — after restart all 50 are posted in the right order and the backlog counter was visible.
5. 05Business rejection: a partial confirmation against an operation already finally confirmed — it lands in the dead letter queue with a plain-language reason and is not retried.
6. 06Volume: send one hour of the released volume within ten minutes — no losses, latency within the agreed limit.
7. 07Reconciliation run: execute the per-order reconciliation after the outage test — the report shows zero deviations, or exactly the ones deliberately created.

Those seven test cases are also the acceptance criteria. They belong in the requirements specification with their expected results before a vendor prices the work — not in a wish list submitted afterwards. A requirements specification for industrial software that leaves them out hands the definition of acceptance to the vendor.

Conclusion

The MES-ERP interface is not a question of protocol. ISA-95 supplies the vocabulary and the five patterns supply the options — the coupling only becomes dependable through three decisions taken before the technology: which system owns order progress, how duplicates are detected, and what happens when one side fails. Anchor those three points in the requirements specification and in the acceptance tests, and you can choose the integration pattern almost freely, by volume and by the skills available to operate it.

The next step is not a quotation but the mapping document from table 03 and the answers to the question list for your ERP vendor. If you need an intermediate layer for that — one that consolidates machine data, buffers it and hands it to the ERP with a business ID — the ralwo solutions for machine data and interfaces show how such a layer is typically built.