There is a particular kind of order that turns a good sales day into an afternoon of copy and paste. The customer filled one cart, paid once, and to them it is a single purchase. But the items inside it come from three different places: one your own warehouse holds, one a supplier makes to order, one a dropshipper ships direct. Now someone has to take that one order apart, decide which line belongs to which vendor, write out a separate order for each of them with only their items and the customer's address, send those off, and then, days later, gather the tracking numbers back and mark the right pieces of the order shipped. Shopify shows you the order. It does not split it, route it, or send it anywhere.

This is the quiet reality of running any store that fulfills from more than one source, and the merchant communities are full of the same question asked a hundred ways. How do I automatically send each supplier only their part of the order. Can Shopify split an order by vendor. Is there a way to email a purchase order to my dropshipper the moment a sale comes in. The answers underneath are always some version of not natively, use an app, or build it in a middleware tool. The merchant is not asking for anything unusual. They want the obvious thing: an order arrives, and each supplier automatically gets the slice of it they are responsible for.

To the customer it was one cart and one payment. To your back office it is three orders wearing a trench coat, and Shopify hands you all three stitched together and leaves the unpicking to you.

What Shopify does and does not do about splitting orders

Give Shopify credit for the part it does, because it is real and it confuses the conversation. Shopify does split fulfillment across your own stocking locations: if one warehouse does not have enough of an item, it can split that item's quantity across locations, and if a cart holds items that live in different locations it can create more than one fulfillment and offer split shipping at checkout. If your whole operation is a couple of your own warehouses, that machinery covers a genuine slice of the need, and it is worth setting your location priorities well. The trouble starts the moment a supplier who is not one of your own locations enters the picture, and for most multi-vendor and dropship catalogs that is every day.

The split it does is by location, not by supplier. Shopify decides where to fulfill from based on which of your locations has stock and how you ordered their priority, not on the rule you actually care about, which is that this brand of item is always made by that vendor and this other one always ships from the dropshipper. There is no rules engine for routing: you cannot tell Shopify to send anything tagged one way to supplier A and anything over a certain weight to the freight partner, and have it group the lines and act. Most tellingly, the vendor field is only a label. You can set a vendor on every product, and it is useful for filtering the catalog and grouping reports, but setting it notifies no one, generates no purchase order, and routes nothing. And there is no way to send a supplier the order: Shopify has no native action that emails or posts each vendor a document containing only their line items in the format they accept, so even after you decide the split, the sending is on you.

The purchase order Shopify never sends

The heart of multi-vendor fulfillment is a document Shopify does not produce: a clean purchase order per supplier, listing only that supplier's items, the ship-to address, and your reference, so they can pick, pack, and ship without seeing the rest of the order or the customer's payment details. Every supplier wants it a little differently, one takes a plain email, one wants a CSV, one has a portal, one still asks for something that looks like EDI, and reconciling those formats is exactly the work that does not scale. So the merchant becomes the router: read the order, split it in their head, build each supplier's version by hand, and send it. It is the same shape of problem as the tracking number you paste in by hand, only upstream. There, a supplier's message has to be read and matched back to the order; here, the order has to be read and split out to the suppliers. Both are reading and matching that Shopify treats as clerical and hands to a person.

And it does not end when the purchase orders go out. Each supplier ships on their own clock, so the order comes back to you in pieces: the warehouse tote today, the candle in three days, the made-to-order mug next week. Each piece is a partial fulfillment you have to record against the right line items at the right location, with the right tracking, so the customer sees an order closing part by part rather than one confusing dump of confirmations. Miss the matching and you either mark the whole order shipped before two thirds of it exists, or you leave lines open that were delivered a week ago.

◆ DATA The reason this is worth fixing is that the pain scales with your range, not your volume. Add one supplier to your catalog and you have not added one step, you have added a new destination that every future multi-item order might now have to be split toward, a new format to send in, and a new stream of tracking to match back. A store with six suppliers and a healthy mix of multi-vendor carts is doing this split-and-route dance on a large share of its orders, every one by hand, and because each order looks like a five-minute job it never gets prioritised into an automation, it just quietly becomes someone's whole morning.

Why the usual workarounds don't hold

Faced with a platform that shows the order but will not split it, merchants reach for a handful of moves, and each one gives back something you did not want to lose.

"I will just email each supplier by hand." The honest starting point, and the one that caps your growth. Reading every order, deciding the split, and building a separate message for each vendor works when there are ten orders a day and collapses at a hundred, and it is the first thing that breaks during a sale or a launch, exactly when the orders are busiest and a missed split becomes a customer who never gets half their box. You are the router, and a router that has to sleep is a bottleneck.

"I will use Shopify's multi-location split." The right tool for your own warehouses, and the wrong shape for suppliers. It splits by which location has stock, so it can hand a line to a location, but a location is not a vendor you can email a purchase order to, and it cannot route by the rules that actually decide who makes an item. You have automated the part that was already close and left the supplier routing, the hard part, untouched.

"I will set the vendor field and build a Flow." Reasonable, and it stops halfway. Shopify Flow can react to a new order and tag it, and on higher plans it can move line items between locations, but it has no action that groups the lines by supplier, builds a purchase order with just that supplier's items, and sends it to each one, then fulfills only their lines when tracking returns. Flow can notice that a multi-supplier order arrived. It cannot carry it across each vendor to done.

