Backorder Management Strategy: Selling at Zero Stock in Magento 2

1. Backorder configuration: global versus product level

Backorders in Magento are controlled at two levels: globally under Stores Configuration in the Catalog Inventory section as a default value, and additionally per product in the Backorders field, provided the Use Config Settings option is disabled there. Three values are available: No Backorders disables selling at zero stock entirely, Allow Qty Below 0 permits the sale without showing the negative quantity on the storefront, and Allow Qty Below 0 and Notify Customer additionally shows a note that the item is currently out of stock but can still be ordered.

In practice, product-level configuration almost always wins out, because backorder suitability varies strongly by catalog segment. A standard item with a short restock time is a good candidate for backorders, a seasonal or discontinued product is not, since the risk of an order that never gets fulfilled is considerably higher there. Blanket global activation across the whole catalog ignores those differences and regularly leads to disappointed customers who ordered an item that is effectively no longer available.

<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Config:etc/system_file.xsd">
    <system>
        <section id="cataloginventory" translate="label" type="text" sortOrder="50">
            <group id="item_options" translate="label" sortOrder="1">
                <field id="backorders" translate="label" type="select" sortOrder="10">
                    <label>Backorders</label>
                    <source_model>Magento\CatalogInventory\Model\Source\Backorders</source_model>
                    <config_path>cataloginventory/item_options/backorders</config_path>
                </field>
            </group>
        </section>
    </system>
</config>

2. Communicating lead time to customers

The default Out of stock but available for backorder message informs the customer about the availability situation, but says nothing about the actually expected lead time. For a professional customer experience that is rarely enough, especially for items with a restock time noticeably longer than the usual shipping time. A practical extension is a dedicated custom attribute per product for the estimated restock time, displayed on the storefront in place of the generic backorder message.

That lead-time figure should not be maintained statically on the product, it should ideally be derived from the actual order date placed with the supplier, provided such an integration exists. Without that integration, at least regular manual maintenance by purchasing is necessary, since a stale lead-time figure damages customer trust more than a fully generic note without a concrete date.

<div x-data="{ backorder: product.stockStatus === 'backorder' }" x-show="backorder">
  <p class="text-amber-700 text-sm font-semibold flex items-center gap-2">
    <svg class="w-4 h-4" aria-hidden="true"><!-- Icon --></svg>
    <span x-text="product.leadTimeText || 'Currently out of stock, orderable with a shipping delay'"></span>
  </p>
  <p class="text-xs text-gray-500 mt-1" x-show="product.expectedRestockDate">
    Expected to ship from <span x-text="product.expectedRestockDate"></span>
  </p>
</div>

3. Interaction with reservations and MSI

Technically, a backorder configuration changes nothing about the reservation mechanism itself: even with backorders enabled, checkout still creates a negative reservation that reduces salable_quantity accordingly. The difference lies only in the check for whether an order is allowed at all when the resulting salable_quantity would be negative. If backorder is enabled, that case is allowed, if it is disabled, checkout fails with a corresponding error.

That also means salable_quantity can stay permanently negative with backorders enabled, which needs to be accounted for in custom reports and analyses. A simple report interpreting salable_quantity below zero as an error state would constantly trigger false alarms with backorders enabled, even though the negative value in that case is intended, correct behavior and not a data bug.

-- Distinguishing backorder cases from real inconsistencies:
-- negative salable_quantity is expected behavior with backorder enabled
SELECT
    si.sku,
    si.quantity + COALESCE(SUM(r.quantity), 0) AS salable_quantity,
    p.backorders
FROM inventory_source_item si
LEFT JOIN inventory_reservation r ON r.sku = si.sku AND r.stock_id = 1
LEFT JOIN catalog_product_entity_int p ON p.entity_id = (
    SELECT entity_id FROM catalog_product_entity WHERE sku = si.sku
) AND p.attribute_id = (
    SELECT attribute_id FROM eav_attribute WHERE attribute_code = 'backorders'
)
GROUP BY si.sku, p.backorders
HAVING salable_quantity < 0 AND (p.backorders IS NULL OR p.backorders = 0);

