WMS vs OMS: orders vs warehouse execution

An OMS is the central order book. It pulls orders from online stores, marketplaces, sales reps and B2B portals into one queue, checks payment and fraud status, and decides where each order should ship from based on stock, distance or cost. It tracks the order's status from the customer's point of view and handles changes: a new address, a cancelled line, a split shipment, a return request.

Its inventory view is broad but shallow. It needs to know how many units are sellable at each location so it doesn't promise stock that isn't there. It doesn't need to know which shelf they are on.

An OMS also serves the customer-facing team. When a customer calls about a late order, customer service looks it up in the OMS, sees which location has it and what state it is in, and changes or cancels it there. That only works if the warehouse reports progress back promptly.

Once an order reaches a warehouse, the WMS decides exactly which units will fill it. This step, order allocation, picks specific bins, lots and license plates according to rules such as earliest expiry first or pick-face first. The WMS then groups orders into pick lists, sorts them by walking route and directs order picking with scans at each step.

Packing verifies each item against the order, captures weight and carton size, and produces labels and documents. The WMS reports back what shipped, what was short and the tracking details, so the OMS and the customer see the real result.

The WMS also owns the timing inside the building. It works to carrier cut-off times, puts urgent orders first and handles short picks: if a bin turns out to hold fewer units than expected, it can reallocate from another location, ship what is available and hold the rest, or flag the order for a decision.

Both systems allocate, which is where most confusion comes from. They allocate at different levels.

For example, a customer orders six bottles of olive oil, SKU OIL-008. The OMS sees 40 sellable units in the main warehouse and 12 at a second site, and routes the order to the main warehouse. That is a location-level decision. Inside the building, the WMS finds 18 units of lot LOT-0826 expiring in three months in bin A-01-02, and 22 units of a later lot in overflow. It reserves six units of LOT-0826, so the oldest stock ships first.

If the OMS's sellable number is stale, both decisions go wrong. Say 10 units of the old lot were moved to quarantine an hour ago after a leak. The WMS knows, but if that change never reached the OMS, the OMS keeps selling stock that can't ship, and orders end up on backorder. The fix is to make the WMS the source of physical availability and push changes to the OMS as they happen.

Match the system to where your problems are. If orders are late because they sit in the wrong queue or ship from the wrong site, look at order management. If they are late or wrong because of what happens inside the building, look at the WMS:

• One warehouse and one or two sales channels: the storefront's own order screens act as a light OMS. A WMS is where the value is.
• Several channels feeding one warehouse: a WMS that accepts orders by API or integration, plus accurate stock sync back to each channel.
• Several warehouses, stores or 3PLs and many channels: a dedicated OMS to route orders, with a WMS in each building you run yourself.
• You outsource all fulfillment: an OMS or storefront on your side, and the 3PL's WMS on theirs.

The integration has a clear shape. Orders, order edits and cancellations flow down from the OMS to the WMS. Allocation results, pick and pack progress, shipments, tracking numbers, returns received and stock changes flow back up.

Two rules prevent most problems. First, one system owns each fact: the OMS owns the customer order and the WMS owns physical stock. Second, changes should be pushed as events rather than polled once a night. Webhooks, which send a message the moment something changes, are the usual way to do this. Also agree on what happens when an order is edited after picking has started, because that is where the two systems most often disagree. Before picking, an edit is simple. After picking, a reduced quantity means units must go back to a bin; after packing, a changed address may mean a new label; after dispatch, it becomes a return or a reship. Write down which system decides in each case and what message it sends.

NextStock is a WMS with solid order handling for a single organization. It takes sales orders through the web app, CSV import or the API, allocates automatically or manually with FEFO, whole-LPN and pick-face-first rules, and supports backorders. After an order is created you can change the address or quantities, split remaining demand, reship, or cancel after picking with guided restock. It does not route orders across channels and locations the way a dedicated OMS does.

To connect an OMS or storefront, use the REST API and webhooks. Native Shopify, WooCommerce and Salla connectors are planned and not available yet; the integrations page lists current status.