WMS and ERP Integration: The Data Contract

Almost every warehouse automation project I have been called into that was described as "underperforming" turned out, on inspection, to be an integration problem wearing a robotics costume. The conveyors ran, the scanners scanned, the pick-to-light walls lit up on cue. What was broken was the quiet, unglamorous data contract between the warehouse management system and the ERP, and because that contract was loose, the two systems slowly disagreed about how much stock existed, which orders were shipped, and what had been received. This article is the deep dive on that specific contract. If you want the wider view of how automation, WMS, ERP and the shop floor fit together, start with the complete guide to warehouse automation and ERP integration, then come back here for the data contract itself.

The message up front: the WMS and ERP integration is a contract, not a pipe. A pipe just moves bytes. A contract specifies who owns each field, which system is allowed to change it, what event triggers each message, and what the receiving system is permitted to do in response. Get the ownership and the triggers right and the integration is boring and reliable, which is exactly what you want. Get them ambiguous and you will spend the rest of the system's life reconciling.

1. Why the WMS-ERP contract matters

Start with the failure it prevents. When inventory in the ERP does not match inventory in the WMS, the whole operation degrades in ways that are hard to trace back to the cause. Sales promises stock that is not physically there. Purchasing reorders material that is already on the dock. Finance closes the period on a stock valuation that reality contradicts. Customer service quotes lead times built on fiction. Every one of those symptoms is downstream of a single root cause: the two systems that each hold a version of inventory truth were allowed to disagree, and nobody defined precisely how they should be kept in agreement.

The reason this is a contract and not just a data feed is that both systems are systems of record for something. The ERP is the system of record for the commercial and financial truth: what was sold, what was purchased, what it is worth, what is owed. The WMS is the system of record for the physical truth: where every item sits, in which bin, in which quantity, at which moment. Neither is subordinate to the other. They are peers, each authoritative in its own domain, and the integration is the negotiated boundary between the two domains. A contract is exactly the right word, because like any contract it specifies obligations, timing and the consequence of a breach.

The practical test I apply on day one of an assessment: pick one item, count it physically, and compare the WMS on-hand, the ERP on-hand, and the count. If all three agree, the contract is probably sound. If they diverge, the divergence is never random. It always traces to a specific object in the contract that was mistimed, misdirected or never defined. The rest of this article is a tour of those objects.

2. What the ERP owns versus the WMS

The single most useful thing you can do before writing a line of integration code is to draw the ownership boundary explicitly, field by field, and get both the operations side and the finance side to sign it. Ambiguity here is the origin of most integration defects, because when two systems both think they own a field, the last write wins and the loser is silently overwritten.

The clean division that works in practice:

• The ERP owns the commercial and financial layer: the item master and its costing, the customer and vendor masters, prices and terms, the sales orders that represent a commitment to a customer, the purchase orders that represent a commitment to a vendor, and the general ledger valuation of inventory. These are decisions about money and obligation, and they belong in the system finance closes the books from.
• The WMS owns the physical and operational layer: the bin and location structure, the putaway and picking logic, the license plates and handling units, the wave and task management, the real-time on-hand by location, and the operational status of every movement inside the four walls. These are decisions about where things are and how they move, and they belong in the system the warehouse actually runs on.
• The shared, contested layer: item on-hand quantity and lot or serial status live in both. This is where the contract does its hardest work. The WMS is the authority on physical on-hand because it is closest to the shelf, and the ERP holds a reconciled view of that on-hand for planning and valuation. The contract must state clearly that the WMS is the source of physical truth and the ERP receives it, never the reverse, or you will get overwrites that erase real movements.

When people describe an integration as "two-way sync of inventory" my alarm goes off, because naive two-way sync is how you overwrite a real physical count with a stale planning figure. The correct model is not symmetric. Each field has one owner and one direction of authority. On-hand flows up from the WMS. Order commitments flow down from the ERP. The word "sync" hides that asymmetry and the asymmetry is the whole point.

3. The integration objects

