WMS ERP integration is the synchronization of inventory, orders and receipts between the warehouse execution system and the system of record. The connector is the easy part. The actual work is deciding, per data domain, which system owns the truth, how fast the other system learns about changes, and what happens when they disagree — because they will. The disagreements are invisible at low volume and surface at peak, which is why this integration is judged in cutoff windows, not in test plans.
This page belongs to the warehousing side of the site; the buyer-side view of fulfillment operations lives there.
What the two systems are really disagreeing about
The WMS and the ERP are both correct, about different things, at different speeds. The WMS holds physical truth at bin level, updated at event speed: a carton is received, a pick is confirmed, a pallet moves. The ERP holds financial truth at organization level, updated at document speed: a purchase order is booked, inventory is valued, a shipment is invoiced. Integration is the agreement between those two truths, and it breaks in four domains.
Inventory balance. The number everyone argues about. The WMS says 96 in bin A-12; the ERP says 100 on hand. The four units are usually not lost — they are in transit between states: received but not put away, allocated but not picked, staged but not shipped. Any sync that moves balances without moving the state behind them manufactures disagreement.
The item master. New items, discontinued items, unit-of-measure conversions, packaging changes. When the master diverges, the WMS picks the wrong item or cannot pick at all. At an EU omnichannel retailer, the product master had diverged across ERP, channels and warehouses, and it showed up as picking errors and wrong substitutions until the ERP was made the source of truth and attribute changes replicated to every channel by event (case C03).
Receipts. The ERP books a receipt when the document posts; the WMS books it when the goods are put away. Between those moments, available-to-promise disagrees with what is physically on the shelf, and the gap is largest exactly when inbound volume is highest.
Outbound confirmations. The shipment the WMS confirmed is the shipment the ERP must invoice and the customer must be told about. Latency here is not a reporting problem; it is a promise problem. The same retailer moved notification latency from 45–90 minutes to under 30 seconds when order-state transitions became published events (case C03).
The three sync architectures
Every WMS ERP integration is one of three designs, and the choice is a latency-versus-complexity trade.
Nightly batch. The classic: a full or delta extract each night, loaded into the other system. Simple, robust, and stale by design — every decision made during the day runs on last night's inventory. This was the starting state at a fulfillment operator processing millions of order-related records a day: nightly batch jobs lagged the inventory picture, so replenishment and routing decisions ran on stale data (case C08).
Scheduled incremental. Polling every N minutes for changes since the last run. Fresher than batch, and carries the classic failure mode of the cursor: a missed window, a restart, an out-of-order delivery, and the two systems diverge quietly. Incremental sync is only as good as its reconciliation, and most deployments have none.
Event-driven. Every inventory movement publishes an event; the other side consumes it in near real time. The state of the art, and the design both casebook engagements converged on: the retailer's product-master changes replicated by event (case C03), and the fulfillment operator's change stream captured via CDC and replicated into an analytical tier in near real time, so the inventory picture stopped lagging by a day (case C08). Event-driven costs more to build and demands idempotent consumers — duplicates and re-deliveries are part of the design, not an edge case.
Why the failure only shows up at peak
This is the part no vendor brochure covers. At normal volume, sync latency is invisible — the stale number is close enough, and query load is light enough that both systems answer instantly. Peak removes both disguises.
At the fulfillment operator above, the orders table had reached 3.2 billion rows with no partitioning. VACUUM ran for more than six hours and competed with the production workload. Analytical queries had grown from two seconds to four–seven minutes and were conflicting with operational writes. At peak, that degradation meant queue buildup that puts cutoffs at risk — which in that business is not a performance metric; it is a shipment that does not go out (case C08).
The fix was structural, not tuning: the orders table partitioned by month, all 3.2 billion rows migrated incrementally and in parallel with zero downtime, VACUUM moved to 15–20 minutes per partition with far less impact on production, reads split onto a replica pool, and the analytical tier served from a CDC-fed column store instead of fighting production writes. Analytical queries went from four–seven minutes to eight seconds (case C08).
The general lesson: WMS ERP integration has to be sized for the peak write rate and for the reporting load that peak attracts, or the integration's failures will be diagnosed as database problems in the middle of the busiest week of the year.
The same dynamic hits the sync itself. Polling windows that keep pace at normal volume fall behind at peak intake, and the backlog clear then competes with the very operations that need current numbers. Batch latency that nobody notices in March is the reason the inventory picture is wrong in November.
When the connector is enough, and when it is not
WMS vendors ship ERP connectors for the large ERP platforms, and they are the right answer when your process matches the connector's model: standard order types, standard receipt flows, batch or near-real-time latency that your operation can live with.
The build case opens in three situations. Your WMS or your ERP is custom, and there is no connector to buy. Your volumes make the connector's sync model — usually batch or coarse polling — operationally stale. Or the join is not just ERP-to-WMS: warehouse shipping orders arriving as EDI 940s from retail partners have to become WMS orders and flow back out as confirmations, which puts the EDI layer and the WMS ERP sync in the same data path. At that point the integration is an architecture, not a configuration.
Go-live deserves its own sentence, whichever path you take: a cutover needs a full balance reconciliation at the moment of the switch, and a parallel-run period until the drift report reads zero. Cutovers that skip the reconciliation import their divergence as opening balances — and then spend a quarter arguing about which system was wrong on day one.
What good looks like
Five properties, observable in production:
- One owner per data domain. Inventory state owned by the WMS; financial valuation by the ERP; item master by one named system with replication out. Disagreement is resolved by ownership, not by meeting.
- Events over extracts for anything the business times against — receipt confirmation, pick completion, ship confirm.
- Reconciliation that measures drift. A scheduled comparison that reports the gap between the two systems by domain, so divergence is a number on a dashboard before it is a stockout.
- Peak-sized from day one. Write rate at peak, reporting load at peak, maintenance windows that do not collide with cutoffs.
- Latency held as an SLO. At one fulfillment hub running 35,000+ shipments a day, warehouse order sync is held to a 30-second latency budget and 99.5% availability, with error budgets reviewed monthly (case C09). If your integration has no latency number, it has no integration discipline.
The failure mode this prevents is specific and expensive: oversell and cutoffs at risk from numbers that were true last night. A quick-commerce operator learned the oversell half the hard way — concurrent orders on the same SKU sold stock it did not have, until reservation became a transactional operation instead of a hopeful one (case C02).
The cost of the disagreement
Summed up: picking errors and wrong substitutions from master drift; promises made on inventory that is not available; shipments missing cutoff because the system of record was busy; and the slow, invisible kind — replenishment decisions made on last night's stock, compounding into overstock and stockouts that nobody attributes to integration.
If your WMS and your ERP tell different stories about what is on hand, the two-week diagnostic finds where the divergence is manufactured — $7,500, fixed scope, findings yours whether or not we build the fix.
Written by the CrunchCode engineering team — the people who ran these integrations in production.