"I will install an order-routing app." Often the right call, and still a fixed rulebook bolted to your store. The good ones do split by vendor and send purchase orders, which is real progress and proof the native gap exists. But an app applies the rules you set in advance to every order the same way: it does not notice that this supplier has gone silent for two days, that this item is backordered and should wait rather than route, that this destination makes the usual dropshipper the wrong choice on cost, or that a rule would ship one item split absurdly across two places. It routes. It does not judge.

What the automation actually has to do

The real job is not "email supplier A their stuff." It is "take each order, group its line items by who actually fulfills each one, build the right purchase order for each supplier in the format they accept, send them automatically, then fulfill only their lines when their tracking comes back, keeping the customer informed once and pulling in a human only for the calls that are genuinely judgement." That is a read, a classification, a document build per supplier, a send, and a set of partial fulfillments that close over time. As a Dugong playbook, in plain prose, it reads like this: 

# trigger
On an order being paid

# steps
1. Read the order: line items with vendor, SKU, type,
   weight, the destination, and the shipping speed paid for
2. Group the lines by who fulfills each, honoring which
   location has stock, the destination region, and cost
3. Build one purchase order per supplier with only
   their items, the ship-to address, and your reference
4. Send each supplier their PO in the format they
   accept, and record the split against the order
5. Fulfill only a supplier's lines when their tracking
   returns, at the right location, as a partial
6. Tell the customer once what ships from where and
   when, not a confirmation per fragment
7. Hold an uncovered item, a backordered line, a bad
   split, or a silent supplier for a human

Seven lines. The compiler fills in the rest: reading the whole order rather than a single field, knowing which vendor owns each line even when the rule is a mix of vendor, type, weight, and destination, assembling each supplier's document in the exact format that supplier accepts, sending it the moment payment clears instead of when someone gets to it, and then patiently closing the order in pieces as each supplier ships, matching tracking to the right lines at the right location. The merchant never opened three windows to fulfill one order. They described how a careful operations lead would split the work, and let the compiler do it on every order, in the background.

◆ NOTE The trap here is treating routing as pure mechanics. Who makes an item is usually a rule, but whether to route it right now is a judgement: a backordered line should wait, not fire a purchase order the supplier cannot fill; a supplier that has not confirmed yesterday's orders should not be sent ten more into the void; a split that would send a single low-value item on its own freight leg may be worse than holding it for the next shipment. A router that only knows the rules ships all of those wrong. Knowing which orders to split cleanly and which to escalate is as much the point as the split itself.

Why this is a compiler problem, not an app problem

There are capable order-routing and dropship apps on the Shopify App Store, and a store that fulfills from many suppliers should look at one. But the thing that makes automatic splitting safe is not one more rules table. It is judgement about each specific order: does this line have stock at the location the rule points to, has this supplier been responsive this week, is this backordered item better held than routed, does this destination change the cheapest source, and would this split leave the customer with a needlessly fragmented delivery. Those answers change per order, per supplier, and per day, which is exactly what a fixed rulebook handles badly and a person handles too slowly to keep up with a growing catalog of vendors. It is the same reason knowing when to reorder from a supplier resists a single threshold: the right call lives in the specifics, not in one rule.

A natural-language compiler fits because multi-vendor fulfillment was never a single action. It is a read, a classification into supplier groups, a document build for each, an automatic send, and a chain of partial fulfillments that has to close cleanly as each supplier ships. You can describe the whole behavior in a paragraph. You could never keep up with it by hand across every multi-item order, every supplier format, and every stream of returning tracking. It sits in the same family as the pre-order that holds your whole order hostage, where one order carries two timelines that have to be pulled apart and shipped on their own clocks, and the second order that arrives before the first ships, where the right move depends on reading the specific orders rather than firing one blunt rule.

The workflow worth building this week

If you fulfill from more than one supplier, warehouse, or dropshipper, and you have ever taken a single order apart to send its pieces to three different places, this is the automation to set up now, because the work scales with the range of your catalog and grows silently every time you add a vendor. It pairs naturally with the fulfillment work we have written about, like the tracking number you paste in by hand, which is the return leg of this same flow, and the bad address that ships anyway, since a split order sent to a broken address multiplies the mess across every supplier, and it feeds the same flywheel as the Shopify automations no one builds, where the work that compounds is the part merchants never get to.

Describe it the way you would brief a careful operations lead: for every order, work out which supplier makes each line, send each of them a clean purchase order with just their items in the format they use, and as each one ships, fulfill only their lines and keep the customer in the loop, and bring me anything where an item has no supplier, a line is backordered, or a vendor has gone quiet. That is the whole brief. The compiler does the reading, the grouping, the document, the send, and the partial fulfillments, on every order. Your suppliers get exactly their part of each order the moment it is paid, and your customers get one clear picture of what is arriving from where, without anyone copying line items into an email again.

◆ READING If this resonates, two companion pieces: our dispatch on the tracking number you paste in by hand, the return leg where each supplier's tracking is matched back to the right lines, and the order tag you set by hand, where reading the whole order and acting on it beats a single blunt rule.

If you are a Shopify merchant who has built something that splits every order to the right suppliers and closes it out cleanly as each one ships without anyone copying line items, or you have a story about a multi-vendor order you have unpicked one too many times, the inbox is open: field-notes@dugong.live. We are collecting case studies for the next issue.