With ownership settled, the contract resolves into a small, well-defined set of message objects. There are not dozens of them. A working WMS-ERP integration is built from roughly six core objects, each with a defined direction, a defined trigger, and a defined effect. Understanding these six is understanding the contract. The diagram below shows the shape of it: commitments flowing down into the warehouse, confirmations and corrections flowing back up into the ERP.

The data contract in one picture: the ERP hands down commitments to fulfil and to receive, the WMS hands back what physically happened.

The table below is the reference I keep coming back to during design workshops. It names each object, states its direction, and, most importantly, names the physical or commercial event that triggers it. If you can fill this table in for your own operation and both teams agree on every row, you have effectively written the contract.

Notice the symmetry of intent. Three objects flow down and represent commitments the ERP has made that the warehouse must now execute. Three objects flow up and represent physical events the warehouse has completed that the ERP must now reflect in its commercial and financial view. That balance is the healthy shape of the contract.

4. Orders down, confirmations up

Take the downward flow first, because it is the simpler half. A sales order is created and released in the ERP. At the moment of release, and not before, the ERP sends it to the WMS as an outbound order to be picked. The trigger matters: releasing on order creation rather than on order release floods the warehouse with orders that are not yet ready, on hold, or awaiting payment. The contract should specify release as the trigger, so the WMS only ever sees work that is genuinely ready to execute.

A purchase order flows down the same way. When the PO is approved in the ERP, the WMS receives an expected inbound so that the receiving team knows what is coming and can validate deliveries against it. The advance ship notice is the refinement of this: when the supplier confirms dispatch, an ASN tells the WMS exactly what is on the truck, often down to the carton and pallet, so receiving becomes a fast scan-and-confirm rather than a blind count. The ASN is optional in simple operations and close to essential in high-volume ones.

Now the upward flow, which is where accuracy is won or lost. When the warehouse physically receives and puts away goods, the WMS sends a goods receipt up to the ERP. This is the event that increments ERP on-hand and, critically, drives the three-way match against the purchase order and the supplier invoice. When the warehouse picks, packs and dispatches an order, the WMS sends a shipment confirmation up, which decrements ERP on-hand, closes the sales order line, and typically triggers customer invoicing. Every one of these upward messages represents a physical event that already happened. The ERP is not deciding anything here; it is recording reality reported by the system closest to the shelf.

The caution: never let the ERP be the trigger for a physical event. I have seen integrations where the ERP posts a goods receipt on the expected date because the PO said so, before the goods physically arrived. The books then show stock that is not on the dock, and when it arrives late, or short, or damaged, the correction turns into a manual investigation. The physical event must always be the trigger, and the physical event is only ever known first by the WMS. If your contract lets the ERP post physical movements on schedule rather than on confirmation, it is already broken; you just have not felt it yet.

5. Inventory adjustments and reconciliation

The sixth object, the inventory adjustment, is the one teams most often forget to design, and its absence is the slow leak that eventually sinks the whole thing. Physical inventory does not only change through receipts and shipments. It changes through cycle counts that find more or less than the system expected, through damage and scrap, through reclassification between lots or conditions, through found stock and lost stock. Every one of those is a real change to physical truth that originates in the WMS and must be reflected in the ERP, because the ERP is where inventory is valued and where planning decisions are made.

The contract must give the WMS a clean, first-class channel to push adjustments up, and the ERP must accept them as authoritative. This is the point where the ownership rule earns its keep: because the WMS is the agreed source of physical truth, an adjustment it reports is not a suggestion the ERP validates against its own count. It is a correction the ERP applies. The only thing the ERP adds is the financial consequence: an adjustment that changes quantity also changes valuation, and that valuation change must post to the correct general ledger account. Operations reports the quantity; finance owns the money impact of it. The contract should make both halves explicit.

Reconciliation is the safety net underneath all of this. Even with a clean contract, messages fail, get dropped, arrive out of order, or get processed twice. A mature integration runs a periodic reconciliation, typically nightly, that compares WMS on-hand against ERP on-hand item by item and reports the deltas. The goal is not to auto-correct silently, which just hides the problem, but to surface discrepancies while they are small and traceable. A reconciliation report that is empty most mornings tells you the contract is holding. A reconciliation report with a growing list of deltas is the early warning that one of your six objects is misbehaving. For the deeper mechanics of keeping two stock ledgers aligned, see the inventory synchronization pillar.

