The warehouse management system demonstration has landed. The picking screens were clear, the put-away logic made sense, and the vendor had an answer for everything until a customer service manager asked what happens when a customer reduces an order after the warehouse has started picking it. That question is the whole ERP vs WMS decision, and the scope table on the vendor’s slide cannot answer it. Once a pick has been released, which system is allowed to change it, and how does the ERP find out what actually happened?

Divide the two systems’ responsibilities by the decision each must make and the event that confirms its result, rather than by which record lives where. The ERP owns the commercial order: what the customer has been promised and what they will be invoiced. The warehouse system owns released work: what is being picked, from where, by whom, and what has left the building. After release, a change to the commercial order is a request to the warehouse. The warehouse checks its own state, accepts the change or records why it cannot, and the ERP reflects the accepted result. If the boundary between the two cannot behave that way, buying a WMS has created a second place to change the same order.

ERP vs WMS by the decision each one makes

An ERP coordinates the records the whole business shares: customers, products, prices, orders, invoices, purchase orders, supplier payments, and the stock quantities finance reports on. Sales, customer service and finance work in it because it holds the commercial facts about each order and the money that follows from them.

It answers what the customer was promised, what they were invoiced, and what the business still owes them. Our guide to what ERP software is covers how one order carries several of those facts at once, so this article takes that as read.

A WMS directs physical work at the level of the task and the location. It decides which bay a pallet goes to when it arrives, which picker collects which lines in what order, how a pick becomes a packed and labelled parcel, and what has left on which vehicle.

It answers what is happening to stock right now, and where. How to compare warehouse systems against a single pick is the job of our guide to choosing warehouse management software; this article assumes the warehouse system can do its own job and asks how it should behave towards the ERP.

The two overlap more than a vendor comparison suggests. ERP suites can include serious warehouse execution: Microsoft’s Dynamics 365 Supply Chain Management uses work templates to direct warehouse workers’ devices and location directives to decide where that work sends them, so “an ERP cannot guide warehouse work” is not a general truth. The question for the meeting is who decides when the two systems disagree about one piece of work, and no scope table answers that.

Why “orders in the ERP, stock in the WMS” is not a boundary

That sentence describes where two kinds of record sit. It says nothing about who decides when one of them has to change, and a change is exactly the moment the two systems have to agree.

Any handoff between the commercial order and warehouse work has to keep three things apart. A request is something one system asks the other to do, and it can be refused. An accepted instruction is what the picker sees on their device. A confirmed result is what physically happened, which may differ from both: the instruction said 24, the picker found 23 in the location, and 23 left.

The boundary works when every message across it is plainly one of the three, carries the reference of the work it concerns, and names which system gets to decide.

Release is the moment ownership changes

Before a pick is released, the ERP can change the order as much as it likes, because no work exists yet. Reduce 24 to 18 at 08:55 and the pick that goes out at 09:00 says 18. Nobody in the warehouse ever knew it was 24.

Once the pick has been released there are two records in two systems: the order line in the ERP and the pick in the warehouse system. From this point a change to one is a message to the other. If the ERP writes 18 over 24 in its own order table at 09:40, it has changed a number in a database. The picker’s device still says 24, the picker is still walking to the location, and 24 will still be packed. The ERP has recorded a wish, and unless something turns that wish into an accepted instruction on the floor, the warehouse completes the work it was given.

That is why a commercial change after release is a request to the warehouse and not an update of it. The warehouse is the only party that knows how far the work has got.

The change contract

A change request after release travels with the reference of the released pick and asks the warehouse to accept it. The warehouse decides against its own state, and the decision depends on how far the pick has progressed.

If nothing has been picked, the warehouse accepts and re-issues the pick at the new quantity. If part has been picked, it accepts, closes the pick at the new quantity with what has already been picked counted towards it, and puts back anything picked beyond the new quantity by a recorded stock move. If everything has been picked, packed and labelled, the warehouse’s own rule decides: accept with a repack task, or refuse because the parcel is about to be collected. If the goods have already been dispatched, the warehouse refuses with that reason, because the change no longer belongs to the pick at all; it belongs to returns and credits.

Whatever the warehouse decides, the ERP records the accepted outcome and not the requested one. A refused request stays visible as refused, so that customer service can see it and have the conversation with the customer, rather than finding out from a delivery note.

One change carried through four states

Everything below is illustrative: one product, one line, one pick, and none of the multiple lines, split picks, back-orders or stock ownership rules a real operation adds. A distributor’s ERP releases a pick of 24 units to the warehouse system at 09:00. At 09:40 the customer rings and reduces the order to 18. The same request arrives at the warehouse in four different states of the pick.

In the second row the surplus never left the shelf, because only 10 had been picked when the change arrived and all 10 count towards the 18, so no return-to-stock task is needed. Had 20 been picked, 2 would go back to their location by a recorded move, and the stock quantity moves with them. In the third row the decision is the warehouse’s to make and the business’s to configure: a rule that allows repacks up to a set time before collection is legitimate, and so is one that refuses them, provided the outcome is recorded where customer service can see it.

Ordered, shipped, cancelled and outstanding stay the ERP’s job throughout. The six units are a cancellation of the promise, and our order fulfilment guide explains how those quantities behave on the customer’s side of the same change.

