Insights · 12 min read
An order management system connects your sales channels to your fulfillment network. What a custom OMS contains, what it costs, and when buying makes sense.
By GGP Editorial
Most e-commerce operators don't set out to build an order management system. They hit a wall instead. Orders arrive from a website, two marketplaces, a wholesale portal, and a retail counter, each in its own tool, and none of them aware of what the others sold. Stock counts drift. A customer buys an item that is already gone. A return takes three emails and half a spreadsheet to resolve.
An order management system (OMS) is the software that fixes this. It sits between your sales channels and your fulfillment network, takes every order no matter where it came from, checks what is available, decides where to ship from, tracks the order to the door, and handles the return when it comes back. This guide is for operators, founders, and operations leads deciding whether to build one, what it should contain, and what it costs.
An OMS is not a storefront and it is not a warehouse system. The storefront belongs to your e-commerce platform, the pick-and-pack belongs to your warehouse management system, and the money belongs to your accounting software. The OMS is the layer between all three. It owns the order from the moment a customer confirms it to the moment it is delivered, refunded, or returned.
An order is not one event. It is a sequence: capture, validate, allocate inventory, route to a warehouse or store, pick, pack, ship, deliver, and sometimes return. Every step can fail, and the OMS is where the failures get caught and corrected. A customer service agent changes a shipping address after payment. A warehouse runs out of the item and the system has to source it from a store across town. A carrier loses a parcel and the order has to be rebuilt. None of that lives in your checkout page.
The value is rarely the order record itself. A database table can hold an order. The value is the decisions the system makes around it: which location fulfills this order, what you promise the customer about delivery, and what happens when reality breaks the promise.
You can split an OMS into a set of modules. Not every business needs all of them, but the list is consistent across industries.
| Module | What it does | Why it matters |
|---|---|---|
| Order capture and validation | Pulls orders from every channel and checks payment, address, and stock before accepting | Stops bad orders from entering the system |
| Inventory visibility | A real-time view of stock across warehouses, stores, in-transit, and on-order | Lets you sell only what you can actually ship |
| Order routing (DOM) | Decides which location fulfills each order using rules for cost, speed, and stock | The core of omnichannel fulfillment |
| Order promising | Estimates a delivery date before and at checkout | The promise routing then has to keep |
| Fulfillment orchestration | Sends the order to the right place and tracks pick, pack, and ship | Turns a decision into physical work |
| Returns management | Handles return requests, restocking, refunds, and exchanges | Often the most manual and most neglected part |
| Payment and settlement | Validates payments, captures funds, and reconciles with the ledger | Keeps the books honest as orders change |
| Customer service tools | Lets agents see and modify orders after purchase | Where order issues actually get resolved |
| Reporting | Order volume, fill rate, delivery performance, exceptions | The part operators and finance actually read |
A single-channel seller shipping from one warehouse needs the first four and not much else. A retailer selling online, in stores, and through marketplaces with ship-from-store and returns needs all of them. The module list should follow how you actually sell, not a template.
The term you will hear when you research OMS is distributed order management, or DOM. It is the routing engine. When an order comes in, the DOM engine looks at inventory in every warehouse, store, and dropship supplier, then picks the fulfillment source that best fits the rules you set. Cheap to ship, fast to deliver, protecting a low-stock store for walk-in customers, whatever the rule is.
DOM is what makes buy online pick up in store and ship-from-store possible. It is also where most of the engineering goes, because the rules are where your business logic lives. A retailer with 200 stores and three warehouses is not running a hardcoded if-statement. It is running a rules engine that re-scores every order against live inventory, carrier rates, and promised delivery dates, and does it in under a second.
If your plan is to grow into multiple channels or locations, design the routing layer as its own component from day one. Bolting DOM onto a system that assumed one warehouse is a rewrite, not an upgrade.
Packaged OMS tools are genuinely good. Manhattan Active Order Management, KIBO, Fluent Commerce, and Salesforce OMS cover standard omnichannel retail well, and most ERPs have an order module built in. If you run a conventional retail operation selling standard products through standard channels, buying is usually the right call. We tell prospects this directly, and it is the short version of our custom software vs SaaS comparison.
The fit breaks in predictable situations.
Deep integration with systems you already run. If your orders need to flow through a custom ERP, a warehouse system you built, or a point of sale you own, a packaged OMS usually means middleware, sync jobs, and manual export. The integration cost can exceed the license.
An unusual business model. Packaged OMS tools are built around B2C retail. B2B quoting, account-specific contract pricing, subscriptions, mixed wholesale and direct-to-consumer, or consignment all strain them. You end up working around the tool rather than with it.
Specific routing or fulfillment rules. If you fulfill by rules no vendor ships out of the box, for example a medical supplier that routes temperature-controlled orders differently, you are back to building.
Cross-border and multi-currency. If you sell across countries with different tax, currency, and carrier rules, no single vendor module covers every jurisdiction cleanly. We cover the same problem in a different domain in our article on cross-border payment platforms. The principle is identical: the regulation drives the architecture.
Cost at scale. License and per-order fees compound. When the annual license plus integration maintenance exceeds what a build costs over a few years, and you want to own the data and the roadmap, building starts to make sense.
None of these is a reason to build for its own sake. Each is a specific gap a custom build closes.
A build is not a table of orders with a status column. The order table is the easy part. Here is the real work.
An OMS lives or dies on its order and inventory model. You need orders, line items, fulfillments, inventory positions, reservations, and returns modeled so that an order can be split across locations, partially shipped, and partially returned without corrupting the numbers. This is the part that is hardest to change later, so it is worth the time up front. The same discipline applies to any enterprise software project.
Most of an OMS build is not the OMS. It is the connections to everything around it: the storefront or marketplaces, the ERP, the warehouse system, carriers for shipping labels and tracking, payment providers, tax calculation, and any third-party logistics partners. Each is its own API integration with its own edge cases, timeouts, and rate limits. Budget for this honestly; it is where projects go over.
An OMS that checks inventory once an hour will oversell the moment two channels sell the same last unit. You need a near-real-time view of stock across locations, with reservations so a confirmed order holds its stock until it ships. This is usually the second-hardest engineering problem in the project. We wrote about the inventory side of this in our inventory management software guide.
Routing rules, order promising, and exception handling are your actual product logic. These have to be configurable by your operations team, not hardcoded by developers, or every rule change becomes a ticket.
Returns, cancellations, partial shipments, and address changes are where the manual work hides. A system that handles the happy path beautifully and falls apart on the exception is not finished.
AI in order management is real but optional. The useful cases are demand forecasting for replenishment, routing decisions that weigh live carrier rates, and exception detection that flags an order likely to miss its promise before the customer complains. You can read where these fit in our AI automation guide. None of this is required for a first version. Get the routing and inventory right first, then layer AI where it pays.
An OMS is not priced per feature. The cost comes from the number of channels and integrations, the routing complexity, and how much real-time inventory data you are handling. Market ranges across development shops look like this:
| Scope | What it includes | Typical range |
|---|---|---|
| MVP | Order capture from one or two channels, single or dual warehouse, basic inventory, one carrier integration, manual returns | $40,000–$80,000 |
| Mid-tier | Multi-channel capture, DOM routing across warehouses and stores, returns, two to four integrations (ERP, WMS, carrier, payment) | $80,000–$200,000 |
| Enterprise | Multi-country, multi-currency, buy online pick up in store and ship-from-store, custom rules engine, AI routing or forecasting, many integrations | $200,000+ |
These are market ranges, not a quote, and the spread is wide because the scope is. The main drivers:
For a fuller picture of where the money goes in a custom build, our custom software development cost guide walks through it, and the piece on reducing development costs covers the levers.
A focused MVP with one or two channels and a single warehouse can ship in three to four months. A full system with DOM routing, returns, several integrations, and multiple locations typically runs six to twelve months. The integrations and the inventory model are the two things most likely to stretch the timeline, so start them early.
Market ranges run roughly $40,000–$80,000 for an MVP, $80,000–$200,000 for a mid-tier system, and $200,000 and up for an enterprise platform. The number depends on channels, integrations, routing complexity, and returns, not on a flat per-feature price.
An MVP typically ships in three to four months. A full system with DOM routing, returns, and several integrations usually takes six to twelve months.
If you run conventional retail with standard channels and products, buy. If you have deep integrations with your own systems, an unusual business model, specific routing rules, cross-border requirements, or license costs that compound at scale, building is worth evaluating. The question is whether the gaps in a packaged tool cost more per year than the build.
A warehouse management system runs the physical warehouse: receiving, putaway, picking, packing, and shipping inside the four walls. An OMS runs the order lifecycle across channels and locations and decides where an order should be fulfilled. They connect, and many companies run both, but they solve different problems.
An e-commerce platform tracks orders from its own channel. The problems start when you sell in more than one place, or need to route orders across warehouses and stores, or handle returns centrally. That is when a dedicated OMS, or OMS logic, becomes necessary.
At minimum your storefront or marketplaces, your warehouse system, and a carrier for shipping. Most businesses also integrate the ERP for finance, payment providers, tax calculation, and any third-party logistics partners.
GlobeSoft is a software development company founded in 2018, with 40-plus engineers and more than 300 delivered projects for over 100 clients across the US, Brazil, South Africa, and Singapore. We build custom software, e-commerce and retail platforms, ERP and warehouse systems, and the integrations that connect them, on a stack that includes Java, Spring Boot, Go, Python, React, Vue, and Node. Our delivered work includes self-ordering restaurant POS systems, financial management systems, and property and retail platforms. We communicate in English and Portuguese and run overlapping working hours with clients, so you get a named contact and a real timezone overlap rather than an email queue.
If you are planning an order management system, or deciding between building and buying, we can help you define the scope, architecture, timeline, and a realistic budget before you commit.
Tell us what you are building and where you are today. We typically reply within 24 hours.
