Backorders are an existing feature that allow you to sell out-of-stock products from the warehouse when you create an order. Backorders are available in the OMS Admin > Sales > Backorders.

See the Backorders User Guide to learn how to view and filter backorders in the Order Management System (OMS) Admin.

To increase visibility for this feature you will see a label for backorders in the Admin.

Label in Admin

You can display the available products for backorders as In Stock, or using a customized message such as Available in ‘X’ days. This feature can increase your sales revenue and provide flexibility when selling products that are not available, but expected to be restocked within a short time frame.


Backorders can be configured at both the store and order item level:

  • Store level—You can enable or disable the backorder feature for each store. If enabled, your Order Management System (OMS) allows all items to be available for backorder. If disabled, when your OMS receives an order for a SKU that is out of stock, the line is canceled.
  • Order item level—Order items that do not allow for a backorder are canceled if they are out of stock.

If backorders are enabled, your OMS splits a single order into several shipments. The sourcing logic allows you to configure the maximum number of allowed splits, or hold back an order if some of the lines are out of stock. For this to work, the logistics provider must be able to support multiple shipment requests for the same order.

Enabling backorders

Your System Integrator (SI) can enable the backorder feature by sales channel. All items in the catalog accept backorders by default, unless defined differently.

If backorders are not allowed for all items, it is still possible to use them by defining allowed order lines with the magento.sales.order_management.create message.

allowBackorder is provided within the custom_attributes node for each order line. If the SKU does not have any available stock the order line will be flagged as a backorder and regularly checked for stock updates:

 "custom_attributes": [
                        "name": "allowBackorders",
                        "value": "true"

These definitions are configured in your SI Portal, which is not yet accessible externally. Contact Magento Support for assistance.


Your OMS checks lines with stock status in backorder and holds them until the stock becomes available. Depending on the payment method, orders with lines on backorder and regular lines have multiple settlements (one for each shipment).

If the backorder configuration is not enabled, and in your OMS a SKU is out of stock, the line is canceled.


You can set a threshold of days that are used to flag the backorder lines as exceptions in the exception queue. Once the specified day limit is reached the exception is reported with a High severity status.

You can set these exceptions in the Order category of the System Integrator (SI) Portal.

Use this configuration to manage the Federal Trade Commission (FTC) compliance, ensuring there is a process for obtaining customer consent to comply with regulations.

Aged backorders

Backorder lines can be either aged, or not aged.

The Exceptions rules configuration in the SI Portal contains several configuration options for managing backorders:

  • Aged Backorders—Determines the timeframe, from the moment of order creation, in which a backorder is defined as an aged backorder
  • Resubmit Aged Orders—Determines the timeframe in days that an aged backorder remains in the queue before it is sent to sourcing
  • Detect New Stock Added—After a stock update is processed, this allows aged backorders containing one of the updated stock SKUs to be flagged as ready for re-sourcing in the next allocation wave (allowing it to bypass the Resubmit Aged Orders configuration setting)

Items flagged as backorders are sent, with their accompanying order, to be sourced for the next allocation wave (same day). After the number of days defined per the configuration have passed, the order is marked as an aged backorder. The system uses the stock snapshot to validate which of the agedBackorders received stock. Then the order is sent to sourcing only once after staying in the queue for the time period defined per the Resubmit aged Orders option in the Exceptions rules configuration.

Aged Backorders example

  1. Client XYZ has set both their Aged Backorders and Resubmit Aged Orders configurations to 30 days.
  2. Client XYZ’s shop has an order created on January 1st, with one of the order’s lines flagged as a backorder.
  3. The order will be sent for sourcing in each configured wave until January 31st (per the Aged Backorders configuration).
  4. After January 31st, the order is marked as an aged backorder and will be submitted to sourcing only once every 30 days (per the Resubmit Aged Orders configuration).
  5. If the Detect New Stock Added configuration is enabled, when the system receives a stock update for one of the backorder items, it will be sent to sourcing during the next configured allocation wave.

Backorder flows

The following diagrams illustrate backorder flows in the OMS.

OMS backorder flow (no stock available)

No stock available

Backorders are displayed in the allocation queue even if the client is using the default mode (Direct).

OMS backorder flow (stock available after some time)

Stock available after sometime


We batch sourcing requests on backorder based on a few general parameters, considering each in a methodical way to determine the best way to batch requests:

  • Order in which the OMS receives the request
  • Client
  • Aggregate
  • Source

Larger sourcing requests are batched and prioritized in a more granular way to configure allocation waves for efficiency. We complete sourcing requests in the order we receive them (similar to the First In First Out rule) but true order is also determined by these other parameters.

For instance, In-store Pickup (ISPU) orders are prioritized above all else due to the timely nature of that order type. If an order is both a backorder and an ISPU order, it is treated as an ISPU order (higher priority than a simple backorder). Sourcing request batches that contain both new orders and backorders are treated as a backorder request (lower priority than a sourcing request with only new orders or ISPU orders).

This approach, along with the aforementioned sourcing parameters, will affect how we batch sourcing requests containing ISPU backorders.

If the Detect New Stock Added configuration option is enabled, when stock is added the OMS receives that info and triggers a sourcing request for affected backorders. Sourcing logic applies to these requests, as they would for any other sourcing request, to place them in allocation waves to be sourced.

Re-auth strategy

An order with backorder lines automatically applies a re-auth strategy to ensure that you are able to capture the money once there is available stock. This process typically takes place every 10 days and can be set by your SI in the SI Portal.