ERP–WMS message reference
Every ERP–WMS integration comes down to the same question: which messages move, in which direction, and which system owns the field. This is the complete baseline we use across every ERP connector, stated once so it can be quoted, scoped and disagreed with before development starts rather than after go-live.
The message baseline
"Into the WMS" is what the ERP sends down; "out of the WMS" is what the warehouse confirms back. Rows marked optional are only in scope when the operation runs that flow.
| Topic | Into the WMS | Out of the WMS |
|---|---|---|
| Articles / items | Item master, barcodes, units, weights, dimensions | — |
| Purchase orders | Open purchase orders | Goods receipts, per line and per batch or serial |
| Purchase order returns | Return-to-supplier orders | Return deliveries |
| Sales orders | Open sales orders | Deliveries and shipment confirmations, with track and trace |
| Sales order returns | Customer return orders (RMA) | Return receipts with condition and reason code |
| Webshop sales ordersoptional | — | Sales orders that originate outside the ERP |
| Purchase orders (WMS-initiated)optional | — | Purchase orders raised on the warehouse floor |
| Production ordersoptional | Open production orders with bill of materials | Processed and completed production |
| Production time registrationoptional | — | Hours booked per production order |
| Assembly ordersoptional | Open assembly and kitting orders | Processed and completed assemblies |
| Assembly time registrationoptional | — | Hours booked per assembly order |
| Stock counts | — | Cycle and annual count results per location |
| Stock corrections | — | Adjustments with reason codes |
Who owns which data
Integrations rarely fail on transport and often fail on ownership. Agree this table before the first message is built.
| Data | Owner | Why |
|---|---|---|
| Item master data | ERP | Codes, barcodes, units, weights and prices are created and maintained in the ERP and downloaded into the WMS. Duplicating creation in both systems is the most common cause of unmatched stock. |
| Warehouse attributes | WMS | Pick location, storage class, zone, replenishment level and pick sequence exist only in the warehouse and should never be round-tripped through the ERP. |
| Physical stock | WMS | Quantity per location, batch and serial is the operational truth and changes on every confirmed scan. |
| Financial stock position | ERP | Valuation and the administrative position stay in the ERP, updated from confirmed warehouse movements rather than from expectations. |
| Order status | Shared | The ERP owns commercial status (approved, invoiced, credited); the WMS owns fulfilment status (picked, packed, shipped, returned). |
Failure semantics
- Every message is queued. A dropped connection pauses delivery, it does not lose it.
- Failed messages stay visible and replayable — a silent gap in stock is never an acceptable failure mode.
- Messages are idempotent on their source reference, so a replay cannot double-book a receipt or a delivery.
- Warehouse work continues during an ERP or network outage; the queue drains once the connection returns.
- Every exchange is timestamped in both directions, so a discrepancy can be traced to a message rather than argued about.
Transport differs, the message set does not
A cloud ERP exposes a public API. An on-premise package usually needs a vendor connector or middleware on the customer's own server. Some environments still run a scoped file exchange on a schedule. None of that changes which messages are needed — it changes latency, monitoring and who maintains the connection. Per-ERP specifics are documented on the partner integration pages.
Frequently asked
Which messages does an ERP–WMS integration need at minimum?
Five: item master downwards, purchase orders down with goods receipts back up, sales orders down with deliveries back up, count results up, and stock corrections up. Everything else — returns, production, assembly, time registration, webshop-originated orders — is added when the operation actually runs those flows.
Which system is leading for stock?
The WMS is leading for physical stock per location, batch and serial. The ERP holds the financial and administrative position and is updated from confirmed warehouse movements. Two systems both claiming to be leading for the same number is the root cause of most integration disputes.
Should stock sync in real time or in batches?
Event-driven on confirmed actions — receipt, delivery, count, correction — rather than on a schedule. Periodic full syncs hide errors until the next run and make it impossible to tell when a discrepancy was created.
What happens when the connection between ERP and WMS drops?
Messages queue and replay when the connection returns. Warehouse operations continue in the WMS throughout, and failed messages remain visible for replay instead of disappearing.
Does this message set differ per ERP?
The message set is the same everywhere; the transport differs. A cloud ERP uses a public API, others use a vendor connector, middleware on the customer's own server, or a scoped file exchange. Where an ERP genuinely lacks a concept — production orders in an accounting-first package, for example — the row is dropped rather than faked.
Related references: WMS selection checklist, BizBloqs brand facts and the logistics glossary.
Ready to see BizBloqs on your own process?
Book a demo and we will walk your warehouse and order flow end to end — inbound, storage, picking, shipping, returns — and tell you honestly what BizBloqs would change.