Keeping stock figures current across ERP and WMS

Read the blog
A Alumio vivid purple arrow pointing to the right, a visual representation of how to access more page material when clicking on it.
Go back

How WMS ERP integration prevents conflicting stock figures

By
Saad Merchant
Published on
August 8, 2026
Updated on
August 8, 2026
IN CONVERSATION WITH
Email icon
Email icon

A warehouse team counts 480 units on the rack. The enterprise resource planning (ERP) system says 500. Someone corrects the ERP figure down, and two days later it reads 500 again because a scheduled job overwrote the correction. Nothing malfunctioned. The ERP and the warehouse management system (WMS) that tracks physical stock had each done exactly what they were configured to do, and neither had been told which of them was allowed to be right. This is the most common failure in WMS ERP integration, and it is not a technical fault. It is an unresolved question about which system is authoritative for which record, surfacing as a sync problem because that is where it becomes visible. Deciding those boundaries deliberately, then enforcing them in the layer that moves data between the two, is what makes the integration stable. That enforcement is the job of an integration platform-as-a-service (iPaaS), where the ownership rules can live without being buried in either system's configuration.

Why WMS ERP integration is a boundary problem

ERP and WMS overlap by design. The enterprise resource planning system runs finance, purchasing, and planning. The warehouse management system runs the physical operation, directing what gets picked from where and recording what moved. Both hold stock figures, both know about locations, and both track receipts and shipments.

The overlap is not identical, though. The ERP holds a financial and planning view of inventory, valued and aggregated, sufficient to run material requirements planning and close the books. The WMS holds a physical view, down to bin, pallet, lot, and serial, sufficient to direct a picker to a shelf.

Those views answer different questions and legitimately hold different numbers at the same moment. Stock sitting in a receiving bay is physically present to the WMS and not yet available to the ERP. Treating that difference as an error to be synchronized away is what produces overwrite loops.

Which system should own each record

A workable division follows the question each system exists to answer, rather than splitting by data type.

  • Item master: owned by the ERP, published to the WMS, because purchasing and costing depend on it.
  • Physical stock: owned by the WMS, published to the ERP, because only the warehouse observes what is on the shelf.
  • Locations and bins: owned by the WMS entirely, with the ERP holding no more than a site-level view.
  • Purchase and sales orders: owned by the ERP, released to the WMS as instructions to execute.
  • Receipts and shipments: created by the WMS as events, consumed by the ERP to update its own position.
  • Inventory valuation: owned by the ERP alone, derived from WMS events rather than maintained in parallel.

The rule underneath the list is simple. Whichever system observes an event first should own the record of it, and every other system should treat its copy as derived. Once that is agreed, most sync arguments resolve themselves.

Why ERP and WMS stock figures diverge

Three failure patterns show up repeatedly, and all three trace back to the same missing decision.

Overwrite loops occur when both systems believe they are authoritative for stock. Each correction is undone by the next scheduled run, and warehouse staff learn to distrust both figures and count instead.

Silent divergence is worse because nobody notices. Two systems drift apart on a lot or serial detail that neither reconciles. The gap surfaces during a recall or a traceability audit, which is precisely when it is most expensive. This is the same class of problem as maintaining data consistency across ERP, MES, and WMS, with fewer systems and no less cost.

Reconciliation as routine is the outcome businesses accept when they stop trying to fix the first two. A person spends part of every week comparing two reports, and that person becomes the integration.

Turn AI ambition into action

Portrait of Leonie Becher Merli, Business Development Manager at Alumio

Get a free assessment of your integration needs and next steps

Portrait of Leonie Becher Merli, Business Development Manager at Alumio

Ready to enforce ownership rules via an integration platform?

Ready to enforce ownership rules via an integration platform?

How an integration platform enforces ownership

An ownership decision only holds if something enforces it, and neither system will do that on its own. Both are configured to maintain their own view, and neither knows what the other has been told.

There are three places the rule can live. It can be configured inside one system by switching off a sync direction, which holds until an exception needs handling and leaves no record of why the exception was made. It can sit in custom scripts between the two, where it becomes undocumented logic that breaks at the next upgrade and is understood by whoever wrote it. Or it can live in the layer that already carries every exchange between them, where it is visible, testable, and changeable without modifying either system.

