Quick answer: An order management system (OMS) is the software that takes every order from every channel (web, app, store, marketplace, call centre), decides where and how to fulfil it using a single real-time view of inventory, and orchestrates picking, shipping, collection, returns and the customer communications in between. It is the operational engine of unified commerce. Decision rule: if you promise customers inventory across more than one location or channel, you need OMS capability, whether bought, built or embedded.
Australian and New Zealand retailers spent the first half of the 2020s adding channels: click and collect, ship from store, marketplaces, social commerce, same-day delivery. Most did it by bolting features onto an ecommerce platform and a store POS that were never designed to share inventory or orders. The result is familiar: online says "in stock" while the store shelf is empty, a click-and-collect order is cancelled four hours after it was placed, a return bought online cannot be processed in store, and three teams run three spreadsheets to reconcile what was sold where.
Unified commerce is the response, and the order management system is where it becomes real. This guide is for retail, ecommerce, supply chain and technology leaders in large retailers and brands who are deciding whether and how to invest in OMS capability, and what to expect.
What is an order management system, and what does it actually do?
An OMS sits between the channels that capture demand and the systems that hold and move stock. Its core functions:
- Order capture and consolidation. One order record regardless of channel, with consistent statuses customers and staff can see.
- Available-to-promise (ATP) inventory. A single, near-real-time view of sellable inventory across distribution centres, stores, suppliers (drop-ship) and in-transit stock, with safety buffers so you do not sell the last unit twice.
- Order orchestration and sourcing. Rules and optimisation that decide where each order line is fulfilled from: nearest store, lowest cost, best margin, oldest stock, split or not split, carrier choice.
- Fulfilment execution. Pick, pack and ship tasks for stores (store fulfilment apps), handoff to the warehouse management system for DC orders, carrier and label integration.
- Collection and delivery management. Click and collect, curbside, lockers, ship-to-store, same-day, scheduled slots.
- Returns and exchanges. Any-channel returns with disposition, refund and restock logic.
- Customer service view. A single pane for order lookup, modification, cancellation and appeasements.
- Post-purchase communication. Status, delays, ready-for-collection and return notifications.
The phrase distributed order management (DOM) usually refers to the orchestration and sourcing layer specifically: the intelligence that treats the whole network as one warehouse.
How is an OMS different from an ERP, a WMS or an ecommerce platform?
This is the most common confusion in OMS projects, and it determines whether you buy, build or extend.
- Ecommerce platform (web/app storefront) — Owns: Catalogue presentation, cart, checkout, payment capture, promotions · Does not own: Network-wide inventory truth, store fulfilment, cross-channel returns, sourcing logic
- POS — Owns: In-store transactions and store stock movements · Does not own: Online orders, cross-channel orchestration
- ERP — Owns: Financial record, purchasing, master data, often inventory of record at a ledger level · Does not own: Real-time ATP across channels, order orchestration, customer-facing status
- WMS — Owns: Execution inside a warehouse: receiving, putaway, picking, packing · Does not own: Which location should fulfil, store-based fulfilment, customer promise
- OMS / DOM — Owns: Cross-channel order lifecycle, ATP, sourcing, fulfilment orchestration, returns · Does not own: Storefront experience, financial ledger, in-warehouse execution
Ecommerce platforms and ERPs both offer "order management" features, and for a single-channel or single-warehouse business they may be enough. They stop being enough when you have multiple fulfilment nodes, stores acting as mini-warehouses, marketplaces as channels, or a promise ("collect in two hours", "delivered today") that depends on knowing precisely where stock is right now.
What is unified commerce, and how is it different from omnichannel?
Omnichannel retail describes the customer-facing ambition: a consistent experience across channels. Most retailers achieved it by integrating separate systems channel by channel, which is why it is brittle.
Unified commerce describes the architecture that makes omnichannel durable: a single source of truth for customers, products, inventory, orders and payments, with every channel reading from and writing to the same data in real time. Instead of integrating five systems' views of inventory, there is one inventory view that every channel consumes.
An OMS is the order and inventory component of that architecture. The others are a product information management system, a customer data platform or CRM, a unified payments layer, and the storefront and store systems that sit on top. Many retailers are moving toward composable commerce (best-of-breed components connected by APIs, often with a headless commerce front end) and the OMS is typically the first component they add, because inventory and order truth is where the customer pain is sharpest.
How does an OMS enable click and collect and ship from store?
Click and collect is one of the highest-volume retail searches in Australia and one of the most operationally unforgiving services. It depends on four things an OMS provides:
- Store-level ATP with buffers. Showing collectable stock only where store inventory accuracy is good enough, with a safety threshold (for example, do not promise the last two units) that can be tuned by category and store.
- Store fulfilment tasking. A simple app for store staff to pick, confirm substitutions or shortages, stage and hand over, with service-level timers.
- Customer communication tied to real status. "Ready for collection" triggered by the staging scan, not by a timer.
- Exception handling. Shortage at pick time rerouted to another store or the DC automatically, with the customer informed, rather than cancelled.
Ship from store adds the sourcing decision: whether to fulfil an online order from a store at all, and which one. Good orchestration balances delivery speed, shipping cost, store labour capacity, stock age and markdown risk, and the probability that the store can actually find the item. Retailers that turn on ship from store without that logic often discover they are shipping full-price stock from their best-selling stores while clearance stock sits in a DC.
Both services expose inventory accuracy. If store stock records are 70 per cent accurate at the SKU level, no OMS will make click and collect work; RFID, cycle counting and disciplined store processes come first or alongside. Australian Consumer Law also bites here: cancelling confirmed orders because of inventory errors is a customer-experience failure and, repeated, a compliance one.
How do you choose and implement an OMS?
Build, buy or extend. Large retailers with strong engineering teams sometimes build orchestration on top of an inventory service; most buy a specialist OMS (several global and Australian-founded vendors compete here) or use the OMS module of a commerce or ERP suite. Choose on network complexity, promise ambitions, engineering capacity and how composable your architecture is becoming.
Requirements that differentiate vendors:
- Real-time inventory ingestion at your event volumes (POS sales, receipts, transfers, adjustments) with configurable buffers by location and category.
- Sourcing rules you can change without a vendor change request, plus optimisation (cost, speed, margin, capacity) where volumes justify it.
- Store fulfilment app usability on the devices your stores already have.
- Returns across channels with disposition logic.
- Carrier integrations relevant to Australia and New Zealand, including same-day and locker networks.
- Marketplace order ingestion.
- Open APIs and event streams so the OMS fits a composable or headless stack.
- Resilience: what happens to store trading and online promises when the OMS is unavailable.
Implementation realities. A first phase that delivers network ATP plus click and collect and ship from store for a pilot set of stores typically runs 6 to 12 months in a large retailer; full network rollout and returns extend it. The hard work is inventory data quality, store process change and integration with POS, WMS and ERP, not OMS configuration. Plan a store-operations workstream with the same seniority as the technology workstream.
In practice: a 300-store specialty retailer
A specialty retailer with 300 stores, two DCs and a growing marketplace business ran click and collect from the ecommerce platform's native feature, with store inventory synced nightly from the ERP. Cancellation rates on collect orders ran well above the industry norm and online "out of stock" messages were common on items the stores held. The programme introduced an OMS as the inventory and order source of truth: POS and WMS events streamed to it in near real time, ATP buffers were set per category (tight for fashion sizes, loose for replenished basics), and click and collect was enabled only for stores whose RFID-based counts exceeded an accuracy threshold. Ship from store was switched on in a second phase with sourcing rules that favoured stores holding ageing stock. Within two seasons, collect cancellations fell sharply, online availability rose, and markdown depth on ship-from-store categories reduced. The ERP remained the financial inventory of record; the OMS owned the operational, sellable view.
What does AI add to order management?
Three uses have moved from pilot to production in larger retailers:
- Sourcing optimisation that weighs cost, speed, labour capacity, markdown risk and carrier performance across thousands of orders an hour, rather than fixed rule hierarchies.
- Promise prediction: estimating delivery or collection times from real network conditions, which lifts conversion when the promise is credible and protects margin when it is not.
- Inventory accuracy inference: flagging store locations whose recorded stock is likely wrong based on sales patterns, shrink history and count data, and adjusting ATP buffers automatically.
The precondition for all three is the clean, real-time order and inventory data the OMS creates. Retail analytics and personalisation programmes benefit for the same reason: one order history per customer, regardless of channel.
Key takeaways
- An OMS owns the cross-channel order lifecycle and the real-time sellable inventory view; ERP owns the ledger and WMS owns warehouse execution.
- Unified commerce is an architecture (one source of truth per data domain), not a feature; the OMS is usually the first component retailers add because order and inventory truth is where customers feel the pain.
- Click and collect and ship from store depend on store-level inventory accuracy, buffers, store tasking and automatic exception handling; no OMS fixes inaccurate stock records.
- Choose vendors on real-time inventory ingestion, configurable sourcing, store app usability, returns, carrier and marketplace integration, open APIs and resilience.
- Plan the store-operations workstream with the same seniority as the technology workstream; integration and data quality, not configuration, set the timeline.
Join your peers at Clutch Events Retail and eCommerce Technology Summits 2027
Free-to-attend, invite-curated and built by practitioners for practitioners. Upcoming Digital Experience summits for retail and ecommerce leaders:
- Melbourne Retail and eCommerce Technology Summit 2027 — 19 August 2027
- Sydney Retail and eCommerce Technology Summit 2027 — 13 October 2027
See all upcoming events · More practitioner guides at Clutch Events Insights.