6. Real-time versus batch and message sequencing

A recurring design argument is whether the integration should be real-time or batched, and the honest answer is that it depends on the object, not the system. Different objects have different urgency, and forcing them all onto one cadence is a common mistake.

Shipment confirmations and goods receipts benefit from being near real-time, because they drive invoicing, customer visibility and on-hand accuracy that other processes read immediately. A shipment confirmed at 10 a.m. that does not reach the ERP until an overnight batch means a customer who cannot see their dispatch and an invoice that is a day late. Orders flowing down can often tolerate short intervals; a sales order released to the warehouse a few minutes later rarely matters. Inventory adjustments and reconciliation are naturally periodic and belong on a scheduled cadence. The right architecture matches the cadence to the object's real urgency rather than imposing one rhythm on everything.

Sequencing is the subtler risk and the one that causes the strangest bugs. Messages about the same item must be applied in the order the physical events happened, or on-hand goes wrong in ways that are hard to reproduce. If a receipt of ten and an adjustment of minus two are applied in the wrong order against a starting balance, the intermediate states are wrong even if the final total happens to land right, and any process reading in between sees a false number. Worse, if a message is lost, a later message may reference a state that never arrived. A robust contract therefore carries sequence or timestamp information on every message, processes per-item messages strictly in order, and is idempotent so that a message delivered twice, which will happen, does not double-apply. These are not exotic requirements; they are the difference between an integration that self-heals and one that needs a human every week.

7. Integration patterns and middleware

There are three broad ways the contract gets implemented, and the choice shapes how maintainable the whole thing will be over its life.

• Point-to-point: the WMS and ERP talk directly to each other through custom connectors. It is the fastest to stand up for a single pair of systems and the most tempting for a small operation. Its weakness shows the moment a third system needs the same inventory data, because now you are building and maintaining a second bespoke connection, then a third, and the topology becomes a web nobody fully understands.
• Middleware or integration platform: an integration layer sits between the systems, receives each object, transforms it to the target format, handles retries and sequencing, and routes it. This is the pattern I recommend for anything beyond the simplest case, because it centralises the contract logic in one place where it can be monitored, versioned and reasoned about, and it lets you add a consumer of inventory data without touching the WMS or ERP.
• API-led: modern ERPs expose well-defined APIs for exactly these objects, and the integration is built by orchestrating calls against them. For Microsoft Dynamics 365 Business Central specifically, the shape of these APIs and the events they expose is worth understanding in detail, covered in the Business Central APIs and integrations pillar, and the native warehouse behaviour it integrates with in the Business Central warehouse management pillar.

Whatever the pattern, the middleware or integration layer is where the non-functional guarantees live: retry with backoff so a momentarily unavailable ERP does not lose a shipment confirmation, dead-letter handling so a malformed message is quarantined rather than blocking the queue behind it, and observability so an operator can see message flow and spot a stall before the business does. A contract without these operational guarantees is a contract that works in the demo and fails in the third week of go-live. For the broader architectural view of how these pieces assemble across the whole warehouse-to-enterprise stack, the warehouse automation ERP integration deep dive covers the surrounding systems this contract plugs into.

8. Common failure modes

The ways this contract breaks are remarkably consistent across industries, which is oddly reassuring, because it means the defects are known and avoidable rather than mysterious:

• Ambiguous ownership: both systems believe they own on-hand, so a planning figure in the ERP overwrites a real physical count from the WMS. This is the classic naive-two-way-sync failure and it is the single most damaging one.
• ERP-triggered physical events: goods receipts posted on the expected date rather than on physical confirmation, so the books show stock the dock does not have.
• Missing adjustment channel: cycle counts and scrap have no path up to the ERP, so physical corrections in the WMS never reach the valuation, and the gap widens quietly until a stock take exposes it.
• Out-of-order or duplicate processing: messages applied in the wrong sequence, or applied twice, so on-hand drifts in ways that are hard to reproduce because they depend on timing.
• No reconciliation: nothing compares the two ledgers, so small discrepancies accumulate invisibly until they are large enough to cause a visible operational failure, by which point they are untraceable.
• One-size cadence: forcing urgent confirmations onto an overnight batch, or hammering the ERP with real-time messages it cannot absorb, because the cadence was chosen for the pipe rather than for each object.

