What does backorder mean? Difference from Preorder

Backorder

The customer can buy now even though current sellable stock is exhausted. That makes a backorder more than an inventory flag. It is a promise against expected future supply. A useful state model is: stock unavailable → order accepted → demand queued → inventory replenished → units allocated → order fulfilled If the expected supply disappears, the process needs an exception path rather than pretending the order is still normally fulfillable.

Backorder, preorder, and stockout are different states

These terms are often blurred because all 3 can involve an unavailable item. A stockout simply means desired inventory is unavailable. The merchant might block purchase entirely. A backorder means purchase remains possible because replenishment is expected after ordinary availability has run out. A preorder usually means the customer orders before normal availability or release begins.

A product launch scheduled for October can be on preorder in September. A replacement filter that normally sells every day but is temporarily depleted can be on backorder. Both can create delayed fulfillment, but the inventory story and customer expectation are different.

Negative inventory is not the whole definition

Some commerce platforms represent backorders by allowing salable quantity to move below zero. Others maintain a separate backordered quantity or reservation model.

Adobe Commerce, for example, can allow orders below zero and recommends an out-of-stock threshold that limits how many units may be backordered. Shopify can allow a merchant to continue selling after tracked inventory reaches zero, but that setting is also used for preorders, made-to-order products, and other cases.

Those implementations show why "inventory is negative" is not a reliable universal definition. The business meaning comes from the promise: the order is accepted now and intentionally waits for future supply.

Every backorder consumes future inventory

Suppose a merchant has:

• 0 units available
• 20 units confirmed inbound next week
• 7 existing backorders

If the merchant accepts another 20 orders, it has not created 20 future sales that can all be fulfilled next week. It has created 27 units of demand against 20 expected units. The system therefore needs to distinguish:

• on-hand inventory
• salable inventory
• inbound or expected inventory
• backordered quantity
• already allocated future units

If incoming supply is uncertain, the merchant may need a conservative backorder cap rather than selling the entire purchase order before it arrives.

Allocation order matters

When 20 units arrive, which backorders get them? Possible policies include:

• oldest order first
• premium customer priority
• complete-order priority to avoid split shipments
• channel or region allocation
• manual exception handling

There is no universal best answer, but the choice should be deterministic. A merchant should not tell every customer "ships next week" if only some orders can actually receive the next replenishment.

The ETA is part of the product promise

A useful backorder message answers 2 separate questions:

1. When do we expect stock?
2. When do we expect this customer's order to ship?

Those are not necessarily the same date. Inventory can arrive at a warehouse and still need receiving, inspection, allocation, picking, and packing before the order is handed to a carrier.

If the inbound date changes, the customer-facing promise should change too. A delayed backorder that stays silent until the customer complains is operationally different from one that proactively communicates the revised date and cancellation option.

Payment behavior is implementation-specific

Do not define a backorder by when the customer is charged. A platform may authorize and capture payment immediately, authorize and capture later, or use another payment flow. Adobe Commerce's current backorder documentation, for example, describes its own configuration as authorizing/capturing funds while shipping waits for stock. Other commerce and payment setups can behave differently. The general operator questions are:

• when is payment authorized?
• when is it captured?
• can an authorization expire before replenishment?
• what happens if the customer cancels before shipment?
• does a long delay require reauthorization or a new payment attempt?

Those questions belong in the backorder design even though their answers are platform-specific.

Backorder caps prevent impossible promises

A safe system can stop accepting backorders when one of these limits is reached:

• maximum backordered units
• maximum expected delay
• insufficient confidence in inbound supply
• supplier allocation not confirmed
• customer promise date would move beyond an acceptable window

A cap converts an open-ended "keep selling below zero" configuration into a controlled queue.

Worked example

A merchant normally sells 8 replacement cartridges per day. Inventory reaches zero on Monday. A confirmed shipment of 50 units is expected Friday.

• By Wednesday morning, 24 backorders have accumulated

If the merchant keeps accepting 8 per day through Friday without considering receiving time, it can easily promise more units than the inbound shipment covers. A better system subtracts existing backorders from expected usable inbound stock and factors in a buffer for receiving issues or supplier short-ships.

If only 45 of the 50 units arrive, the final 5 customers need a new promise. That is an exception the workflow should anticipate, not a surprise discovered during picking.

A practical Backorder rollout

One step.

1. 01
   A backorder workflow needs exit pathsA backorder ends in more than one way: - inventory arrives and the order ships - customer cancels - merchant cancels because supply is no longer expected - product is substituted with customer agreement - order is partially fulfilled - ETA is revised and customer accepts the delay The operational goal is not simply to keep accepting orders during a stockout. It is to accept only the future demand that the merchant can communicate, allocate, and fulfill responsibly.