Most companies running distribution at scale hit the same wall at the same point: going from one warehouse to two, or two to five. It doesn't matter what you ship. Auto parts to dealers, FMCG to retail chains, chemicals to industrial buyers, components to assembly lines. The complexity shows up the same way.
The wall isn't logistics. Logistics scales: add trucks, add shifts, add capacity. The wall is decisions.
With one warehouse, fulfillment is simple. An order comes in, you check stock, you ship. There's no choice about where to ship from, no question about which location should hold which SKU, no split shipment, no stock transfer, no regional demand pattern to weigh.
Add a second warehouse, and every order becomes a decision. Which location has stock? Which one is closer to the customer? Which has the lower freight cost? If neither has full quantity, do you split the order, transfer stock, or backorder? If stock is two days out at one location but available now at the other, which wins?
None of these questions are hard on their own. But multiply them by hundreds or thousands of orders a day, and a planning team ends up spending most of its time on routine calls that shouldn't need a human at all.
Splitting an order across two warehouses isn't just a freight decision. It's a cost decision with several moving parts at once. It splits pick and pack costs, potentially doubles packaging, and creates two delivery touchpoints for the customer instead of one.
Sometimes splitting is the right call. Sometimes waiting for a stock transfer is cheaper overall. Getting this right means weighing the full cost picture, not freight in isolation.
Each system in a typical distribution stack does its job well. None of them sit across all four and make the fulfillment call:
ERP handles transactions. It knows what was ordered, what was invoiced, what's on the books, not which warehouse should fulfill an order.
OMS handles order lifecycle. It knows order status, customer commitments, delivery promises, not whether stock should come from Location A or B, or whether a transfer beats a split.
WMS handles warehouse execution. It knows what's on the shelf, what's being picked, what's being packed at that warehouse, not what's happening at the others.
TMS handles transport. It knows routes, carriers, freight costs, delivery times, not whether an order should wait for incoming stock or ship partial from two locations.
That gap between the four systems, the decision layer, is what companies fill today with planners, spreadsheets, and phone calls. It works at small scale. It breaks at large scale.
Making a good fulfillment decision requires pulling four kinds of data into one place.
Not just what's in one warehouse. What's available across all locations, what's reserved, what's soft-allocated, what's incoming from suppliers, what's in transit between warehouses, and what's physically present but held for quality or other reasons.
Available-to-promise (ATP) sounds simple. It isn't. Upstream data from ERP and WMS is often delayed, batched, or inconsistent. A decision layer has to work with the best available picture while accounting for that uncertainty, not pretend the data is perfect.
Who's the customer, what cluster or region do they belong to, what's their priority tier, what type of order is this, and what's the acceptable delivery window.
What it costs to ship from each location, transit times by lane, and rates across shipment modes.
Which warehouse serves which region, which SKUs are assigned to which locations, and what the thresholds are for splitting an order versus transferring stock versus backordering.
This is the hardest part in practice, because rules conflict. A customer-priority rule says ship from the nearest warehouse; a SKU-assignment rule says that part only lives somewhere else. An order-type rule says expedite; an inventory rule says the stock is soft-allocated to another order. A decision layer needs to resolve rule priority and conflicts explicitly, not just apply rules in sequence and hope for the best. And because rules get tweaked constantly as the business learns, the system needs to absorb that change without collapsing into a pile of exceptions.
Most companies already have this data. It just lives in four different systems with no single view across them.
Fulfillment gets the attention because it's customer-facing, but the same gap exists in replenishment.
Once you run multiple warehouses, supplier schedules can't be a single consolidated number anymore. Each location needs its own demand forecast, its own firm schedule, its own safety stock calculation.
Supplier performance, OTIF, lead time accuracy, rejection rates, needs to be tracked at a level granular enough to actually inform procurement decisions, feeding live into which supplier gets what share of the next schedule release, not sitting in a quarterly report. Measuring this well is harder than it sounds: are you comparing PO promise date against goods-receipt date? How are partial deliveries handled? Do you trust supplier-reported dispatch dates, or only actual receipt? Getting the definitions right matters as much as the tracking itself, and most teams skip that step.
Inbound logistics, pickup scheduling, route consolidation, coordination with suppliers, needs to account for which warehouse the stock is headed to, not just which supplier it's coming from.
The data and systems already exist here too. What's missing is the same thing: a layer that connects them and makes the call.
Pando has run transportation management at scale for a while. Rate matrices, route optimization, carrier allocation, freight cost tracking. That's the core of the product.
The data that drives those transport decisions turns out to be the same data multi-warehouse fulfillment decisions need. Freight cost from Warehouse A versus Warehouse B, transit time to the customer, carrier availability. These aren't separate problems. They're the same problem at different points in the order lifecycle.
So Pando is building an orchestration layer that sits on top of ERP, OMS, WMS, and TMS and handles the decisions those systems weren't designed to make: which warehouse fulfills which order, when to split, when to transfer, when to backorder, how to balance stock across locations, and how to schedule suppliers at the warehouse level.
The advantage: the freight and logistics master data, rate cards, consignee profiles, depot configurations, transit times, already lives in Pando. Nothing is replicated or approximated. The fulfillment decision runs on the same data the shipment execution uses, with no sync lag and no translation layer. The integration patterns with ERP, OMS, WMS, and supplier systems aren't new either. Pando has built and run these connectors across customers in auto, FMCG, chemicals, and manufacturing, and has seen the edge cases in high-volume distribution, inbound logistics, and multi-channel order receipt before.
If you're running a single warehouse and plan to stay that way, you probably don't need this. Your ERP and WMS are enough.
If you're running multiple warehouses, or about to, and your planning team spends more time on routine order routing than on actual exceptions, the decision layer is what's missing. The systems you have aren't the problem. They just need something sitting across them that can make the call.
Which warehouse receives a return, and where refurbished stock goes, is a related but different problem. Companies that try to solve forward and reverse flow at the same time tend to end up shipping neither well. Get the forward flow working first.
Pando is working with a few companies on this right now. If routine order routing is eating time, your planning team should be spending on exceptions, get in touch to talk through how we're approaching it.