ERP4 min readNetray Engineering Team

ERP-WMS Integration: Interfaces, Ownership, and Reconciliation

ERP-WMS integration connects the planning and financial system of record to the warehouse execution system that directs putaway, picking, and shipping. The design question that determines everything else is which system owns inventory truth: usually the WMS owns location-level detail and the ERP owns item-level balances by warehouse. Get that boundary wrong and you spend years reconciling. This guide covers the core interface set, the real-time versus batch decision, lot and serial traceability, and the daily reconciliation controls that keep an ERP-WMS pair honest.

Deciding the System of Record for Inventory

The standard split is that the WMS is authoritative for on-hand quantity by bin, license plate, and lot within the four walls, while the ERP is authoritative for item-level balance by warehouse, cost, and everything general ledger touches. That means ERP never directs a pick to a bin and WMS never posts a cost layer. Movements originate in the WMS and flow to the ERP as confirmations that adjust ERP quantity. Trouble starts when both systems allow adjustments: a cycle count corrected in ERP but not in WMS creates a phantom that nobody notices until a pick fails. Permit adjustments in one system only, and make the other one derive its balance.

The Core Interface Set

Most ERP-WMS pairs need six to eight interfaces, and the temptation to build twenty should be resisted. Outbound from ERP: item master, purchase order for expected receipts, and sales order or shipment order for picking. Inbound to ERP: receipt confirmation, pick and ship confirmation, and inventory adjustment. Each inbound message must carry enough detail to post a complete ERP transaction, including lot, serial, and license plate identifiers where traceability requires them.

  • Item master out: item, description, UOM, weight, dimensions, lot/serial control flags, hazmat class
  • Purchase order out: expected receipts with PO line, quantity, supplier, and required lot control
  • Ship confirmation in: order, line, quantity shipped, lot/serial, carton and pallet IDs, tracking number
  • Adjustment in: reason code mapped to an ERP transaction type so the GL posting is unambiguous

Real-Time Versus Batch and Message Sequencing

Order release and ship confirmation should be near real time, because a delayed ship confirmation delays invoicing and can break EDI ASN timing with customers. Item master and purchase order changes tolerate a five to fifteen minute cycle. What genuinely matters more than latency is ordering: a receipt confirmation that arrives before the purchase order it references will fail, and if your integration retries blindly it will fail forever. Sequence messages per entity, hold out-of-order messages briefly in a pending state, and expire them into a dead-letter queue with a clear reason. Design for at-least-once delivery, which means every ERP posting must be idempotent on a WMS-supplied transaction ID.

Cycle Count, Lot and Serial, and Traceability

In aerospace and defense, lot and serial traceability is the whole point of the WMS, and the integration must carry genealogy without loss. Cycle counts executed in the WMS produce variances that post to ERP as adjustments with reason codes, and those reason codes must map to ERP transaction types that hit the correct GL accounts. Never post a net variance; post the detail so root cause remains analyzable.

  • Carry lot, serial, expiry, and country of origin on every receipt and ship confirmation message
  • Map WMS count reason codes one-to-one to ERP adjustment transaction types and GL accounts
  • Post cycle count variances at line detail, never as a summarized net quantity per item
  • Retain WMS license plate IDs in ERP transaction history so a recall trace can cross both systems

How Netray Builds and Monitors ERP-WMS Integration

Netray starts with a written ownership matrix - which system may create, update, and adjust each inventory attribute - because most troubled ERP-WMS estates we inherit never had one. We then build the interfaces with idempotent posting keyed on WMS transaction IDs and add a nightly reconciliation job that compares ERP item-warehouse balances against summed WMS bin quantities. Our AI agents investigate any variance automatically, replaying the day's message log to identify the exact failed or duplicated transaction, and open a ticket with the root cause attached. Clients typically move from monthly surprise write-offs to same-day variance resolution.

Frequently Asked Questions

Which system should own inventory, the ERP or the WMS?

The WMS should own location-level detail - quantity by bin, license plate, and lot inside the warehouse - while the ERP owns item-level balance by warehouse plus all costing and general ledger impact. Movements originate in the WMS and flow to ERP as confirmations. Critically, allow inventory adjustments in one system only; permitting them in both is the most common source of chronic reconciliation problems.

How many interfaces does ERP-WMS integration need?

Most implementations need six to eight: item master, purchase order, and shipment order flowing out of ERP, plus receipt confirmation, ship confirmation, and inventory adjustment flowing back. Some add work order issue and receipt for manufacturing, and a cycle count interface. Building far more than this usually signals that the ownership boundary was never settled and the two systems are duplicating each other's function.

How do you reconcile ERP and WMS inventory balances?

Run a nightly comparison of ERP item-warehouse on-hand quantities against the sum of WMS bin quantities for the same item and warehouse, and alert on any nonzero difference rather than on a tolerance. When a variance appears, replay that day's confirmation messages to find the transaction that failed, duplicated, or posted out of order. Same-day investigation keeps root causes findable; monthly review does not.

Key Takeaways

  • 1Deciding the System of Record for Inventory: The standard split is that the WMS is authoritative for on-hand quantity by bin, license plate, and lot within the four walls, while the ERP is authoritative for item-level balance by warehouse, cost, and everything general ledger touches. That means ERP never directs a pick to a bin and WMS never posts a cost layer.
  • 2The Core Interface Set: Most ERP-WMS pairs need six to eight interfaces, and the temptation to build twenty should be resisted. Outbound from ERP: item master, purchase order for expected receipts, and sales order or shipment order for picking.
  • 3Real-Time Versus Batch and Message Sequencing: Order release and ship confirmation should be near real time, because a delayed ship confirmation delays invoicing and can break EDI ASN timing with customers. Item master and purchase order changes tolerate a five to fifteen minute cycle.

Fighting inventory variances between your ERP and WMS? Netray can rebuild the interface set with idempotent posting and daily automated reconciliation.