The third option is why the integration layer is the practical answer. The Alumio iPaaS sits between the two and applies the ownership policy in transit. A stock event originating in the WMS is accepted and forwarded to the ERP, while an ERP-side stock figure is not permitted to overwrite the warehouse position. From there the work splits into four parts:

  • Transformers: map bin-level detail into the aggregated form the ERP expects, without losing the granularity the WMS needs to keep
  • Storage: holds intermediate state, so a WMS event survives an ERP outage and replays rather than disappearing
  • Logging: records the direction and outcome of every exchange, so a supervisor can answer where a figure came from instead of guessing
  • Configuration: holds the ownership rules themselves, with the Code Transformer covering what configuration cannot express

Because the rules sit in the flow rather than hard-coded into either system, revisiting the boundary later is a change to the flow rather than a reimplementation.

Getting WMS ERP integration right before scaling it

The temptation with a warehouse integration is to start with the highest-volume flow, usually stock, because it is the one causing visible pain. The more reliable order is to agree ownership first, then connect the flows in the order the ownership model implies: master data down, events up, valuation derived.

That sequence matters more as the system landscape grows. A second warehouse, a third-party logistics provider, or a new ERP instance each inherit whatever model is already in place. An explicit boundary extends cleanly. An implicit one has to be renegotiated at every site, usually by whoever is available rather than by design.

An integration platform is what makes the explicit version hold, because it is the only place the rule can sit where both systems have to respect it. Businesses that get this right stop arguing about which number is correct. The warehouse and the finance team work from the same position, and nobody spends a morning reconciling it by hand.

No items found.

FAQ

Integration Platform-ipaas-slider-right
What is WMS ERP integration?

WMS ERP integration is the connection between a warehouse management system and an enterprise resource planning system, allowing item data, orders, stock positions, receipts, and shipments to move between them. The technical work is data exchange, but the design work is deciding which system is authoritative for each record. Without that decision, the two systems overwrite each other's corrections.

Integration Platform-ipaas-slider-right
Which system should own inventory data, the ERP or the WMS?

The WMS should own physical stock, because it is the only system that observes what is actually on the shelf, at bin and lot level. The ERP should own the valued and planning view of inventory, derived from WMS events rather than maintained separately. The two figures can legitimately differ at any moment, for example, when goods sit in a receiving bay, and forcing them to match is what causes overwrite problems.

Integration Platform-ipaas-slider-right
Why do ERP and WMS stock figures keep diverging?

Usually because both systems are configured as authoritative for stock, so each scheduled synchronization undoes the other's adjustments. A second cause is granularity, where the WMS tracks lot or serial detail the ERP does not hold, so the aggregate matches while the detail drifts. Both are resolved by fixing the ownership model rather than by synchronizing more frequently.

Integration Platform-ipaas-slider-right
How does an integration platform help connect a WMS to an ERP?

An integration platform-as-a-service (iPaaS) holds the ownership rules between the two systems and applies them to every exchange, so a stock event from the WMS updates the ERP while ERP-side figures cannot overwrite the warehouse position. It transforms bin-level detail into the aggregated structure the ERP expects and replays events if one system is briefly unavailable. It also logs each exchange, so any figure can be traced to its source.

Integration Platform-ipaas-slider-right
Should ERP and WMS sync in real time or in batches?

It depends on the flow. Stock movements and order releases generally justify event-driven updates, because delay directly causes overselling or idle pickers. Master data such as item records changes rarely and is often fine on a schedule. The reasonable default is event-driven for anything a person or another system acts on within the hour, batch for reference data.

Integration Platform-ipaas-slider-right
What should be agreed before starting a WMS ERP integration project?

The ownership boundary for each shared record, written down and agreed by both warehouse and finance, before any flow is built. Also worth settling upfront: how discrepancies are resolved when they appear, who is notified, and what granularity each system retains. These are business decisions rather than technical ones, and projects that defer them tend to encode an accidental answer that is expensive to change later.

Get a free assessment of your integration needs

Laptop screen displaying the Alumio iPaaS dashboard, alongside pop-up windows for generating cron expressions, selecting labels and route overview.