Reference
What an order
management system decides
Four categories of vendor sell something called an order management system, and they do not mean the same thing by it. A storefront's own order screen, a middleware router, a warehouse system's order module and an ERP's sales-order module all carry the name. A merchant searching the term is usually trying to work out which of the four they are missing.
The answer is easier to reach from the decision than the category. An order management system is the layer that decides which stock, from which location, fulfils which order — and holds that order's state from placed to settled. Everything else it does follows from owning that decision.
Every commercial relationship, declared
Shopify. StoreBuilder Ltd is a Shopify Partner and earns referral commission when a merchant moves to or upgrades a Shopify plan through the practice. That is a real financial interest in the platform recommendation, and it is stated here rather than on a page a reader may never reach.
Stok.ly. We hold an affiliate account with Stok.ly, who sell into the category this page describes. We have not delivered an implementation on it, and it is named below as an example of a pattern rather than as a recommendation or a delivered integration. When that changes, the change appears here in this paragraph.
No other order-management vendor pays us anything. Not Brightpearl, not Linnworks, not Veeqo, not NetSuite, not Khaos Control, not any tool named on this page. No referral fee, no commission, no rebate, no affiliate link, no sponsored placement.
Four systems, and the one that owns the promise
These overlap in the brochures and not in the building. The useful question is never which product is best — it is which of these four currently makes the allocation decision on your orders, because on most sites the honest answer is that nothing does, and it happens by accident of sequence.
The storefront
Takes the order and knows everything about it except where it will be fulfilled from. Shopify holds locations and can route, and for one channel and one location that is a complete answer. It has no view of an order that arrived somewhere else.
The warehouse system
Runs the building — bins, picking paths, packing, dispatch. It is expert on what happens after an order is assigned to it and deliberately incurious about how it got there. Asking a WMS to arbitrate between channels is asking the wrong floor.
The ledger
Values what happened after it has happened, in a form an accountant will accept. It is downstream of every decision on this page. Where that line falls, and the four reconciliations that break across it, is accounting and stock.
The order layer
Sits above all three and owns the promise: this unit, from this location, to this customer, in this priority. It is the only one of the four with a reason to know that a trade order and a website order want the same box.
Four things that break when nothing owns allocation
None of these arrive as an error. Each one arrives as a person doing a job by hand that nobody costed, and the job is usually invisible until the person taking a holiday makes it visible.
Two channels sell the same unit
Not because the sync is slow, though it usually is. Because a unit is only committed when something writes the commitment down, and a stock feed publishing an availability number is not a commitment. Whichever channel is asked first wins, and on a promotion both are asked in the same second.
The split decision is made by the picker
An order with two lines in two locations either ships as two parcels or waits for a transfer. That is a cost decision — two shipping labels against a delayed delivery date — and with no rule it is taken by whoever reaches the order first, differently every time.
Trade and retail compete blind
A wholesale order for forty and six website orders for one arrive against the same stock. There is a right answer and it depends on the margin, the customer and the replenishment date. Without a priority rule, the answer is whichever was keyed first.
Where is my order takes three systems
The tell that order state lives nowhere. Someone opens the storefront, the courier portal and a spreadsheet to answer one question, several times a day. That time is the running cost of not having an order layer, and it never appears on a quote.
The four routes, compared on what they cost you later
No prices in this table, deliberately. Licence cost is the smallest and most published number in the decision, and the figures that decide it — implementation, the mapping work when a SKU convention changes, the person who owns the integration — are specific to a catalogue and a channel mix. What generalises is where each route puts the logic, and therefore what it costs to change later.
| Storefront native | Middleware routing | Dedicated OMS | ERP sales-order module | |
|---|---|---|---|---|
| Where allocation logic lives | In the platform's own rules | In flows somebody authored | In the product, configurable | In the ERP, with the finance model |
| Adding a fifth channel | Only if the platform supports it | Another flow, and another to maintain | Usually configuration | A project, and often a partner |
| When a SKU convention changes | Contained | Every mapping is touched by hand | One mapping layer | Contained, but change-controlled |
| Where it breaks first | The second sales channel | The author leaving | A process the product did not anticipate | Speed of change, not capability |
| When it is the wrong choice | More than one place holds stock | Nobody in-house will own the flows | One channel, one location | The finance model is not the constraint |
Stok.ly, Brightpearl, Linnworks and Veeqo sit in the dedicated-OMS column; NetSuite and Khaos Control in the ERP column. They are named as examples of where a category sits, not as a shortlist — see the disclosure above, and what this reference does not yet contain below. How each physically connects to Shopify Plus, and where each connection type breaks, is the systems reference.
When you do not need one
One sales channel, one place stock sits, and orders in the low hundreds a month: the storefront's order screen is an order management system and it is a good one. Adding another is cost with no decision to make.
The threshold is not a revenue figure — it is the moment a second place holds stock, or a second channel sells it. That is when allocation becomes a decision somebody has to own, and it is worth naming before it starts being taken by accident.
Where stock truth should live in the first place, multi-location inventory and the WMS-versus-3PL decision are the operations side of the same question.
Stock and fulfilmentWhat this reference does not yet contain
The per-vendor rows — what each product does with partial allocation, how each handles a trade channel alongside retail, which connectors hold up under volume, and what each costs to run rather than to buy — are not written here.
We have not implemented against that field at this merchant size. The obvious page is a feature grid, and a reader cannot tell a matrix built from implementations from one built from vendor datasheets. Those rows appear named, dated and attributed as real implementations produce them.
The practical answer in the meantime is the diagnostic: which system makes the allocation decision today, whether anything writes the commitment down, and which of the four failures above is already being handled by a person.
Book the diagnosticTell us what is breaking
What the systems are doing now, and what you need them to do. We will tell you whether it is a platform problem or something cheaper.