How Brightpearl handles Shopify pre-orders.

Shopify packages every checkout as a single order. When a customer adds a wireless speaker (in stock) and a limited-edition case (pre-order, ships next month) to the same cart, Shopify creates one order with two line items. That order fires the orders/create webhook, which the official Shopify-to-Brightpearl integration consumes. Brightpearl receives the order and writes one Sales Order with two lines. So far, everything looks normal.

The problem is in what happens next. Brightpearl tries to allocate stock against each line. The wireless speaker line allocates fine. The case line finds zero stock available. Brightpearl marks the Sales Order release status as Pending and waits. The in-stock speaker, which could ship today, sits behind the case that ships next month.

Brightpearl’s order model assumes that an order is a single unit of fulfillment work. The platform was built for distribution and wholesale, where partial fulfillment is the exception, not the rule. In that world, holding the whole order until you can fulfill all of it is the correct behavior.

That assumption breaks down for direct-to-consumer Shopify shops that take pre-orders, because the customer experience there is the opposite: customers expect the in-stock item this week and the pre-order item whenever it lands. They don’t expect both items to wait for the slower one. Brightpearl can be configured to split orders manually, but the splitting always happens after the order has already landed and the dispatch window has already passed.

Brightpearl uses three different states that all get called “on hold” in casual conversation. Knowing the difference matters when you’re reading the queue or debugging.

Release status: Pending. The Sales Order exists, the stock allocation is incomplete, and the order cannot dispatch. This is the default state for a mixed-cart order with one out-of-stock line. Sales Order status: On Hold. An ops user has manually marked the order on hold for a reason unrelated to stock (suspected fraud, customer request, payment issue). Allocation: zero. The line has no inventory reserved. Often a symptom of the first state.

For pre-order mixed carts, you’re almost always looking at the first one. The Sales Order is fine. The release status is Pending. Brightpearl is waiting for stock.

Letting Brightpearl hold mixed-cart orders has three measurable costs.

Dispatch delay. The in-stock item sits in its bin for as long as the pre-order takes to arrive. That can be weeks. The customer expected next-day dispatch on the in-stock item. Cancellation rate. Customer service receives queries within 48 hours of order placement. A meaningful fraction of those queries end in “please cancel my order.” The refund processing, the inventory put-back, and the lost margin all land on the same week. Reputation drag. Reviews and social posts about delayed orders accumulate. The merchant didn’t do anything wrong, but the integration’s default behavior is making them look like they did.

The most common workaround is manual. An ops user watches the Brightpearl queue, finds held orders, opens each one, identifies the pre-order line, copies the customer details, creates a second Sales Order for the pre-order line, adjusts totals on the original, releases the in-stock half. Average handling time is 12 to 18 minutes per order.

At low volume this is fine. At 30 mixed orders a week it’s a quarter of a full-time job. It also introduces reconciliation risk: tax, shipping, and discount math typed in by hand rarely matches Shopify’s line-level rounding, and the gap accumulates. End-of-month reconciliation finds it, eventually.

Brightpearl supports virtual warehouses: a warehouse location with no physical stock backing it. The pattern is to allocate pre-order lines against a virtual location, then book real inventory in when stock arrives. For shops running a few named pre-order campaigns a year, this works well. It gives you Brightpearl-native reporting on pre-order demand, and the workflow is well-understood by Brightpearl agencies.

For shops with frequent mixed-cart orders, virtual warehouses introduce real friction. Setup is two to three days. The ops team has to learn a new pattern. Returns and edits touch the virtual layer. Most importantly, mixed carts still allocate across two warehouses on one Sales Order, which puts you back at the holding problem unless you also configure split allocation rules, which are fragile.

The third pattern is to split the order before Brightpearl receives it. nohold listens on the same orders/create webhook, classifies each line as in-stock or pre-order using product tags, metafields, or live inventory, then writes two Brightpearl Sales Orders in a single API call. The in-stock SO lands Released. The pre-order SO lands on hold, then auto-releases when stock arrives.

The trade-off here is honesty: you’re moving the splitting logic out of Brightpearl and into a middleware layer. The middleware is opinionated, purpose-built for the Shopify-to-Brightpearl flow, and runs in around 184 ms. There’s a monthly subscription. There’s nothing to configure beyond pointing at your pre-order tag. Ops sees two normal-looking Sales Orders in Brightpearl, which is the whole point.

US shops carry an extra compliance layer. The FTC Mail, Internet, and Telephone Order Rule requires that if a shipment slips more than 30 days, you must notify the customer with a revised date and offer them the option to cancel. Civil penalties are real: $53,088 per violation, FTC-adjusted as of January 2025.

Whichever pattern you pick, the compliance work still has to happen. If you’re doing manual splits, the 30-day clock is tracked manually too. If you’re running virtual warehouses, you’re tracking ETAs against the virtual stock arrivals. nohold ships this in the Growth plan: a 30-day aging cron, a delay notice with a revised date, and a signed cancel link that records the request without touching payments.

Look at last quarter’s orders and count two numbers: how many pre-order items you sold, and what fraction of those carts also contained an in-stock item.

If the mixed-cart fraction is below 10%, manual splits are reasonable. If you’re between 10% and 20% and your pre-orders are concentrated in a few named campaigns, virtual warehouses earn their setup cost. If mixed carts are above 20% of your pre-order volume, or you’re running drops every month, webhook-layer splitting is the lower-friction answer. Above 50%, the manual workflow is no longer viable at any team size.

There’s no universally right answer. The right answer is the one that matches the order shape your customers are actually placing.

Brightpearl handles Shopify pre-orders the way it handles any other order: one allocation, one fulfillment, all-or-nothing. That model is correct for distribution and wrong for direct-to-consumer pre-order workflows. Pick the pattern that costs you the least friction for the order volume you actually ship.

nohold is one of those patterns. If you want to see what webhook-layer splitting looks like in production, the install link is at the top of the page. There’s a 14 day trial, no card on file, and the first split lands in Brightpearl about three minutes after you connect your account.