# How to Send Production and Labor Reporting from MES to ERP > Source: https://netray.co/erp-help/mes-production-labor-reporting-to-erp-how-to > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer Treat the ERP work order as the system of record for cost and quantity, and the MES as the system of record for what physically happened. Send one confirmation message per operation (or per shift or lot) containing work order, operation sequence, good quantity, scrap quantity with reason, and labor start/stop per employee and work center, post it through the ERP's supported transaction API, and make the message idempotent so a retry never double-posts. ## Kind how-to ## System mfg-systems ## Erp MES to ERP integration ## Module Production and Labor Reporting ## Query how to send production and labor reporting from MES to ERP ## Alternate Queries - MES to ERP production confirmation integration - post labor hours from MES to ERP work order - MES backflush vs operation confirmation ERP - shop floor data collection to ERP job transactions ## Applies To Any MES (commercial or custom) feeding Infor SyteLine, Infor LN, Infor M3, NetSuite, SAP, Dynamics or Epicor; patterns apply to both discrete and routing-based manufacturing ## Steps ### How to wire production and labor reporting **Items:** Decide the reporting grain: per operation completion, per lot or container, or per shift. Finer grain gives better WIP visibility but raises message volume and the odds of partial failures. Pick one owner for each fact. ERP owns work order, routing, standards and costing. MES owns timestamps, operator, machine and actual counts. Never let both edit the same quantity. Define the message: work order number, operation sequence, work center or resource, employee ID, start and end time, good qty, scrap qty plus reason code, rework qty, and a unique message ID generated by the MES. Map each field to the ERP's own transaction: for SyteLine the job transaction and labor posting IDOs, for SAP a production order confirmation (CO11N style, or the confirmation BAPIs and APIs), for NetSuite a work order completion and operation completion, for Dynamics a production journal. Post through the supported API or service layer, never by writing to ERP tables. Store the ERP document number returned and link it to the MES message ID. Enforce idempotency: before posting, check whether the message ID already has an ERP document. On timeout, retry with the same ID rather than creating a new one. Route failures to an exception queue (closed operation, wrong sequence, over-reporting, locked job) with an owner and a daily review, instead of silently dropping them. Reconcile nightly: compare MES counts and hours per work order against ERP posted quantities and labor, and flag differences above a tolerance. ## Sections ### Pick the right confirmation model **Body:** There are three common models. Operation confirmation posts quantity and time when each routing step finishes; it gives accurate WIP by step and accurate labor costing. Backflush posts materials and labor against the parent item when the last operation completes, which is simpler but hides where time and scrap actually occurred. Time-and-attendance style labor feeds post hours to a job or cost center independent of quantity, which suits indirect labor and long-running jobs. Most aerospace, defense and electronics shops need operation confirmation because they must prove which step produced which lot, and because scrap at step 40 has a different cost than scrap at step 90. Backflush is acceptable for high-volume repetitive lines where routing steps are not individually traceable. Choose per product family, not once for the whole plant. ### What the message must carry **Body:** A reliable payload is small but strict. The work order and operation sequence are the join keys; resource and employee are needed for labor and capacity reporting; good, scrap and rework quantities must be separate numbers, never a single net figure, because the ERP posts them to different accounts or locations. Timestamps should be UTC with the plant time zone carried separately, otherwise daylight saving shifts create phantom overtime. Include a unique message ID and a version or sequence number. If the operator corrects a count in the MES after the first send, the correction must be a compensating message that references the original, not a second independent confirmation. **Code:** { "messageId": "MES-2026-10-19-000412", "workOrder": "WO-100234", "operationSeq": 40, "workCenter": "CNC-12", "employeeId": "E1042", "startUtc": "2026-10-19T06:02:11Z", "endUtc": "2026-10-19T09:47:50Z", "goodQty": 46, "scrapQty": 2, "scrapReason": "SCR-DIM", "reworkQty": 0 } ### Idempotency, ordering and failure handling **Body:** The most common integration defect is double posting after a timeout: the ERP committed the transaction but the response never reached the MES, so the MES retries and the ERP posts again. Store the MES message ID on the ERP transaction (a user-defined field, reference text or an integration log table you own) and have the integration layer check it before every post. Ordering matters too. An operation 40 confirmation that arrives before operation 30 is posted can be rejected by the ERP, or worse, accepted and later corrupt move quantities. Use a per work order queue so messages for the same order are processed in sequence, while different orders run in parallel. Failed messages should block only their own work order, not the whole feed. ### Labor specifics **Body:** Decide whether the ERP receives raw clock punches or computed hours. Computed hours are easier to post, but raw punches let the ERP apply its own shift, overtime and premium rules. Whichever you choose, document it, because payroll and cost accounting will ask. Multi-machine operation, where one operator runs two machines, needs an allocation rule such as splitting elapsed time by machine, otherwise labor is double counted. Indirect time (setup, waiting for material, maintenance) should post to indirect codes or cost centers, not to the work order, unless your costing method capitalises setup into the job. Align those codes with the downtime reason list so a stop in the MES maps to a known indirect code. ## Pitfalls - Posting quantity net of scrap in one number, which destroys scrap accounting and yield reporting. - Writing directly into ERP tables to save time; it bypasses validation, costing and audit trails and breaks on upgrade. - No idempotency key, so every network timeout creates a duplicate confirmation. - Using local time without a zone, producing phantom overtime at daylight saving changes. - Letting operators edit counts in both MES and ERP, so the two never reconcile. - Dropping failed messages silently instead of queueing them with an owner. ## Ai Angle A grounded assistant such as ERPray can answer the reconciliation questions that usually take an analyst a morning: which work orders have MES hours but no ERP labor, which confirmations failed and why, and where posted scrap differs from MES scrap. It reads the ERP under the asking user's role, shows the query it ran, and does not post anything itself. For SyteLine shops, SyteRay can help draft the IDO-level integration and review the mapping, with a human approving any write-back. ## Faq ### Should the MES post to the ERP in real time or in batches? **Answer:** Near real time per operation completion is the better default because planners and customer service see accurate WIP. Batch (every few minutes or per shift) is acceptable when the ERP API is slow or rate limited. Whichever you choose, keep the message idempotent and queue per work order so batching does not change correctness. ### Can I skip the MES and have operators report directly in the ERP? **Answer:** Yes, for simple shops. The ERP's own shop floor screens or terminals may be enough if you do not need machine data, electronic work instructions or detailed traceability. An MES earns its cost when you need automatic machine counts, genealogy, or paperless routing, not just because it exists. ### How do I handle a count correction after the confirmation was posted? **Answer:** Send a compensating message that references the original message ID and carries the delta, then let the integration call the ERP's reversal or adjustment transaction. Do not edit the posted ERP document directly, since that breaks the audit trail and any downstream costing that already consumed it. ### Where should employee and work center master data live? **Answer:** Keep one master and sync it one way. Usually the ERP or HR system owns employees and work centers, and the MES receives them. Mismatched IDs between the two systems are a leading cause of rejected labor postings, so validate IDs at the interface and reject early with a clear message. ## Search terms MES to ERP integration, production confirmation MES ERP, labor reporting MES to ERP, operation confirmation work order, MES backflush vs operation confirmation, shop floor data collection ERP, idempotent ERP posting, MES ERP reconciliation, work order labor posting, MES scrap reporting to ERP --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json