The failure the contract prevents

Now remove the contract. The ERP simply stores 18 at 09:40, and the warehouse, which was never asked anything, keeps picking 24. At 10:15 a customer service colleague looking at the ERP confirms to the customer that 18 are coming. Later that morning the picker, looking at the pick, dispatches 24.

Finance now invoices from one of two records. If it invoices from the order, the customer is billed for 18 and receives 24, and the business has given away six units it will find missing at the next stock count, if at all. If it invoices from the shipment, the customer is billed for 24 and disputes it against the 18 they were promised on the phone, with the call log on their side. Both screens were valid on their own terms. They disagreed because a change was recorded in one place as a fact when it should have crossed to the other as a request.

Confirming what left the building

When the warehouse dispatches the goods, it sends a shipment confirmation carrying the quantity that left and the reference of the pick it completes. If 18 leave, the confirmation says 18 against that pick, and the ERP moves shipped to 18 on that order line.

Messages between systems get retried, because networks fail and queues back up. If the same confirmation is sent twice, the ERP has to recognise the reference and treat the second copy as the same event, so shipped stays at 18 and never becomes 36. This is what people mean when they call a message idempotent: sending it twice has the same effect as sending it once.

If the warehouse system in turn hands work down to an execution or control layer inside the building, the same discipline of request, acceptance and confirmation applies between those layers, and our guide to WMS, WES and WCS covers it.

What to test before you sign

Run the same test against every candidate, whether it is the ERP’s own warehouse module or a separate WMS. Release one order. Change its quantity after release in each of the four states above, and watch three screens each time: the picker’s device, the ERP order, and whatever customer service would look at. The picker should only ever see an accepted instruction. The ERP should show the accepted outcome, and a refusal should appear as a refusal with its reason. Then send the shipment confirmation twice and check that shipped did not double.

Ask two questions the demonstration will not volunteer. Who owns the stock quantity while a pick is open: the ERP, the warehouse system, or both with a reconciliation nobody has written down yet? And when a cycle count finds 23 where the system said 24, which system is corrected first, and how does the other one find out?

Then write your own boundary down before you sign anything. For every point where a decision crosses from the commercial order to warehouse work or back, name the reference that travels with it, the party that accepts it, and the event that confirms the result. In the example there are four such points. Release carries the order line reference; the warehouse accepts it by issuing the pick; the picker’s first scan confirms that work has begun. A change carries the pick reference; the warehouse accepts or refuses it; the re-issued pick, the repack task or the recorded refusal confirms the outcome. Shipment carries the pick reference back; the ERP accepts it; your dispatch event confirms what left. A count correction carries the location and the product; whichever system you have decided owns stock while a pick is open accepts it; the corrected quantity appearing in the other system confirms it. The list fits on a page, and each row is something the vendor has to show working.

When one suite is enough

If the ERP’s warehouse module already directs the actual task at the level of the location and the scan, and your team trusts how it behaves when an order changes mid-pick, staying in one suite has a real advantage. The change contract above becomes a configuration question inside one system, with one reference and no message to lose. That should be demonstrated with the 24-to-18 change before a separate WMS is considered.

A specialist WMS is the right choice when the warehouse’s execution needs exceed the module: automation, wave and zone picking, high SKU counts, or throughput the module cannot direct. Even then, the vendor should show the change contract working against the ERP you already run, in each of the four states, before anything is signed. In both cases the integration behaviour is the buying decision, and it is evaluated before signature rather than sorted out afterwards.

Where Keel fits

Keel is an operations platform shaped around how a business runs its warehouse work and how it handles changes to that work. For the warehouse team in the example, that means the current pick and the requested change appear together on one screen, and whoever decides to accept, repack or refuse records that decision under their own name. The picker’s device shows whatever was accepted; the raw request never reaches it. The ERP receives the accepted result and, later, the confirmed shipment against the same pick reference. When the business changes its rule, for example allowing repacks up to thirty minutes before collection instead of refusing them, the rule and the screen the team works in change together.

Keel supports tailored operator tools, workflows that combine human steps with processing, and business rules expressed in code. An implementation of this example has to define and test the connection to the ERP, how a change request is acknowledged and its outcome returned, which system owns stock quantities while a pick is open, how duplicate messages are recognised, and how results are reconciled when something is missed. Those are designed, built and tested for this business and this ERP. Keel does not ship a WMS, a connector to any named ERP or a ready-made change contract, and Keel is not automatically the master of any record; the ERP can and usually should remain the commercial system of record. Keel leads the implementation and agrees the handover with your team.

Keel is not the answer if your ERP’s warehouse module already directs the task at the scan and your team trusts its change behaviour, which you should see demonstrated first. Nor is it the answer if a specialist WMS can show you a documented and tested change contract against your ERP, or if changes after release are rare enough that “ring the warehouse and hold the pick” is a rule that works. Keel is the right conversation when the warehouse work needs to run your way, the change and confirmation rules need to be your own and keep changing as the operation does, and the ERP needs to stay the commercial system of record throughout.

If you would like to talk it through, bring one order change that crossed your ERP and warehouse boundary and went wrong, or one you fear would. We can talk through which warehouse and boundary responsibilities a Keel implementation should own and whether Keel fits.