WMS–ERP integration: decide which system owns each inventory fact

The WMS confirms a receipt. The ERP updates inventory from the receipt message, then applies another stock update from a separate feed describing the same movement. Both interfaces report success, but the ERP now carries twice the received quantity.

The first integration decision is ownership: who is authorised to establish each fact, and which message communicates it? A blanket “ERP is the master” or “WMS owns inventory” is too broad to answer questions about physical receipt, available stock, client ownership and valuation.

This guide's decision is the authority and quantity meaning of the warehouse-to-ERP exchange. It precedes connector selection and a receipt pilot. In a 3PL, the same SKU and quantity can belong to different clients, so an interface that omits the inventory-owner dimension can create a plausible but incorrect combined balance.

Separate the facts before selecting the interfaces

A system can display a fact without being allowed to originate it. A customer portal may show available stock; that does not make it the authority that releases held goods.

Use the following illustrative ownership matrix as a design exercise, not a universal product model.

Agree the matrix with inventory, quality, finance and IT. The application selected to store a decision must support the business authority; it does not create that authority by itself.

Microsoft's external-ERP warehouse guidance illustrates separate warehouse and ERP processing, including receipt messages, inventory updates and reconciliation. It also warns about double updates when overlapping feeds are consumed. Microsoft Dynamics 365 — Integrating warehouse management with an external ERP.

Make each message describe one kind of change

A receipt message may carry a movement of +100 units. A stock snapshot may say the balance is now 100 units. Applying both as movements would produce 200 units. Treating a later snapshot as an unconditional replacement could instead erase a legitimate intervening dispatch.

Define the contract for each message: business purpose, identifiers, dimensions, units, event time, version, quantity meaning, destination action and acknowledgement. Decide whether quantities are absolute, incremental or split by state. Do not leave the receiver to infer semantics from a field named “quantity”.

GS1's artefact page supplies EPCIS 2.0.1 specifications and schemas for event exchange. It does not make an inventory snapshot equivalent to a receipt transaction. Agree the supported standard version and the intended business use of each event with the partner. GS1 — EPCIS and CBV artefacts.

Trace a single receipt through both systems

In this illustrative sequence, the warehouse counts and accepts 100 cartons. One authorised receipt event should cause the agreed ERP receipt action.

The architecture may use only one feed to change ERP quantity and another for observation or diagnostics. Alternatively, it may combine feeds under a designed event model. Either approach must prove that the same physical movement is not counted twice.

If a pack contains ten units, preserve both the original cartons and approved conversion. A destination that expects units needs 1,000 units for this example, not 100. The mapping version belongs to the transaction history.

Now test a stale snapshot. In a separate illustrative timeline, receipt R-17 creates 100 cartons at 10:00, a snapshot records those 100 at 10:02, and dispatch D-2 removes 20 at 10:05. The current comparable balance is 80. If the 10:02 snapshot arrives at 10:10, replacing the current balance with 100 would erase the dispatch.

A snapshot therefore needs an as-of boundary and a defined purpose. Compare it with records reconstructed to the same point, or use a designed snapshot-plus-subsequent-events recovery process. Do not allow both a movement consumer and a snapshot consumer to write current stock independently.

Review the ownership model with a small replay

The WMS ERP replay sheet in the illustrative review workbook turns this sequence into editable inputs. With a 100-carton receipt, a 20-carton dispatch and ten units per carton, the comparable current quantity is 80 cartons or 800 units. A stale absolute replacement with 100 cartons would overstate that current quantity by 20 cartons.

The sheet also shows the different error from treating the 100-carton snapshot as another movement: after the dispatch, that incorrect path produces 180 cartons. The earlier double-receipt example produces 200 before any dispatch. Keep the time boundary explicit when comparing the two errors.

An unapproved conversion or unresolved quantity writer leaves the replay result unavailable. That is a prompt to resolve the design decision, rather than a stock adjustment. The worksheet's ownership table is an illustrative starting point; the actual system contract must also bind item, owner, location, status, unit and any relevant lot dimensions.

When comparing a native adapter, a controlled file handoff or an event layer, ask each approach to show the destination receipt reference and the reconstructed balance at the agreed boundary. A declared ownership matrix is insufficient if both feeds can still change quantity. Keep transport-retry design in the event-recovery review and the first live receipt scope in the implementation pilot.

Design correction authority before go-live

Receiving may correct a count. Quality may change stock eligibility. Finance may correct valuation. These are different actions and should not be represented as an unrestricted “update inventory” operation.

For each correction, identify the original fact, authorised actor, reason, resulting state or movement, affected downstream records and acknowledgement. A corrected receipt might require review if some stock has already been picked or financially processed.

The interface team should not choose whichever value makes the ledgers agree. Reconciliation detects a disagreement; authority determines its resolution.

Keep business reconciliation separate from transport success

An HTTP response or imported-file status can show that a request was received without proving that the expected business record exists. Retain the destination identifier and compare the material fields and totals.

Agree a reconciliation boundary: a completed receipt batch, a daily owner/SKU/status balance or another scope that matches the business question. Explain timing differences with specific pending events. Do not label every discrepancy “eventual consistency” without an owner and expected resolution.

A manual mapping register can document an early pilot's authority decisions, but it is not a substitute for enforcing them. Evaluate native adapters for the required movement, status and correction semantics. A custom event layer is justified only where those contracts cannot be expressed or reconciled through supported interfaces. In each case, demonstrate a receipt, its duplicate representation, an intervening dispatch and a controlled correction.

Ownership workflow: define the fact → assign business authority → map the supported event → acknowledge the destination outcome → compare records → route any correction to its owner. Ambiguous authority stops the design for that fact rather than becoming an undocumented integration rule.

Make the interface enforce the operating agreement

A sound WMS–ERP integration preserves who can establish a fact and how other systems use it. That makes successful messages meaningful and gives failed or conflicting messages a route back to an accountable decision.

Next actions

1. Trace one receipt and one dispatch across current systems and feeds.
2. Assign authority for each material field, status and correction.
3. Document movement versus snapshot semantics and unit conversions.
4. Test overlapping feeds, retries and a changed receipt.
5. Pilot the smallest receipt handoff that proves the ownership model.

An ownership assessment starts with the inventory fact being overwritten and the systems allowed to change it. Trace its correction path before adding interfaces.