ERP–WMS Integration Playbook

The most common integration architecture between an ERP and a WMS is a nightly batch file. The ERP exports a flat file of purchase orders, sales orders, and inventory adjustments at midnight. The WMS imports it at 2am. Any errors are discovered at 6am when the morning shift starts and finds missing orders or incorrect stock levels.

This architecture was acceptable when systems ran on-premise and real-time integration was technically difficult. It is no longer acceptable. Businesses operate across time zones. Orders come in at all hours. Inventory positions need to be accurate in near real-time for a finance team trying to close the books, a demand planner trying to place replenishment orders, or a customer service team trying to answer a query.

Event-driven integration — where changes in one system trigger immediate updates in the other, rather than waiting for a scheduled batch — is the architecture that enterprise operations are moving to. The shift requires middleware (an integration platform or ESB), careful event schema design, and a robust approach to error handling and idempotency. But it eliminates the midnight-file problem entirely.

SAP has been the dominant ERP in large enterprise environments for 30 years. The legacy integration method — IDocs (Intermediate Documents) sent over RFC connections — still works and is supported, but it is not the right approach for new implementations. IDocs are complex, brittle, and difficult to monitor. When something goes wrong, diagnosing the issue in STMS (SAP's IDoc monitoring transaction) requires specialist SAP Basis knowledge.

The modern approach for S/4HANA integration is the SAP Business Technology Platform (BTP) Integration Suite, which provides pre-built adapters for common WMS transaction types. For organisations not using BTP, the SAP Integration Framework (SIF) or a third-party middleware platform (MuleSoft, Boomi, or Azure Integration Services) are practical alternatives.

The 18 core transaction types that any ERP-WMS integration must cover are: inbound delivery creation, inbound delivery confirmation, goods receipt posting, putaway confirmation, purchase order updates, transfer order creation, transfer order confirmation, outbound delivery creation, pick confirmation, packing confirmation, goods issue posting, return delivery, inventory adjustment, cycle count results, batch/lot creation, serial number tracking, billing document trigger, and stock transfer between plants.

Oracle Fusion Cloud — previously Oracle ERP Cloud — uses a REST API-first architecture that is significantly more accessible than SAP's IDoc model for new integrations. Oracle Integration Cloud (OIC) provides a managed integration platform with pre-built adapters for Oracle Fusion modules and a visual mapping tool that reduces the need for custom development.

The key challenge with Oracle Fusion integration is handling the asynchronous nature of Oracle's inventory and order management APIs. Creating a sales order in Fusion does not immediately make the order available to pick — it goes through a booking and availability-to-promise process that can take seconds to minutes. A WMS integration that polls for new orders immediately after creation will frequently find them in an intermediate state.

The correct pattern is a webhook or event subscription: Oracle Fusion publishes an event when an order is ready for warehouse processing, and the integration layer receives this event and creates the corresponding outbound delivery in the WMS. This eliminates polling latency and the associated load on the Oracle API.

Dynamics 365 Supply Chain Management (D365 SCM) uses a Dataverse-based architecture for lower-complexity integrations and the Dynamics 365 finance and operations data entities for more complex warehouse scenarios. Microsoft Power Automate can handle simple trigger-based integrations, but for production ERP-WMS workloads, Azure Logic Apps or Azure Integration Services provide the reliability and monitoring capabilities needed.

One specific consideration with D365 SCM is the Advanced Warehouse Management module. Some organisations run D365 SCM with the AWM module enabled, which effectively makes D365 itself a WMS — creating obvious duplication with a standalone WMS. Before integrating a third-party WMS with D365 SCM, it is worth scoping which warehouse management functions will live in D365 and which in the standalone WMS, and whether the AWM module should be disabled.

In our experience, organisations running D365 SCM at scale typically use D365 for financial inventory — the value, the ownership, the commitments — and a specialist WMS for operational execution: directed putaway, directed picking, real-time scan validation, and shop-floor operator workflows. The integration layer keeps both systems in sync without duplicating business logic.

The unglamorous but critical aspect of any integration is what happens when something goes wrong. Messages fail to deliver. The receiving system is temporarily unavailable. A data validation error causes a transaction to be rejected. Without a robust error handling strategy, these failures silently corrupt the data alignment between your ERP and WMS.

Idempotency — the property that processing the same message twice produces the same result as processing it once — is essential for integration reliability. When a message is retried after a failure, you need to be confident that it will not create a duplicate goods receipt, double-book an inventory adjustment, or create two outbound deliveries for one sales order. Idempotency keys (unique message identifiers that the receiving system checks before processing) are the standard mechanism for this.

Monitoring should surface three things: message volume (so you know if the integration is running at the expected throughput), error rate (so you know if something has broken), and latency (so you know if messages are queuing up). All three should have alerts configured so that on-call teams are notified before a backlog becomes a business impact.