Ecommerce order management system: what an OMS does that your store and your warehouse don't

An ecommerce order management system is the least well-understood product in this market, because three different systems all behave as though they own the order.

Your storefront thinks it does — it took the money, it has an order list, it sends the confirmation email. Your warehouse system thinks it does — it has the pick list and it knows what shipped. And the OMS is the thing that actually owns it, from the moment the customer pays to the moment the parcel is delivered or the refund clears, across every channel you sell on.

While you have one sales channel and one place you ship from, you do not need one, and the storefront's order list is fine. The moment there are two of either, nothing owns the order and everything is reconciliation.

This is what an OMS actually does, the one concept it is built around, and how to tell whether you have reached the point of needing one.

The concept the whole product rests on

Available-to-sell is a computed number, not a count.

If you take one thing from this page, take that. A physical count tells you what is on the shelf. It does not tell you what you can sell, because some of what is on the shelf is already promised to orders that have not shipped yet, and some of what you can sell is not on the shelf at all — it is on a container, or sitting with a fulfilment partner.

A serious system tracks at least six separate quantities, and one of our own build-offs produced a system doing exactly this:

On hand — physically in your possession.
Reserved — promised to orders that have not yet shipped.
Sellable — on hand minus reserved. This is the number the storefront must publish.
On order — bought from a supplier, not yet arrived.
In transit — moving between your own locations.
At partners — held by a 3PL or a marketplace's own fulfilment network.

Publish the wrong one to your channels and you either oversell, which costs you a customer and a marketplace metric, or you under-sell, which costs you the margin on stock sitting idle.

Let sellable go negative

A detail worth stealing. In one of the builds we audited, if you promise more than you hold, the sellable figure goes negative instead of quietly showing zero.

That is the correct behaviour and it is rare. Clamping to zero hides the fact that you have oversold by nine units — the screen looks calm, and the problem surfaces when the picker cannot find the stock. A negative number is a visible, actionable statement that somebody needs to decide which customers get theirs.

What an OMS actually does

1 · Captures orders from every channel into one shape

Each channel has its own idea of an order: different identifiers, different address formats, different tax handling, different states, different timing on when payment is confirmed. The OMS normalises them so everything downstream deals with one shape.

The requirement that gets missed: the original channel order reference has to stay on the record permanently, because every customer service conversation and every marketplace dispute starts with that number, not yours.

2 · Allocates stock to orders

Which physical units, in which location, satisfy this order? This is where reservation happens, and it is the step that makes the sellable figure move.

Allocation has real policy in it — nearest location, cheapest shipping, avoid splitting the parcel, prefer the location with slower-moving stock — and the policy is business-specific. It is also where partial allocation lives: two of three lines available now, and a decision about whether to hold the order or ship what you have.

3 · Routes fulfilment

Which of your locations, or which 3PL, actually picks it. Split shipments when no single location can fill the order. Re-routing when the first choice turns out to be short.

This is the capability that justifies an OMS on its own for anyone shipping from more than one place, because doing it by hand is a person making a hundred small decisions a day, inconsistently.

4 · Runs the order's state machine

Not a status field. A state machine with defined transitions and refusals.

An order is placed, paid, allocated, picked, packed, shipped, delivered — and along the way it can be held, part-shipped, cancelled, returned, refunded or written off. The system's job is to know which transitions are legal. A cancelled order cannot then be shipped. A refund cannot exceed what was paid. A return cannot be accepted against an order that never shipped.

We have watched this go wrong in adjacent builds: one storefront allowed a cancelled order to be shipped until its own hostile testing caught it. Status-as-a-field cannot express any of this, which is why the distinction matters.

5 · Handles returns as several separate decisions

The single most common modelling error in this category is treating a return as one event. It is at least three:

The goods came back (or did not).
They are resellable (or damaged, or need inspection).
The customer gets money (all of it, some of it, or store credit).

Those three are separate decisions made at different times by different people. A system that collapses them will restock damaged goods automatically, or refund before anything arrives. One of the storefronts we audited got this right explicitly: accepting a return never quietly restocks or refunds by itself.

6 · Surfaces exceptions

This is the part that is actually the product, and the part no demo shows. Every order that is stuck, short, failed, held for fraud review, undeliverable, or waiting on a decision needs to be in a queue somebody works.

An OMS with no exception queue is a database. The orders that flow through without incident do not need software; the ones that do not are the entire reason you bought it.

Idempotency, or why you shipped that order twice

Every integration in this stack delivers events more than once. Payment webhooks retry. Marketplace APIs re-send. A network timeout means your system does not know whether its own request succeeded, so it tries again.

If your OMS is not idempotent, the result is duplicate orders, double allocations, and — the expensive one — the same parcel shipped twice.

The requirement: every inbound event carries an identifier, and processing the same identifier twice has no additional effect. The same applies to your own outbound calls to a 3PL or a carrier.

