Preorders and Backorders Without Overselling Any Channel

A preorder sells a unit that has never been in stock. A backorder sells a unit of something you normally carry, after it has run out. Both take money today for goods you cannot ship today, and both fail in the same place: the quantity you publish to each channel stops being a count of what exists and becomes a forecast of what will arrive.

A count is hard enough to share across channels. A forecast is worse, because the thing being divided has not happened yet and the date it depends on can move.

Two different promises, two different risks

A preorder rests largely on somebody else's schedule: the factory, the supplier, the freight booking, customs. You are quoting a date you were given, often once and often optimistically, for a production run that has not finished.

A backorder rests on a lead time you have measured. You have bought this item before and you know roughly how long replenishment takes. The risk is not that the date is unknowable. It is that the date is knowable and nobody looked it up before the badge went on the product page.

It is worth resisting the idea that a preorder is a complete unknown, because that belief is how forecasting gets skipped. Most preorders are a new colorway, a seasonal rerun or a second version of something you have shipped before, which means you have the supplier's on-time record, the freight lane's history and a customs profile. Use them.

Those two risks call for different limits, and the following is operational judgment rather than anything the sources below establish. A preorder deserves a hard cap set from the purchase order quantity, reduced for the share of the run you expect to lose to quality holds and short shipping. A backorder deserves a rolling cap tied to the next confirmed inbound; the surrounding process, from supplier lead times to customer communication, is covered in our guide to backorder management. What neither deserves is an uncapped pool.

What you are actually selling when you sell a backorder

It helps to be precise about which number you are drawing down.

Shopify, to take a platform that documents this plainly, tracks three states at a location plus a total. "On hand" is "all inventory units that you have at a location", and it equals committed plus unavailable plus available. "Committed" is "the number of units that are set aside and can't be sold, such as units in an unfulfilled order, reserved in a draft order, or in a transfer that's marked as ready to ship". "Unavailable" is "the number of units set aside by apps or held for other reasons, such as damaged, quality control, or safety stock". "Available" is "inventory that you can sell" and is what remains.

Then there is a number sitting outside that equation entirely. "Incoming" is "inventory that's on its way to your location from inventory transfers or apps", and Shopify is explicit that it "isn't available to sell until it has been received and its state has been changed to Available".

That separation is the thing to internalize, and it is worth being exact about the mechanism, because it is easy to assume a connection that is not there. Allowing oversell does not draw down incoming stock. On Shopify, the "Continue selling when out of stock" setting simply lets available go to zero or below; it does not read the incoming quantity, does not stop at it, and does not decrement it. Nothing in the platform ties the two together.

So the cap is yours to impose. The system will happily let available go to minus four hundred against an inbound of two hundred, and it has no opinion about that. Deciding the number, per product, against a specific expected delivery, is work no setting does for you.

Two preconditions are easy to miss on the same platform. The setting applies only where inventory tracking is turned on, so untracked items behave differently, which matters in a large catalog. And an item counts as out of stock when the level is "at zero or below" — the threshold is not configurable upward, so you cannot reserve a floor this way.

Where the oversell actually happens

Single-channel oversells are real and common: unreserved carts, two checkouts completing at once, a cancellation restocking late, count drift, a fulfillment split. Do not assume one channel is a solved problem.

But the failures that hurt most across a multi-channel business tend to sit between systems rather than inside one.

Sync timing is the obvious one. Many channels hold their own copy of your quantity, refreshed on a cadence or pushed by webhook, and there is usually some window in which two channels can each sell the last unit in good faith. Keeping one inventory position across channels is the foundation the rest of this sits on. Backorders widen the consequences, because the pool being raced for is larger and more speculative.

Then there is the location that cannot ship. Shopify's documentation describes the trap exactly: "If you have an item at a location that fulfills online orders with an inventory level of zero or below, and a location with available inventory that doesn't fulfill online orders, then that item is still displayed as out of stock to customers." Stock exists and the channel cannot see it, because of a fulfillment setting rather than a quantity. When a backorder pool is layered on top of a location map nobody has audited recently, the pool inherits every one of those assumptions.

And there is the register. On Shopify, the "Continue selling when out of stock" setting "doesn't apply to orders placed from Shopify POS" — staff get a warning instead. That is one platform's behavior and not a general rule, since other point-of-sale systems inherit the web setting or allow negative stock outright. The point is that your stores may not follow the policy you wrote for the website, and somebody has to find out which way yours goes before a customer does.

The ship date is a commitment, not just a marketing line

What follows is general information about one US rule, not legal advice, and other markets have their own regimes. Check your own obligations.

In the US, the Federal Trade Commission's Mail, Internet, or Telephone Order Merchandise Rule requires that a seller have "a reasonable basis to expect that it will be able to ship" within the time stated, or, where no time is stated, within "thirty (30) days after receipt of a properly completed order". Where the buyer applies for credit to pay at the time of ordering, that default is 50 days. The FTC describes a reasonable basis as information that would satisfy "a reasonable and prudent businessperson, acting in good faith, that the representation is true", substantiated through anticipated demand, inventory sufficiency, fulfillment capacity and recordkeeping.

Note that last word. Recordkeeping is not an afterthought in that list; it is the part that turns a belief into a basis.

If the date slips, there is a prescribed procedure. You must offer the buyer the "option either to consent to a delay in shipping or to cancel", giving either a "definite revised shipping date" or a statement that you are "unable to make any representation regarding the length of the delay", along with clear notice of the right to cancel for a full refund and a cost-free way to do it.

The consent rules are asymmetric, which is worth knowing before anyone writes the email. Where the revised date is 30 days or less later, silence works in your favor: "unless the seller receives... a response from the buyer rejecting the delay", the buyer "will be deemed to have consented". Where the revised date is more than 30 days out, or indefinite, silence does not. The order cancels within 30 days unless the buyer expressly agrees to keep waiting. A seller that never offers the option at all, and has not shipped within the applicable time, must cancel and refund anyway. On refunds, the Rule sets seven working days by first-class mail or faster for a straightforward purchase, and one billing cycle where a third-party creditor is involved.

Here is an implication rather than a requirement, and it is this post's own inference: the obligation attaches to the order line, against the date that was showing when the order was placed. Product pages get edited and badges change when a supplier revises. If your system derives the promise from the current product record, the order record no longer reflects what that customer was told. The confirmation email is usually the fallback evidence, which is better than nothing and worse than a field you can query, because you cannot build a trigger on an inbox. A design that only guards the quantity has nowhere to put that date and nothing hanging off it.

What to put in place, in order

Cap every backorder and preorder pool explicitly, per product, against a specific inbound quantity, with a number somebody owns.

Allocate that pool across channels deliberately rather than first come, first served. Otherwise the fastest-selling channel takes all of it, including the share you meant to hold back.

Store the promised date on the order line at the moment of sale, next to the quantity, and do not recompute it later from the product page.

Make a slipped inbound a routed exception with an owner and a clock, of the kind covered in order exception management, rather than a spreadsheet somebody remembers on Friday. When a confirmed date moves, every line promised against it needs revisiting.

And decide what your stores do before a customer asks, because the register is the surface least likely to have been included when the policy was written.