When the ERP shows 50 units on hand and the WMS shows 12 of them already staged for outbound, you usually have not lost inventory. The two systems are reporting different quantity states from different points in time. The ERP updates on a batch schedule and typically decrements stock only when a shipment confirmation posts. The WMS tracks allocation, picking, and staging as they happen. Fix it by giving every field one owner and tightening the sync on the flows that drive allocation. Making everything real-time is not the fix.
Read the mismatch before you touch the interface
Check the quantity definition first. Compare WMS on-hand against ERP on-hand, not WMS available against ERP on-hand. If on-hand matches and only availability differs, the interface is working as designed. Your problem is who is reading which screen.
| Symptom on the floor or in CS | Likely cause | First check |
|---|---|---|
| ERP on-hand higher than WMS available | ERP counts allocated and staged stock as on-hand until ship confirm | Compare on-hand to on-hand, per item and location |
| Orders released against stock already allocated | Inventory sync interval is longer than the order release cycle | Timestamp of the last successful inventory sync |
| Overselling on web or phone orders | Available-to-promise read from a stale ERP snapshot | Which system the sales channel actually queries |
| Cancelled order still picked or shipped | Cancellation status written in two systems, with no event pushed to the WMS | Order status history in ERP and WMS side by side |
| Invoice freight differs from carrier bill | Estimated and actual freight share one field, or have different owners | Which system wrote freight cost last |
| Carton count on packing list differs from BOL | Cartons changed after the TMS tendered the shipment | Carton close time vs tender time |
| Permanent drift after cycle counts | Adjustments keyed in both ERP and WMS | Adjustment transaction logs in each system |
| Delta clears itself after the next run | Normal batch lag, not a defect | Recheck after the sync window closes |
Understand why the ERP lags the WMS
A WMS models inventory as a ladder of states: received, put away, available, allocated, picked, staged, loaded, shipped. Most ERP inventory models collapse that ladder into on-hand, and on-hand drops only when goods issue posts at shipment confirmation. Twelve units sitting in a staging lane are still on-hand to the ERP, and correctly so.
Batch sync adds a second gap. Anything that changes between runs is invisible to the ERP. If inventory and shipment confirmations sync every few hours, you get the familiar failures:
- Overselling, because availability is quoted from the last snapshot.
- Picking stock that another order already allocated.
- Customer service quoting status that is hours old.
The third mechanism is last-writer-wins. If two systems can write the same field, whichever message lands last becomes the truth. A batch file processed after a real-time event can silently revert newer data. This is how "we integrated it" turns into "the integration moves bad data faster."
Assign one owner to every contested field
Use this baseline split:
- WMS owns inventory quantities, locations, and warehouse order status: released, picked, packed, shipped.
- ERP owns money, items, and customers: item master, pricing, costing, customer records, and order creation. The ERP pushes orders down to the WMS.
- TMS owns carrier execution: carrier selection, tender, tracking, and freight.
The fights happen on five fields. Decide these in writing before anyone builds a mapping:
- Ship date. Split it into two fields. The ERP owns the promised date. The WMS writes the actual ship date at ship confirm.
- Carton count. The WMS sets it at pack close. The TMS consumes it. Any change after tender forces a re-tender and is not edited in place.
- Freight cost. The TMS owns it. Keep estimated and actual as separate fields. The ERP receives both for accrual and invoicing and never edits them.
- Inventory adjustments. Execute them in the WMS only, with a reason code. The WMS posts the result to the ERP for valuation. The ERP never adjusts quantity directly.
- Cancellation status. The ERP requests the cancel. The WMS accepts or rejects it based on pick state. The ERP marks the order cancelled only after the WMS acknowledges.
Rebuild the sync around allocation-critical flows
- Write the field ownership matrix. For every shared field, record the owner, the consumers, and the trigger that sends it. One writer per field, no exceptions.
- Map the status codes between systems explicitly. A WMS "staged" state with no ERP equivalent must map to something, or be deliberately excluded.
- Classify each flow by how fresh it needs to be. Inventory availability, cancellations, and ship confirms need event-driven messages or very frequent sync. Item master, pricing, and financial postings tolerate batch.
- Make every message idempotent. Carry a unique transaction ID plus a sequence number or source timestamp, and reject anything older than what the target already holds.
- Lock the field in every non-owning system. Make it read-only on screen, not just "please don't edit."
- Monitor the error queue. A failed message that nobody sees is indistinguishable from lag until the cycle count.
- Point each consumer at the right source. Sales and customer service read availability from the WMS, or from a feed built on it. Every screen that shows synced data displays its last-sync timestamp.
- Schedule a reconciliation job that compares on-hand by item and location between WMS and ERP and flags deltas that persist past one sync window.
Prove the ERP and WMS agree after the change
- Quiet-period snapshot. With no transactions in flight, compare on-hand by item and location. The delta should be zero. Trace any remainder to a specific transaction.
- Lifecycle test order. Push one order from ERP through release, pick, pack, tender, and ship. Confirm each status reaches the ERP and TMS within the interval you set for that flow.
- Cancel at every stage. Cancel test orders before release, after allocation, after pick, and after tender. Each one should end in a defined, acknowledged state in all three systems.
- Adjustment test. Post a cycle-count adjustment in the WMS. Confirm the ERP receives it once, with its reason code, and that the ERP screen will not accept a manual quantity edit.
- Freight test. Confirm the estimated freight lands at tender and the actual freight lands later without overwriting the estimate.
- Replay test. Resend a message you already processed. The target must reject it or ignore it, with no double posting.
Avoid the fixes that waste integration time
- Chasing real-time ERP inventory while batch jobs still run. Months of work on a perfect ERP integration still produce ERP lag if any downstream schedule is batch. Decide which consumers need fresh numbers and feed only those.
- Integrating before ownership is written down. Without ownership rules you only automate the conflict.
- Dual-entry adjustments. One adjustment keyed in both systems means drift that no sync will ever correct.
- Floor decisions from ERP screens. Pickers and leads read the WMS. If someone on the floor is comparing ERP quantities to staging lanes, you have a training and access problem.
- Ignoring data capture. If scans are skipped or wrong, every integration pattern carries wrong counts. A simple file-drop interface fed by accurate barcode scanning beats a fast feed of bad data. Spending dev time on scanning compliance often pays back more than faster sync.
- Pulling in the TMS too early. The ERP-to-WMS order push is near-universal. TMS integration depends on shipment volume and carrier count, so stabilize ERP-WMS ownership before adding a third writer.
FAQ
Why does the ERP show more stock than the WMS?
The ERP typically keeps allocated, picked, and staged units in on-hand until shipment confirmation posts goods issue, while the WMS subtracts them from available immediately. Compare on-hand to on-hand. If those match, only availability differs and the numbers are correct.
Why does a cancelled order still get picked in the warehouse?
The cancel was written in the ERP but never reached the WMS before the wave released, usually because of batch sync or an unowned cancellation field. Make the ERP send a cancel request event and wait for WMS acceptance or rejection based on pick state before marking the order cancelled.
When should I escalate a WMS-ERP sync problem to the software vendor?
Stop tuning schedules and mappings when messages leave the source cleanly, the error queue is empty, and postings still go missing or duplicate. Also stop when the standard connector cannot enforce single-writer or sequence rules. Open a case through the WMS or ERP vendor's official support channel with transaction IDs, timestamps, and the raw payloads from both sides.