Split order fulfillment: what has to be true before the software can decide

By Yitz Lieblich, Founder and CEO, SkuNexus. In eCommerce since 2007, founded SkuNexus in 2018, hands-on in hundreds of warehouses.

The order that cannot ship in one box

Here is the workflow as it runs in most operations today, in the words buyers use for it.

An order lands from the storefront. Someone opens it. They see five line items. Two are in the main warehouse. Two sit at the second location that opened last year. One is a vendor item nobody stocks. So they make a decision: ship the two now, hold the rest, and email the vendor. Then they key that decision into whatever system holds the shipment records, usually twice, because the storefront wants to know too.

Garrick at Zero Breeze described the same loop on his demo call. His stock is split across a direct-to-consumer warehouse and a business-to-business warehouse, and a bundle often cannot go under one label. In his words, they go into the ERP and manually split it into shippable quantities. In peak, he said, one order would have to be split three times.

That is the workflow. It is not stupid. A person doing it is applying real judgement about stock, distance, cost and what the customer will tolerate. It works fine at low volume, and it is genuinely faster than configuring a rule when you split two orders a week.

Where the hand-off breaks

The break is not the splitting. It is the decision, and specifically it is the decision made twice.

The first failure is arithmetic. One person can hold the stock picture for two locations in their head. At three locations plus a handful of vendors, they cannot, so they start defaulting: always ship from the main warehouse, always dropship the vendor item. Defaults are rules, just bad ones, and nobody wrote them down.

The second failure is the record. Once the split exists in someone's head and on a picking slip but not in the order system, every downstream system disagrees. The storefront thinks the order is open. The accounting system has one invoice. The customer gets one tracking number for a parcel that is half of what they bought.

The third failure is what happens under load. This is the one buyers actually feel. Jeff Cayley runs three eCommerce brands out of three warehouses in California, Nevada and Pennsylvania, and his incumbent could only connect one storefront to one account. The result was not slow splitting. It was no splitting: he was limited to fulfilling out of one location, because the system could not see the other two. You cannot split across locations your order system does not know exist.

What has to be true before any software can fix this

This is the part that gets skipped in demos and then blows up in implementation. Routing software does not create these conditions. It consumes them.

Stock has to be known per location, not in total. A single available number for the whole company cannot answer "can this order ship from Nevada". If your current tool holds one quantity per SKU, no routing rule will help until that changes.

Vendors have to be records, not email addresses. If a dropship item is fulfilled by a person sending a message, the split cannot be automated. The system needs a vendor record to assign the line to a vendor instead of a warehouse.

One order has to be allowed to carry several fulfillments. This is a data model question, not a feature question, and it is settled by how order management systems handle allocation. If the system treats order and shipment as the same object, a split is modelled as two orders, and now your reporting, your returns and your customer's inbox all disagree with each other.

The condition you split on has to be expressible. Buyers rarely want "nearest warehouse". They want something like: business-to-business orders go to the B2B location, print-on-demand lines go to the vendor, everything else tries the main warehouse first. If the rule language cannot say that, the rule engine is decoration.

Where the decision actually gets configured

Three ways to get this decision out of a person's head, ordered by how far the buyer has to move.

Stay in the storefront or the channel app. Best fit when the split is always the same shape, for example one print-on-demand vendor handled by an app that claims its own lines before anything else sees them. Sarah at Firecrown had exactly that: orders were split off to the outside vendor before her order system ever saw the whole order. Where it breaks down: the app owns the rule, so the rule cannot consider your other locations. Not the right call if the split depends on stock you hold, and if that stock sits in more than one place the real constraint is multi-location inventory on Shopify, which no channel-side app is positioned to solve.

Push it into the ERP you already run. Best fit when the ERP is already the inventory record and the split logic is simple. Where it breaks down: Garrick's team was in the ERP doing the split by hand, which tells you the ERP held the data but not the decision. Not the right call if you are about to pay for custom ERP development to express a fulfillment rule.

Move the decision to a rules-driven order platform such as SkuNexus. In SkuNexus this lives under Settings, Order Routing, and it is worth being specific about the mechanism because "rules engine" means very little on its own.

Rules are evaluated in priority order and the first matching rule wins. A rule carries a name, a priority, condition groups built from order attributes such as order value, SKU, shipping method and customer type, a strategy for selecting the warehouse, and the fulfillment methods it is allowed to use: ship, pickup or drop-ship. The engine runs either automatically when an order is imported or created, or manually when an operator clicks evaluate.

The output is a Decision Plan. The plan names which warehouses will fulfill the order, which method each uses, and which items go where when the order splits across warehouses. It moves from Draft to Confirmed to Executed, or is cancelled. Selecting a batch of orders and using Auto Decide routes them together.