Related, and from the same family of failure: in the builds we audited, the strongest ones made every stock movement reversible and recorded — every reserve, ship and cancel written as a movement that can be undone — and made changes atomic, so an operation either fully happens or does not happen at all. A partial write in an allocation is how one unit ends up reserved to two orders.

Where the OMS stops and shipping begins

A recurring source of duplicated effort, and worth drawing the line explicitly because two products both claim this ground.

The OMS decides what ships, from where, and when. A shipping or carrier tool decides how — rate shopping across carriers, buying the label, printing it, and handing over the manifest. Most businesses need both, and the integration between them is a short, well-defined handover: the OMS says "this parcel, these contents, this address, this service level", and gets back a tracking number.

Three things about that handover are worth specifying, because they are where it goes wrong.

The tracking number has to travel back to the channel, quickly. Marketplaces require tracking upload inside a stated window, and missing it damages the seller metrics that determine whether you keep selling there at all. This is not a nice-to-have integration — on some channels it is a condition of trading. If the tracking number lands in your shipping tool and reaches the marketplace when somebody remembers to export a CSV, you have an operational risk rather than an inconvenience.

A parcel is not an order. One order can be several parcels, from several locations, on different days, with different carriers. Each needs its own tracking number, and the customer needs to be told once about the order rather than three times as though they had bought three things. A system that models one tracking number per order will misrepresent every split shipment you make.

Address validation belongs before allocation, not at the label. Finding out the address is undeliverable at the moment you print is finding out after you picked and packed. Validating at order capture turns a wasted pick into a customer service message.

The failure mode when this boundary is fuzzy is mundane and expensive: two systems both think they own fulfilment state, one says shipped and the other says picking, and the customer service answer depends on which tab is open.

When you actually need one

You do not need an OMS when you have one channel and one shipping location. The storefront is your OMS, and adding another system is a cost with no benefit.

You need one when two or more of these are true:

You sell on more than one channel and they share a stock pool.
You ship from more than one place — two warehouses, a shop and a warehouse, or a 3PL plus your own stock.
You have oversold more than once, and it was not a counting mistake.
Somebody's job is reconciling systems. If a person spends hours a week making two order lists agree, that person is your OMS, and they are more expensive and less reliable than software.
Returns volume is material and you cannot answer what happened to a specific returned item.

The sharpest single test: ask how long it takes to answer "where is this customer's order and what is happening to it". If that takes more than a few seconds and involves opening two systems, you have found the gap.

Buy or build

Buy if you are a reasonably standard multi-channel retailer. There are mature OMS products and mid-market platforms that include one, and the allocation and routing logic they ship covers most businesses.

Build when your allocation or routing policy is genuinely yours — unusual fulfilment arrangements, consignment, made-to-order mixed with stocked lines, contractual delivery commitments — or when the OMS products that fit are priced for businesses several times your size, which is a real gap in this market between the cheap tools and the enterprise ones.

Six ecommerce inventory systems were built from a single specification by three coding models, and five run as live demos. What the audits found is worth knowing before you commission anything:

The strongest tracked all six stock quantities across two locations and two channels, with permissions enforced on the server, and its channel connections admitted when they were not connected rather than pretending — which is the honest behaviour and rarer than it should be.
One had the best-looking interface of the set and, as delivered, existed only in the browser: no server, nothing saved, no real sign-in. Refreshing the page wiped every change. It was rebuilt properly over four rounds.
One shipped with two roles that had never actually been tested — every visit signed you in as the owner, and the second role could be invited but never used.
One had a security check that was too strict once hosted and refused to let anyone sign in at all.

None of those is a missing feature. If you build, specify the six quantities, the state machine with its illegal transitions, idempotent event handling, atomic writes, and real server-enforced roles — because "build me an order management system" produces an order list.

The evaluation checklist

Show me sellable, and tell me which quantities it was computed from.
Oversell deliberately. Does the number go negative, or clamp to zero?
Cancel an order, then try to ship it.
Send the same payment webhook twice.
Split one order across two locations.
Accept a return without refunding, then refund without restocking.
Show me the exception queue and who works it.
Ask where a specific order is, and time the answer.

If you are not yet sure whether you need this, an inventory system or a warehouse system, what is a warehouse management system draws the line between the three. If the problem is one stock pool across several sales channels, multi-channel inventory management covers that specifically. And if your stock problem is a shop rather than a warehouse, what a retail inventory management system includes is the counted inventory for that shape.

And if you are building, the Ecommerce Inventory planner is the specification we hand our own agents. One note on that page, since this article has quoted audit findings rather than market counts: this is the one planner we publish without a cited feature ledger, flagged as unverified, because its research is a machine first pass we have not finished checking. We would rather show the gap than print numbers we cannot stand behind.