4. The link between backorders and cancellation rate

Uncontrolled backorder activation reliably leads to a measurably higher cancellation rate, since customers place orders without being able to judge the actual lead time and lose patience once the expected short shipping window is noticeably exceeded. This is particularly critical for items still incorrectly marked as backorder-eligible even though the supplier has already discontinued the product and stock will effectively never arrive again.

A sensible control mechanism is a maximum backorder duration per product: if an order stays in backorder status longer than a configurable deadline without new stock arriving, a notification to purchasing should automatically be triggered instead of leaving the order open indefinitely. Without that kind of escalation, problematic backorders often sit unnoticed for months until customers actively reach out to support.

5. Custom backorder reporting for purchasing

Since Magento does not ship a dedicated backorder report itself, a custom module is worthwhile, aggregating open backorder orders by SKU together with the number of affected orders and the date of the oldest open backorder line. That report helps purchasing prioritize reorders instead of relying solely on generic minimum stock thresholds that do not capture actual backorder demand at all.

Building such a report requires identifying order items whose shipped quantity is lower than the ordered quantity and whose linked product was actually sold as a backorder at order time, not just regular items awaiting shipment. That distinction matters because a normal, not-yet-shipped order with sufficient stock has a completely different action requirement than a true backorder line without any physical stock at all.

6. Risks of uncontrolled backorders

The biggest risk is a persistently negative salable_quantity with no realistic prospect of restocking, effectively turning into a silent queue of unfulfillable orders. Without active monitoring, a company often only notices this problem once the number of support requests about missing deliveries rises noticeably, by which point significant reputational damage may already have occurred.

A second, often underestimated risk concerns payment processing: if the full amount is captured immediately at order time even though the actual delivery is weeks or months away, that can violate rules around prepayment capture depending on the payment provider and jurisdiction, which often require capture only at actual shipment. For backorder items, it is therefore worth carefully checking whether a delayed capture until the actual shipment is the cleaner solution both legally and technically.

7. Custom control logic instead of pure default configuration

For operations with serious backorder usage, a custom module is worthwhile that goes beyond the plain yes-no backorder configuration: a maximum backorder quantity per product, automatic deactivation once a configurable deadline without restocking is exceeded, and an escalation to purchasing. Like any other Mironsoft module, this module should ship its own system.xml with acl.xml and a dedicated menu item for configuration, instead of hiding thresholds in code.

It is important to attach custom logic as a plugin on the relevant order placement and stock availability checks, rather than replacing existing Magento classes via preference. A plugin on the availability check lets you add custom criteria such as a maximum backorder quantity without replacing the core of Magento's inventory logic and having to reconcile it again with every update.

8. Backorder items in search and category navigation

Backorder items stay visible in layered navigation and search by default, as long as catalog visibility is not separately set to Not Visible Individually, since visibility is maintained independently of stock level. That is usually desired, since a backorder item is meant to actively keep selling, but it can cause confusion when sorting by availability if backorder items and regularly stocked items appear indistinguishably next to each other in the grid.

A custom layered navigation filter for availability status, layered on top of catalog sorting, creates transparency here by letting customers filter specifically for immediately deliverable items without hiding backorder items from the catalog entirely. Technically, this can be implemented via a dedicated filter attribute derived from backorder status, kept current through the indexer, and shown in the facet navigation alongside price and brand.

9. Common pitfalls in backorder strategy

The most common mistake is a blanket global backorder activation across the entire catalog without regard to the restock time of individual product categories. That leads to discontinued or seasonal items being just as backorder-eligible as evergreen sellers with a short restock time, needlessly driving up the cancellation rate. A differentiated, product-level configuration is almost always the better path.

A second mistake is missing monitoring of actual backorder duration. Without an escalation once an expected deadline is exceeded, problematic orders stay open unnoticed until customers act themselves. Combined with correct payment processing, where capture ideally only happens at actual shipment, the risk of uncontrolled backorders can be reduced substantially without fully giving up the revenue benefit.

10. Summary

11. FAQ: Backorder Strategy: Key Takeaways