WMS ERP integration works when every shared field has one owner. In most businesses the ERP owns the commercial record, meaning orders, prices and invoices, and the WMS owns what physically happens to stock, meaning receipts, locations, picks and dispatches. Most integration failures come from that split never being written down, not from the connection itself breaking. This guide covers what flows between the two systems, the integration patterns you can choose from, how to handle errors and reconciliation, and how to test before cutover. The vocabulary follows Enterprise Integration Patterns, a standard catalogue of messaging designs. If you are still deciding whether you need a dedicated system at all, ERP vs WMS sets out where each one stops.
What flows between your ERP and WMS?
The core flows are item data, purchase orders and expected receipts, goods receipts, sales orders, stock adjustments and shipment confirmations. Each ERP publishes its own data model, such as the Microsoft Dynamics 365 documentation or the Xero developer documentation, and the field mapping starts with those documents rather than with the WMS.
| Flow | Usually starts in | What the WMS does | What comes back |
|---|---|---|---|
| Item master | ERP | Creates product records, dimensions, GS1 identifiers and batch or expiry flags | Confirmation the record was accepted |
| Purchase order and advance shipping notice | ERP or supplier | Sets up the expected receipt | Receipt status, including short and over quantities |
| Goods receipt | SGA | Creates stock in a storage location | Received quantity per purchase order line |
| Sales order | ERP, shop or marketplace | Allocates stock and creates pick tasks | Allocation status and short-pick flags |
| Stock adjustment | SGA | Records a count, damage or hold with a reason code | Quantity and value change for the ERP to post |
| Shipment and dispatch | SGA | Confirms dispatch with carrier and tracking data | Dispatched lines, which can trigger invoicing |
The WMS is the only system that knows a pallet is short, damaged or on hold, so it should raise those events. The ERP then needs to post what they mean financially. If you also run a transport system, dispatch data feeds it too, and WMS to TMS integration is a separate piece of work to scope.
Goods in is where most of the value sits, because the data you get before the lorry arrives decides how much anyone has to type. Mathew Buttar, Head of Solutions at Clarus, describes one standard flow where the advance notice carries a pallet barcode, batch, quantity and product code for each line. With that in place, one scan per pallet can receive a whole load, because the system already holds the data. Where a supplier sends nothing up front, the operator has to find and key each detail on the dock, and that is where receiving times blow out. Goods in and its impact on the warehouse covers that side in more depth.
Which integration pattern should you choose?
Use a native connector where one exists for your ERP or channel, a direct API where the ERP exposes a stable one, and scheduled files where it does not. Middleware earns its place when three or more systems need the same data in different shapes. Manual upload is fine for a pilot and a poor basis for live stock.
The patterns differ in what you have to run and who fixes things when they break:
- Native connector: a pre-built link to a named platform, configured rather than coded. Check which fields it maps as standard and which you must add yourself.
- Direct API: the WMS and ERP call each other’s endpoints, usually close to real time. Shop platforms such as Tienda virtual publish their own API documentation for this. Watch rate limits, authentication and who owns the retry logic.
- File exchange (SFTP, CSV or XML): files are dropped into an agreed folder on a schedule or when an event fires. SFTP runs over SSH, described in RFC 4251. Agree file naming, timing, and what happens to a file that fails validation.
- Middleware: a separate integration layer maps and routes data between several systems. It gives you one place to monitor, but it is another system to license, run and support.
- Manual upload: someone exports from one system and imports into the other. Errors grow with every extra file, so keep this for pilots and very low volumes.
Clarus is built API-first, and it supports API, EDI, XML and CSV exchange via SFTP. It also exposes an MCP server, so AI tools can query live warehouse data, which is covered on the page about smarter warehouse integrations. Clarus has pre-built connectors for Brightpearl, Unleashed Software, Zoho Inventory y Tienda virtual. Xero and Sage do not have dedicated pages, so check the integrations hub for the current position before you assume either way.
For an ERP without a connector, Mathew Buttar explains the logic simply. Where the ERP has an API, the link is close to instant. Where it does not, Clarus maps the files the ERP produces into the WMS format, creates the sales order or receipt, and sends a confirmation file back. Outbound files work the same way in reverse. An automation can send a file over SFTP when a pick list completes, so the receiving system knows what left the building without anyone keying it in.
Our verdict: choose the method by the ERP’s API maturity and by who will work the error queue, not by which connector looks best on a slide.
Who owns each field?
A field with two owners drifts. Write the ownership list before you write a single mapping rule, and get the finance and operations leads to sign it. Three examples show the shape:
- Selling price: the ERP owns it. The WMS never needs to change it, so it should only receive it.
- Storage location and bin: the WMS owns it. The ERP should not hold a location that the warehouse can change overnight.
- Batch and expiry on receipt: the WMS captures them at the dock, and the ERP reads them. If both systems can edit them, the two records will disagree within a month.
Also agree which system is the source of truth for each stock figure. For physical quantity, that is normally the WMS, because only the WMS sees the pallet that was actually counted. The ERP keeps the value and the financial posting.
How should errors and reconciliation work?
Every message needs a unique reference, every failure needs a queue with a named owner, and stock needs a regular comparison between the two systems. Without all three, a failed order push looks like a successful one until a customer calls.
Retries can create duplicates. The HTTP standard defines PUT and DELETE as idempotent, meaning repeating them has the same effect as sending them once, but POST is not, as set out in RFC 9110. If an order is pushed with POST and the response is lost, a retry can create it twice. Send a unique order reference with every create, so the receiving system can recognise a repeat.
Give failures an owner and a clock. Each integration should have an error queue, a named person who clears it, and a time limit. A message sitting unseen for two days is a stock or invoice problem, not an IT ticket.
Reconcile stock on a schedule. Compare quantities by product and location each day, and investigate any difference using the reason codes and the transaction history. Clarus keeps a full audit trail of every action and stock movement, which is what you need when two systems disagree and someone has to explain why. Track the result against your warehouse KPIs so the trend is visible, not just the exceptions.
The payoff is measurable. Almacén de St John’s Hall, a 3PL, cut its invoicing time by 90%. Its managing director used to spend around four days at the end of each month checking invoices that had been re-keyed from the WMS into the accounts package, and that re-keying has gone. Welch’s Transport, which runs both transport and third-party warehousing, reports a 100% time saving from removing duplicate data entry between its WMS and TMS, as set out in its customer story.
How do you test and cut over safely?
Test every flow end to end with the people who will use it, against a copy of your live setup, and cut over one account or product group at a time. A big bang cutover can work, but only with a full test schedule behind it. Mathew Buttar puts it this way: a big bang is fine if you have time for proper user acceptance testing, and you should not attempt one without a full schedule that covers goods in, stock control, goods out and every interface, signed off by all parties including the customer.
Build the test script from the flows table above, and include the failure cases, because those are where integrations break in practice:
- A receipt that is short, over and damaged, each with its own reason code.
- A sales order that cannot be fully allocated, and the message that goes back to the ERP.
- A duplicate order push, and what the receiving system does with it.
- An ERP outage during a busy dispatch, and how the queued messages are cleared afterwards.
- A stock adjustment that is posted in the WMS and confirmed in the ERP at the same value.
Name at least two super users on your side. They run the acceptance tests, learn why the set-up works the way it does, and become the people your team goes to after go-live. Clarus’s own UAT is manual, with customer users confirming each step, and there is no automated test suite. Ask any vendor what they automate, and what your team has to test by hand.
On timing, Mathew Buttar has said a standard Clarus project should aim to go live within 12 weeks, with the right support on both sides. Complex, high-volume projects with many features can run much longer, so ask for a dated plan that names each integration flow and its sign-off date, not just a headline go-live week.
Questions to ask a WMS vendor about ERP integration
Flip the usual question. Mathew Buttar’s discovery approach starts with what you want to send, what you can send, what you want done with it, and what you want to see back, so ask the vendor the same thing and listen for specifics. Then check the answers against this list:
- Which ERPs and channels have a pre-built connector, and which versions do they support?
- Can you show us the ownership list for item, stock and order fields, and will you sign it off with us?
- Which integration methods do you support, and is any of them an extra cost?
- When a message fails, where does it go, who sees it, and how is it retried?
- How do you stop a retried order from creating a duplicate?
- Can you send and receive files over SFTP, and what format and naming do they use?
- Who maintains the field mapping after go-live, and how are changes to our ERP tested?
- What does your UAT process look like, and which tests will our team run?
- What is your standard go-live timescale, and what would make ours longer?
Vendors who answer these in writing, with names and dates, are the ones to shortlist. Vendors who answer with a demo of the dashboard alone have not yet thought about your error queue.
Habla con un experto en almacenes
If you are evaluating how a WMS would connect to your ERP and want to see the integration options in practice, Clarus is worth a conversation. We work with 3PLs and distributors across the UK to fit warehouse management software to the way they already run, including the systems they already use.
Ponte en contacto con nuestro equipo para discutir tus requisitos.
Related reading: Sage 200 warehouse management.