Which System Should Own Fulfillment: Your Storefront, Your ERP, or an OMS?

Three systems can each plausibly claim fulfillment: the storefront that captured the order, the ERP that holds the financial record, and an order management system between them. Most comparisons argue about which one is capable of routing an order. That is the wrong axis, because all three are. What actually differs is what each one can see, and what it costs you to move the decision somewhere else. Put the decision wherever the full picture already lives, and go in clear-eyed about the reconciliation you take on if you move it.

When does this question actually arrive?

Not at a revenue threshold. It arrives when you add the second place stock can ship from.

Before that, one thing is worth clearing up: even a single warehouse makes sourcing decisions. Ship now or backorder, ship partial or hold complete, dropship or pull from stock, cancel the line. What a second location adds is the specific question of which place, and that is the one that cannot be answered in two systems at once without them disagreeing.

In most companies nobody chose which system answers it. The answer was inherited from whatever was installed first, and it gets examined only when it starts producing visibly wrong results.

What "source of truth" actually means here

The phrase gets dismissed too easily. It does not mean "the only system holding order data", because all of them will hold a copy. It means which copy wins when they disagree, and that is a real operational question you should answer explicitly. It is also a separate question from who routes. You can perfectly well have the ERP own the authoritative financial record while something else decides where the box comes from, as long as you have decided which one wins on each field and how conflicts get resolved. Skipping that conversation is what produces the daily reconciliation pain of a three-system stack.

What each system can actually see

The storefront

Shopify models fulfillment as a fulfillment order carrying an assigned location, and its documentation is explicit that this is where the answer lives: you can fetch "the assigned location of a given group of unfulfilled line items to determine where fulfillment should occur".

Behind that is a real routing engine. Shopify's order routing "works by applying a series of rules to an order and then prioritizing locations based on the results", with a default sequence that minimizes split fulfillments, then stays within the destination market, then ships from the closest location. That sequence is a default rather than a fixed law, and merchants can change it. The documentation is candid about the mechanics: distance is straight-line rather than driving distance, which "might occasionally differ from what you might expect", and where two locations share an address "the older location is prioritized".

Two things are usually missed about the storefront option. First, the scope limit is softer than it looks, because many retailers pull marketplace and wholesale orders into the storefront through channel integrations, at which point those orders are visible to its routing like any other. Second, when the defaults run out, custom routing logic can run on the platform itself: Shopify supports order routing apps that "provide a way for merchants with complex or highly custom needs to take control over their fulfillment and delivery strategy needs", built with Shopify Functions. That is a genuine option for keeping the decision where it already is, not a reason to leave.

The ERP

The common claim that an ERP cannot route is simply out of date, and worth correcting because it is the argument most often used to sell against one.

NetSuite's Automatic Location Assignment "lets you configure NetSuite to assign fulfillment locations automatically to sales order lines". It queries Supply Allocation to find which locations have inventory and when, weighs allocation strategies and available-to-promise lead times, and then assigns "the best location based on the ALA configuration and rules", with backorder rules for when no location can serve and options spanning subsidiaries.

That happens on the sales order, upstream of the item fulfillment record. The item fulfillment, which "you must create" to fulfill an order, is the record of a decision already made, sitting in the order-to-cash chain alongside billing, payments, returns and collections. So the honest framing is not that the ERP is architecturally unfit to route. It is that routing in an ERP is a configuration you either turned on or did not, and a great many implementations never did, because the project scope was finance and the stores came later.

An order management system

This is the category defined by the job, which is a definition rather than a discovery, and worth stating plainly instead of dressing up. The practical case for it is scope: it is built to sit across channels and locations rather than to serve one of them. That argues for it when your orders and locations genuinely span more than one system, and argues for nothing at all when they do not.

So how do you actually choose?

One question does most of the work: which system already sees every order and every location, without somebody exporting something?

Then two honest follow-ups.

Does the system you have in mind see stock positions you trust? This one gets abused. A new routing layer inherits exactly the same store counts as the old one. If store inventory is wrong, that is a counting and shrink problem, and no routing architecture fixes it. Solve it first, or you will have bought a faster way to make confident wrong decisions.

And how fast does the decision need to be? Real retail is mixed: a delivery promise at checkout, final sourcing at release, exceptions worked overnight. Speed alone does not point at any particular system. Storefronts route in milliseconds; the batch tendency is a property of how a given implementation was configured, not of double-entry accounting.

What breaks in each case

When the storefront owns it, the failure is scope. Orders it never captured are outside its view, so it commits stock to the demand it can see while the rest waits. That is real, but check whether your channel integrations already close the gap before treating it as decisive.

When the ERP owns it, the failure is usually that the allocation layer was never configured, or that store-level detail is not modelled at the granularity fulfillment needs. Both are fixable inside the ERP, and fixing them is often cheaper than adding a system.

When an order management system owns it, the failures are the ones vendors write about least. You now have a second inventory position that can drift from the ERP's, and reconciling them becomes somebody's standing job. You own integration mappings for every channel and location, permanently. You have added a component that, on the peak weekend, is a new single point of failure between the order and the warehouse. Routing rules accumulate until nobody can explain why a given order went where it did. And some of the logic will duplicate what your warehouse system already does. None of that means do not do it. It means price it honestly, because these costs are real and they are recurring.

The thing all three models leave out

Routing is not a decision, it is a proposal. In any real store network, the store can reject it: the unit is damaged, already sold, or nobody has time today. Mature ship-from-store runs an accept-or-decline loop with a time limit, and rejected orders re-route. If a system cannot take a rejection and try again, it does not matter how good its first choice was. Ask about that behaviour before anything else, whichever system you are evaluating.

The practical answer

Let the storefront capture, let the ERP hold the financial record, keep the warehouse system doing the physical work, and put the routing decision wherever the full picture already lives. Frequently that is a system you already own and have not finished configuring. Sometimes it is a dedicated layer, and then the case rests on scope rather than on sophistication.

OmniOrders is an order management system for brands and retailers selling through many channels. The wider pattern of several systems each holding part of the picture is covered in how omnichannel fulfillment works and the order management platform overview, and the rules themselves in which location should ship the online order.

Whatever you choose, write it down. The costly version of this is not picking the wrong system, since most of these decisions are reversible at some price. It is leaving it unowned, so that the rule lives in one person's head and nobody discovers the dependency until the day they are away.