Order Management System: What It Owns, What It Does Not

Most brands buy an order management system a year after they needed one, or two years before they needed one. Both are expensive. The first mistake shows up as a team of people copying order files between seller portals every morning. The second shows up as a licence fee sitting idle because the brand has neither the volume nor the channel count to justify the software.

The confusion usually starts with vocabulary. Three systems get discussed as if they are interchangeable. They are not.

What an OMS owns, and what it does not

The ERP owns the financial record. Purchase orders, vendor bills, tax documents, costing, the general ledger, the statutory books. It is the system your auditor cares about. It is deliberately slow, because financial records are supposed to be deliberate. An ERP is a poor place to hold a stock number that changes forty times an hour.

The WMS owns the four walls of a warehouse. Bin locations, putaway, pick paths, packing stations, cycle count tasks, dispatch manifests, gate passes. It knows where a physical unit sits and who touched it last. It does not know or care which channel generated the demand.

The OMS owns the order lifecycle across channels, and the availability picture that sits above every fulfilment node. It answers three questions neither of the other two can answer alone. How much sellable stock exists in total. Which node should serve this particular order. What is the current state of every order, no matter where it was placed. Strip away the brochure language and an OMS is an allocation engine with a status ledger attached.

The single source of truth question

This is the only question that matters in the decision, and most evaluations skip past it. For inventory, exactly one system must hold the master number. Everything else consumes a copy.

In an Indian omnichannel setup the copies multiply fast. Amazon holds a number under FBA. Flipkart holds a number in its fulfilment centres. Blinkit, Instamart and Zepto hold stock inside dark stores that you cannot see or move. Your own website reads from a self operated warehouse. Offline distributors hold stock you have already invoiced. Some of that inventory is legally yours, some is not, and some is yours but physically unreachable.

So the honest design is not one pool. It is one master ledger with clearly typed buckets. Owned and reachable stock the OMS can allocate freely. Owned but committed stock, already promised to an open order. Placed stock inside a platform network that the OMS tracks but cannot allocate. Stock sold through, which only reconciliation can confirm. If a system cannot express that distinction, it will oversell within a fortnight, and the team will fix the oversell by holding buffers, and the buffers will quietly consume your working capital.

Allocation and sourcing rules

Once availability is honest, the OMS earns its keep on sourcing logic. A good rule set is small and readable. A bad one is fifty overlapping conditions nobody can explain when an order routes to the wrong city.

• Node priority by serviceability, so the closest node that can actually deliver the pin code wins.
• Split shipment policy, and whether the brand allows a split at all when one line is short.
• Cut off times by node, because a warehouse that closes at four cannot accept a five o clock order.
• Reservation windows, so stock is held for a defined period and released automatically if payment or confirmation fails.
• Backorder behaviour, including whether the channel is told zero or told a later promise date.
• Expiry aware allocation for food, supplements and cosmetics, so the oldest saleable batch leaves first.

Ask any vendor to demonstrate rule changes in a sandbox in front of you. If a routing change needs a support ticket and a release cycle, you have bought a project, not a product.

Questions to ask in evaluation

Skip the feature list. Ask these instead.

1. What is your stock sync interval per channel, and is it a full push or a delta push.
2. What happens when a channel API is down for two hours. Do you queue, retry, and reconcile, or do you silently drop the update.
3. How do you handle a partial cancellation from a marketplace after allocation but before dispatch.
4. Show me the returns flow end to end, including the physical grading step and the point where stock becomes sellable again.
5. Can I run two identifier schemes at once, our internal SKU and a channel specific listing identifier, without manual mapping files.
6. Where do serial numbers, batch codes and expiry dates live, and are they carried through to the invoice.
7. What does your GST invoicing support look like for multi state stock transfers and e way bill generation.
8. What is the exit path. Can we export the full order and inventory history in a usable structure.

Also ask for two live references at your scale in your category, and speak to the operations lead, not the founder.

When a brand does not need one yet

Plenty of brands do not need an OMS. If you sell on two channels, ship from one warehouse, and your 3PL panel already gives you order status, an OMS adds a layer without removing work. The panel your 3PL provides is doing the job. Buy time instead, and put the money into demand planning discipline.

The real trigger is not revenue. It is the number of independent fulfilment decisions you make per day. When a human is deciding which node ships which order more than a few times daily, and getting it wrong often enough to matter, the rules need to live in software. That is the moment. Three or more nodes, four or more channels, and a returns volume large enough to need its own grading step is the usual shape.

One last discipline. Sequence the implementation. Get the item master clean first, then availability, then allocation, then returns, then reporting. Brands that try to switch on everything in one weekend spend the next quarter unpicking it.