Last Black Friday, a home-goods seller called me in for a rescue: their OMS had split a 5-line order into three parcels shipping from California, Texas, and New Jersey. The customer paid for one shipment; the company paid for three — and got a one-star review: "Five items arrived over three days, what a joke of a store." The owner asked: "Isn't the system supposed to pick the optimal warehouse automatically?" It did follow the rules. The rules were just configured three years ago, casually, and never touched since.
Multi-warehouse sourcing rules in an OMS are the kind of module where a misconfiguration bleeds money daily and a correct one earns no praise. Here's what dimensions the rules actually have, how to rank them, and the three most common misconfigurations I see in the field.
Rule one: distance first — but "distance" isn't straight-line distance
Nearly every OMS ships with "closest warehouse to the customer" as rule number one. Sounds right; the devil is in how "close" is computed. Using straight-line miles, an LA order might source from San Bernardino — 60 miles away on paper. But carrier pricing runs on ZIP-to-ZIP zones, and the actual charge can exceed sourcing from Phoenix.
The fix is to reverse-engineer from the carrier zone tables: import your main carriers' zone matrices into the OMS and sort by estimated freight cost, not miles. One client doing 3,000 orders a day cut monthly freight 9% with this single change. Real number, one sorting-logic edit.
Rule two: inventory depth — don't sell through your last unit
Distance without inventory awareness is the second-biggest trap. Warehouse A is closest, but the SKU has 2 units left, one already allocated to another pending order. An OMS that ignores available-to-promise shoves the order there anyway; picking comes up short, the order splits again, and the ship date explodes.
Sourcing rules need an inventory waterline: warehouses below safety stock (say, 7 days of sales) get automatically deprioritized, no matter how close. Set the waterline per ABC class — high for A SKUs, lower for C. Many OMS platforms support per-class waterlines, but implementations lazily set one number for everything, which is the same as setting none.
Rule three: cost isn't just freight
Mature sourcing rules compute a total: freight + warehouse handling + packaging differences. Example: an East Coast order costs $2 more in freight from the West Coast building — but the West Coast site is captive with $3 cheaper handling than the East Coast 3PL. Net: $1 saved. A freight-only rule picks wrong.
Sneakier still are 3PL fee schedules: multi-piece order surcharges here, oversize handling fees there. These have to be folded into the sourcing cost model, or the system routes every bulky order to the "cheap freight, expensive handling" building and the loss only surfaces at month-end reconciliation.
Rule four: delivery promises get their own lane
Orders with time commitments — premium shipping, TikTok Shop on-time dispatch scoring — need separate sourcing logic: pick the warehouse that can ship on time, not the cheapest one. Late penalties and account strikes cost far more than a few dollars of freight.
I recommend two rule templates: cost-optimal for normal orders, time-first for committed ones, with the OMS switching on order tags. One blended rule set for both always ends up failing at both.
Tuning in practice: priority order is a craft
These four rules execute in priority sequence inside the OMS. My recommended order: time-commitment tag → inventory waterline → total cost → distance as tiebreaker. Why: the promise is a red line; sourcing to a short warehouse manufactures an incident; cost is the daily optimization battlefield; distance only matters when everything above ties.
Tune one rule at a time, run a week, read the data: split rate, average freight, late rate. Read all three together. Split rate down but freight up means the waterline is too strict. Freight down but lates up means the time rule is being overruled by the cost rule. Two or three rounds and it converges.
One last thing — the fallback. There must be a "no warehouse can fulfill" path. When every building is short or the system chokes, orders can't vanish into thin air: route them to an exception pool for manual handling and fire a replenishment alert. I've seen a setup with no fallback where orders sat in the system four days; the customer had already been refunded before the warehouse knew. Perfect rules with a missing fallback equal zero.
Go check your OMS sourcing rules — when were they last tuned? If the answer is "at go-live," this article was written for you.