Every one of these traces back to a term of the contract that was left undefined. None of them is a robotics or hardware problem. They are all data-contract problems, which is precisely why fixing the contract fixes the "underperforming automation" that prompted the call in the first place.

9. A practical approach

If you are specifying or repairing a WMS-ERP integration, the sequence I would follow every time:

• Draw the ownership boundary first. Field by field, name the owner and the direction of authority, and get operations and finance to sign it before any code is written. On-hand flows up from the WMS; order commitments flow down from the ERP. Make the asymmetry explicit.
• Enumerate the objects and their triggers. Fill in the six-row table for your operation. If both teams cannot agree on the triggering event for every object, you have found the ambiguity that will cause your first production incident.
• Tie every upward message to a physical event. Goods receipt on confirmed putaway, shipment confirmation on dispatch, adjustment on count or scrap. Never a schedule, never an ERP prediction.
• Design sequencing and idempotency in from the start. Timestamps or sequence numbers on every message, strict per-item ordering, and safe reprocessing of duplicates. Retrofitting these after go-live is painful.
• Match cadence to the object. Near real-time for confirmations and receipts, short intervals for orders down, scheduled for adjustments and reconciliation.
• Build reconciliation before you need it. A nightly item-by-item comparison of the two ledgers that reports deltas. It is your smoke detector, and an empty report is the daily proof that the contract is holding.

Do these six things and the integration becomes what a good integration should be: invisible. Nobody talks about it because nothing goes wrong, the numbers agree, and the automation everyone paid for actually delivers because the data underneath it is trustworthy. That invisibility is the highest compliment a data contract can earn.

10. References

The material below informs the standard patterns described here. The specifics of any given implementation depend on the WMS, the ERP and the operation, but the contract principles are stable across them.

• APICS / ASCM, Supply Chain Operations Reference (SCOR) model, on source, make and deliver process definitions.
• GS1, EDI and EANCOM message standards, on advance ship notice, despatch advice and receiving advice message structures.
• Microsoft, Dynamics 365 Business Central documentation, warehouse management and inbound/outbound API references.
• Warehousing Education and Research Council (WERC), inventory accuracy and cycle counting practice guidance.
• Practitioner experience across ERP, EAM, CAFM and WMS integrations, 22+ years, informing the ownership, triggering and reconciliation patterns above.

Where this sits in the bigger picture: this article is deliberately narrow, focused on the data contract itself. For how the WMS and ERP fit alongside conveyors, robotics, the shop floor and the wider enterprise landscape, read the complete guide to warehouse automation and ERP integration. This contract is the load-bearing wall inside that larger structure.

Final thoughts

Warehouse automation gets sold on the visible things: the robots, the conveyors, the lights, the throughput numbers on the dashboard. What actually determines whether the operation runs clean is the invisible thing underneath: the precise, boring, well-governed data contract between the system that owns physical truth and the system that owns commercial truth. When that contract is right, ownership is unambiguous, every message is triggered by a real event, sequencing and reconciliation catch the inevitable glitches, and the two systems tell the same story about inventory and orders every hour of every day.

When it is wrong, no amount of automation saves you, because the machinery is faithfully executing against numbers that are quietly false. The good news is that this is the most controllable part of the whole warehouse automation programme. It does not depend on a vendor roadmap or a hardware breakthrough. It depends on drawing the ownership boundary honestly, defining the six objects and their triggers, and building the sequencing and reconciliation discipline that keeps the contract enforceable. Get that right and the flashy parts of automation finally deliver the return they promised.

Related reading: The complete guide to warehouse automation and ERP integration, Warehouse automation ERP integration deep dive, Business Central warehouse management, Business Central APIs and integrations, Inventory synchronization.