Two things here matter more than the rule syntax. There is a rule simulator that evaluates a rule against sample orders before you activate it, and there is Dry-Run Routing on any order detail page that shows which rule would match, what it would assign, and which conditions failed on the rules that did not match, without changing the order. That is how writing the rules down stops being a gamble: an undocumented default becomes a written rule without betting a peak week on it.

Where it breaks down: someone still has to write the rules, and rules encode a policy decision your operation may not have made yet. Not the right call if nobody internally can say what the policy should be.

Splitting after the decision, at the line and at the bench

Automated routing handles the ordinary case. The exceptions are still manual, on purpose.

On the order itself, Split Item divides a line into two, for example ship three now and two later. Merge Items recombines lines that were split. Request Decision re-runs routing on the order after you have changed it.

At the pack bench, Partial Ship sends what is packed now and creates a new fulfillment for the remainder, and the order moves to Partial status: some items shipped, some pending. Rick's team at Snow Commerce described wanting exactly this, manual hold plus a quantity split, sitting on top of the automated vendor routing rather than replacing it. They split orders at the line level all the time.

Anything ordered beyond available stock becomes a backorder, tracked separately, fulfillable when receiving brings the stock in.

What your storefront sees while the order is in pieces

This is the setting that causes arguments, and it belongs to the connector, not the router.

Partial fulfillments can either be pushed to the sales channel as they complete, or held until the full order is fulfilled. Push early and the customer gets a tracking number for half their order and possibly a support ticket. Hold and the customer sees nothing for three days while two of the five items are already on a truck. There is no correct answer. There is only the answer your category can live with, and it is a configuration decision.

Christine at Manaup Hawaii went straight to the human version of this on her call: she asked whether there was somewhere to add notes so their buyer could tell the receiver about the split shipments. Cathy confirmed on the same call that they do split fulfillment. Order-level custom fields and tags carry that context.

Where this stops being an automation problem

Three honest limits, because a page that only lists capabilities is not useful to someone evaluating.

If no rule matches an order, it does not get force-routed. It stays unrouted and lands in the Review Queue for someone to handle. That is correct behaviour and it also means an incomplete rule set turns into a manual queue, which is what you were trying to escape.

Once a fulfillment has gone through the hospital queue for a short pick or a damaged item, short picks and partial shipments are blocked for that fulfillment. The exception path is deliberately narrower than the happy path.

None of this predicts anything. Routing decides where to ship what you have, right now. It does not forecast demand, and it will not tell you that the Nevada warehouse is about to run out.

What the demo corpus actually says about this

Being precise, because the number matters and a wrong one has cost this site before.

Across 78 buyer-eligible demo transcripts, 8 buyers raised order splitting or order routing in their own words. Counting every speaker on those calls, including our side demonstrating it, the figure is 25 of 78. The buyer-only number is the honest one for a claim about demand.

When it comes up, it comes up hard. Phoebe, evaluating on behalf of a merchant part-shipping from own stock and part-shipping from suppliers on Magento, called being able to split inventory a core need her incumbent could not meet. Megan at Casson Hardware described a single order spanning warehouse stock, dropship and receive-then-ship, needing to split each item per vendor. Jupiter Chevrolet described in-stock, special order and dropship in any combination, down to the individual unit.

That is the shape of the problem. It is rarely "split this in half". It is "this one order is three different fulfillment strategies at once".

If that is your order, the fastest way to find out which of the three conditions your data already meets is to bring a real split order to a demo and watch it route, dry-run first, before anything changes.

Frequently asked questions

How does order routing decide which location fulfills an order?

Rules are evaluated in priority order and the first one whose conditions match wins. A rule matches on order attributes such as order value, SKU, shipping method or customer type, then applies a warehouse-selection strategy and the fulfillment methods it is allowed to use: ship, pickup or drop-ship. The result is a Decision Plan naming the warehouses, the method for each, and which items go where if the order splits. If nothing matches, the order stays unrouted rather than being forced somewhere wrong.

Can a single order become more than one shipment?

Yes, and that is the point of the order and fulfillment split. One order can carry several fulfillments, each with its own method, warehouse and label. The Decision Plan is where the allocation is visible before it executes. You can also split a line item manually on the order, for example ship three now and two later, and recombine split items if the situation changes.

What happens to the items that could not ship?

If some items are packed and others are not, Partial Ship sends the packed items now and creates a new fulfillment for the remainder. The order sits in Partial status: some items shipped, some pending. Quantity ordered beyond what is available becomes a backorder, tracked separately, and fulfilled when receiving brings stock in. One exception to know: after a fulfillment has been through the hospital queue, partial shipment is blocked for it.

How do I test a routing rule without risking real orders?

Two ways, both non-destructive. The rule simulator evaluates a draft rule against sample orders before you activate it. Dry-Run Routing, on any order detail page, shows which rule would match, the warehouse and method it would assign, and which conditions failed on the rules that did not match, without changing the order's state.