Order Management System
One order. More than one delivery.
A custom order system built around one confirmed order — the lines it contains, the fulfilment groups they split into, what has actually shipped, and why the order stays open until the last line resolves.
Order fileWeb store · A. MehtaOR-2048
Two of three lines have shipped and the customer has a tracking number. The order is not complete, and a system that said it was would be wrong in the way that generates the support ticket.
ILLUSTRATIVE INTERFACE · SAMPLE DATA
Checkout and orchestration
The storefront gets the order. This gets it fulfilled.
A checkout finishes with a confirmation email. That is the point at which the difficult part starts — deciding where every line comes from, in how many pieces, and what to do when one of those decisions turns out to be wrong.
- The storefrontCatalogue, cart, checkout.It knows what the customer chose and that the order was confirmed. Its record of the order is a receipt, not a plan.
- The order fileWhat must now happen.Lines, sources, fulfilment groups, exceptions, returns — the operating record from confirmation to resolution.
- The fulfilment systemsWhere the work is done.Stock, warehouses, carriers and finance, each authoritative for its own part and none of them for the order.
Which order sources are connected — a storefront, a marketplace, a counter, a B2B portal — is a scoping decision. We confirm what each one can expose before defining the connection.
What is an order management system?
A system that owns a confirmed order for the rest of its life: the lines it contains, the fulfilment source each line is allocated to, the groups those lines split into, the release to whoever picks and packs, the shipment and delivery state coming back from connected systems, the exceptions that change the plan, and the cancellations and returns that change the order. It is the stretch between checkout and resolution.
What is the difference between an ecommerce platform and an OMS?
An ecommerce platform focuses on the storefront and checkout; an OMS focuses on operational coordination after it. The platform knows what was bought and that payment was confirmed. The OMS decides where each line comes from, splits the order into fulfilments when it has to, tracks each one separately, and holds the single answer to what state the whole order is in.
When does the OMS take over from checkout?
At confirmation. Everything before that — browsing, cart, payment authorisation — belongs to the storefront and its payment provider. From the confirmed order onwards the question stops being "what does the customer want" and becomes "where does each line come from, and what happens when one of them cannot".
Lines and fulfilments
A fulfilment group is not something you create. It is what allocation leaves behind.
Two lines sourced from the same place travel together. A line with nowhere to come from travels alone, later, and is the reason the order is not finished. Nothing declares the groups — they are what the allocation produced.
F-01Ready to release
- 01Desk lampLocation A
- 02Cable setLocation A
UnallocatedAwaiting source
- 03Wall shelfNo source
How a source is chosen
- What each connected source reports it can supply for that line.
- The preference order the business configures — nearest, cheapest, primary location, a named source for a product class.
- Whether the business allows an order to split at all, or holds it until one source can take everything.
- A person, when the rules produce no answer and somebody has to decide.
The business sets the rules and the system applies them the same way every time. What it does not do is invent an allocation strategy of its own, predict the optimal warehouse, or claim a live view of stock it is not connected to.
Can one order split into multiple fulfilments?
Yes, and handling that properly is most of what an OMS is for. Lines sourced from the same location become one fulfilment; lines that cannot be sourced there become another. Each group is then released, picked, shipped and tracked separately while the order keeps one identity and one state derived from all of them.
How is a fulfilment source chosen?
From what each connected source reports it can supply, filtered through the preference rules the business configures — nearest location, primary warehouse, a named source for certain products, or whether splitting is allowed at all. Where the rules produce no answer, the line waits for a person rather than being assigned to something arbitrary.
Can it support multiple warehouses and locations?
Yes — multiple fulfilment locations is the normal case, and it is what makes allocation a decision rather than a formality. Each location is a source the system can allocate against, using whatever it is connected to for availability, and the split follows from that.
Partial and complete
Two of three lines shipped is not a shipped order
One group is moving and the customer has a tracking number for it. The other has no source. The order is partial — and every system downstream of this one, from support to finance, needs that to be the answer rather than a rounded-up version of it.
One group shipped
- F-012 linesShipped
- Unallocated1 lineAwaiting source
2 of 3 lines fulfilled
Order statePartially fulfilled
Every line resolved
- F-012 linesDelivered
- F-021 lineShipped
3 of 3 lines fulfilled
Order stateFulfilled
The order state is derived from every open line, so no group can complete the order by finishing first. That is arithmetic, not a status somebody remembered to update.
Exceptions
The plan changes. The record of the old plan does not disappear.
A source that accepted a line can turn out not to have it. Reassigning is easy; the mistake is rewriting the order so it looks like the first decision never happened, which leaves nobody able to explain the delay.
- 12:04Line 03 allocatedLocation B accepted the line.
- 12:18Location B could not supplyReported back from the connected source.
- 12:20Exception openedLine 03 returned to awaiting source. The order became partial.
- 12:24Line 03 reallocatedLocation C accepted the line.
What needs a person right now
- OR-2051Line awaiting allocationOrder ops
- OR-2057Warehouse rejected the releaseWarehouse
- OR-2062Shipment state has not movedOrder ops
- OR-2070Return received · financial handoff pendingFinance
Does one shipment being delivered mean the order is complete?
No. Order state is derived from every open line, so an order with one group delivered and another awaiting a source is partially fulfilled — not complete. Treating the first shipment as the end of the order is how a customer gets a delivery confirmation for a parcel that contains half of what they bought.
Can an order be partially fulfilled?
That is the normal case, not the edge case. Lines are fulfilled as their sources become available, the order carries a partial state until every open line resolves, and each group keeps its own shipment and delivery state so support can answer which part is where.
Can the system hold an order until it can ship complete?
Yes, where the business wants it that way — whether an order may split at all is a rule you set, not a behaviour we assume. Some businesses split by default, some hold everything until one source can supply the whole order, and some decide per product class. The system applies whichever rule consistently.
Can a fulfilment source change after allocation?
Yes, and it frequently has to. The line returns to awaiting source, an exception is opened, and a new source is allocated — with the previous source and the reason it failed kept on the order. The current plan is what the system acts on; the earlier plan is what lets somebody explain the delay afterwards.
How are order exceptions handled?
As records with an owner and a state rather than as an alert that scrolls past. A rejected release, a stalled shipment, a line nobody can source and a return waiting on finance are all things a named team has to act on, and they sit on a list of what is stuck rather than inside an aggregate that says the day went well.
Can it manage cancellations?
A line or a whole order can be cancelled with a reason and, where the business requires one, an approval — and the cancellation is released downstream to whatever had already been told to fulfil it. What cancelling does not do on its own is refund money, return stock to a shelf or reverse anything in the books; each of those belongs to the system that owns it.
Returns and money
A return that has arrived is not a refund that has been paid
The parcel coming back is an operational fact this system owns. The money going back is a financial one it does not — and showing them as a single status is how a customer is told they have been refunded before anybody has refunded them.
What this system knows
- RequestedThe customer asked to return line 02.
- AuthorisedThe return was accepted under the business’s own policy.
- In transitWhere a connected carrier reports it.
- ReceivedThe item is physically back.
- ReviewedChecked against whatever condition rule the business applies.
What a different system decides
- Refund dueA commercial decision, following the business’s policy.
- Refund issuedExecuted by the payment provider that took the money.
- Credit or adjustmentWhere the sale runs through an invoice rather than a card.
- SettledConfirmed by the provider or the bank, never assumed here.
The order line reads returned as soon as it is back and checked. The financial outcome appears when the system that owns it says so — and until then the record says the handoff is pending, because that is what is true.
Does a returned order mean a refund is complete?
No. Return states are operational — requested, authorised, in transit, received, reviewed — and they describe where the goods are. A refund is a financial event executed by whichever provider took the payment, or a credit raised in a billing workflow. The order can show returned while the refund is still pending, and that distinction is deliberate.
Can it manage returns?
Yes, as states on the order line with the business’s own policy behind them: what may be returned, within what window, needing what authorisation, and what condition check applies on arrival. Where a carrier is connected, transit state comes back from it. What the system will not do is decide or execute the money.
Does it process refunds or payments?
No. It records what the payment or billing system reports and hands the return outcome to it. Charging, refunding, settling and reconciling belong to payment providers and to billing and accounting workflows — this system is where the order state lives, not where the money moves.
Where it sits
Five systems touch an order. Only one of them is accountable for it.
Each of these is authoritative for its own part and none of them for the order as a whole. That gap is what an order management system is: the place where one answer about one order actually exists.
The storefront gets the order. This gets it fulfilled.
- Ecommerce storefrontEcommerce storefront
- Owns catalogue, product, variant, cart and checkout — the customer’s buying experience up to confirmation. Its order record is a receipt; it has no way to express one order arriving in two parcels from two places on two days.
- Inventory managementInventory management
- Owns item, quantity, location, movement and reorder state, and answers whether stock is available somewhere. This asks that question and decides what happens to the order line as a result.
- Warehouse managementWarehouse management
- Owns execution inside the building — receiving, put-away, picking, packing. This releases a fulfilment group to it and takes the resulting state back; it does not pick anything itself.
- Fleet & logisticsFleet & logistics
- Owns the vehicle, the trip and the delivery run. Shipment and delivery state come back from it or from a carrier where connected — this page claims no tracking, no route optimisation and no live vehicle position of its own.
- Billing & invoicingBilling & invoicing
- Owns the invoice, its status and its balance. A return may raise a credit there; a B2B order may need a real invoice workflow. Neither makes the order record a billing record.
- POS & retailPOS & retail
- Owns the counter transaction. A store sale can be an order source, and a store can be a fulfilment source — both only where that integration is built.
- Payment provider
- Moves and settles money and executes refunds. Its confirmation comes back onto the order; nothing here charges or refunds anything.
What is the difference between an OMS and inventory management?
Inventory owns the stock: item, quantity, location, movement and reorder state. An OMS owns what happens to an order line as a result. Inventory answers "is there one of these at Location A"; the OMS answers "then this line is sourced there, it joins this fulfilment group, and here is what the order state becomes". They share the word availability and nothing else.
What is the difference between an OMS and warehouse management?
A warehouse system owns execution inside the building — receiving, put-away, picking, packing. An OMS owns orchestration outside it: which lines should be fulfilled, from where, in which groups, and what the order state is. The OMS releases a fulfilment to the warehouse and takes the resulting state back. It does not pick, pack or move anything itself.
Is an OMS the same as shipping or logistics software?
No. Shipping and logistics own transport — the vehicle, the trip, the label, the delivery attempt. An OMS owns the order those shipments belong to. Where a carrier or a fleet system is connected, its shipment and delivery state comes back onto the order line; the OMS is not the source of that state and does not claim to track anything itself.
Can it work across online, marketplace and store orders?
Orders from the channels a project actually connects can enter one operating model, which is what makes the order state meaningful across them. Each channel is a scoped connection against what that platform exposes and what the business is permitted to sync — the useful claim is one model for the channels you connect, not every channel by default.
Connect · migrate · choose
Most businesses should use the order tools they already have.
Commerce platforms, ERPs and established OMS products handle standard order flows well and come with marketplace and carrier integrations already built. If your operating model fits one of them, that is the better purchase and we will say so.
Use what you have when
- Standard channels and standard allocation logic already fit how you sell.
- The marketplace and carrier integrations you depend on exist there.
- Your ecommerce platform or ERP already orchestrates orders adequately.
- You need to be running in weeks with vendor support behind it.
- Standard order reporting answers your questions.
Build custom when
- Allocation and split rules are specific to your business and cannot be expressed.
- Several internal or proprietary systems have to agree about one order.
- Exceptions are being managed in spreadsheets alongside the real system.
- Ops and support need a view of the order that no existing tool produces.
- The operating model itself is the thing you are competing on.
The clearest signal is an operations team keeping a parallel spreadsheet to answer questions the order system cannot.
- 01What exists nowStorefront and marketplace exports, ERP or order exports, fulfilment records, shipment statuses, returns.
- 02Sample checkA representative set — clean orders, split ones, partially shipped ones, cancelled lines, returns with and without a financial outcome.
- 03Map the recordOrder, line, source, fulfilment group, shipment, return, and the states each of them can hold.
- 04Clean and normaliseChannel statuses reconciled into one vocabulary, duplicates merged, statuses that mean nothing retired.
- 05Import and verifyLoaded with open orders and history intact, and whatever did not reconcile listed rather than quietly accepted.
We check what each current system can export before defining the migration. Historical statuses arrive as a record of what a previous system said rather than as re-verified truth — channel status vocabularies rarely agree with each other — and anything that does not reconcile is listed rather than silently imported.
- Order sources and channels
- One storefront is a different build from a storefront, two marketplaces and a counter.
- Fulfilment locations
- One warehouse makes allocation trivial. Several make it the centre of the project.
- Allocation and split rules
- How much of the decision is rules, and how much is a person.
- Warehouse and carrier connections
- Each depends on what that system actually exposes and how it reports back.
- Cancellation and return logic
- Windows, authorisations, condition checks, and where the financial outcome goes.
- Billing and payment handoffs
- Whether orders need invoices, credits, or only a provider confirmation.
- Migration weight
- Opening with live orders is not the same as carrying years of order history.
- Volume, roles and reporting
- How much traffic, who sees what, and which questions the business needs answered.
Does every ecommerce business need an OMS?
No, and most do not. If your platform or ERP already coordinates orders adequately and the integrations you need exist there, adding another system makes things worse. An OMS earns its place when orders routinely split, when several systems disagree about one order, or when your operations team is running a spreadsheet beside the software to answer questions it cannot.
Can it connect to marketplaces and shipping providers?
Each connection is scoped against what that specific platform or carrier exposes and what the business is permitted to sync — order intake, status updates, label creation, tracking events. We confirm the interface before defining the connection rather than listing named providers as included capability.
Can historical orders migrate?
Orders, lines, fulfilments, shipments and returns can be mapped and loaded, and we check first what each current system can export. Channel status vocabularies rarely agree, so historical statuses are normalised into one model and imported as a record of what the previous system said — with anything that does not reconcile listed rather than quietly accepted.
Who owns the system and the data?
You do. Source-code access, hosting, data ownership, exports, handover and any third-party dependencies are defined in the project scope rather than assumed, and the data is exportable.
What determines the cost and timeline?
How many order sources and channels, how many fulfilment locations, how much of allocation is rules versus judgement, which warehouse and carrier systems connect and how they report back, how cancellations and returns behave, what the billing and payment handoffs are, how much history migrates, and what volume and reporting the business needs.
Selected work
Records, states and the interfaces people operate them in
An order file is a structured record with derived state and an operations interface on top of it, read under pressure by people answering a customer. These are three builds where exactly that was the deliverable.
Questions
Order management, answered
- What does order management software do?
- It owns a confirmed order until it is resolved: the lines it contains, where each line is sourced from, the fulfilment groups they split into, the release to whoever picks and packs, the shipment and delivery state from connected systems, the exceptions that change the plan, and the cancellations and returns that change the order.
- Is an OMS the same as an ecommerce platform?
- No. The platform owns the storefront and checkout; the OMS owns operational coordination after confirmation. The platform knows what was bought — it has no way to express one order arriving in two parcels from two locations on two different days.
- Can one order become more than one shipment?
- Yes, and managing that is most of what an OMS is for. Lines sourced from the same place become one fulfilment; lines that cannot be become another, released and tracked separately while the order keeps one identity.
- Does one delivered shipment complete the order?
- No. Order state is derived from every open line, so an order with one group delivered and another still awaiting a source is partially fulfilled, not complete.
- What happens when a fulfilment source cannot supply?
- The line returns to awaiting source, an exception is opened and a new source is allocated — with the failed source and the reason kept on the order, so the delay can be explained afterwards.
- Does a received return mean the customer has been refunded?
- No. Return states describe where the goods are. The refund is executed by whichever provider took the payment, or raised as a credit in a billing workflow, and the order shows that handoff as pending until that system confirms it.
- Does it hold stock or run a warehouse?
- Neither. Inventory owns quantities and locations, a warehouse system owns picking and packing. The OMS asks inventory what is available, releases a fulfilment group to the warehouse, and records what comes back.
- Can it connect to marketplaces, carriers and ERPs?
- Each connection is scoped against what that system exposes and what the business is permitted to sync. We confirm the interface before defining the connection rather than listing named providers as included capability.
- Should we build a custom OMS or use what we have?
- Use what you have if your platform or ERP already coordinates orders adequately and your integrations exist there — that is most businesses. Build when allocation and split rules are specific to you, when several systems disagree about one order, or when operations is running a spreadsheet beside the software.
Start
Bring one week of orders, and the one nobody could explain
The fastest way to scope an order build is real orders with real complications in them. Bring a week of what came in, and the one support had to apologise for.
- Where your orders come from — a storefront, marketplaces, a counter, a B2B portal.
- How many places you can fulfil from, and how you decide which one.
- Whether an order may split, or has to ship complete.
- What happens when a location says it cannot supply after all.
- Who decides a refund, and which system actually pays it.