Backorder-Management-Strategie: Verkaufen trotz Null-Bestand in Magento 2

1. Backorder-Konfiguration: Global versus Product-Level

Backorders werden in Magento auf zwei Ebenen gesteuert: global unter Stores Configuration im Bereich Catalog Inventory als Standardwert und zusätzlich pro Produkt im Feld Backorders, sofern die Option Use Config Settings dort deaktiviert ist. Drei Werte stehen zur Auswahl: No Backorders deaktiviert den Verkauf bei Null-Bestand vollständig, Allow Qty Below 0 erlaubt den Verkauf, ohne die negative Menge im Frontend anzuzeigen, und Allow Qty Below 0 and Notify Customer zeigt zusätzlich einen Hinweis, dass der Artikel derzeit nicht auf Lager ist, aber bestellt werden kann.

In der Praxis bewährt sich fast immer die produktbezogene Konfiguration, weil sich Backorder-Eignung stark je Sortimentsbereich unterscheidet. Ein Standardartikel mit kurzer Nachproduktionszeit ist ein guter Kandidat für Backorders, ein saisonales oder auslaufendes Produkt dagegen nicht, weil dort das Risiko einer nie erfüllbaren Bestellung deutlich höher liegt. Eine pauschale globale Aktivierung für das gesamte Sortiment ignoriert diese Unterschiede und führt regelmäßig zu Enttäuschungen bei Kunden, die einen faktisch nicht mehr verfügbaren Artikel bestellt haben.

<?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. Lieferzeit-Kommunikation an Kunden

Der Standard-Hinweis Out of stock but available for backorder informiert den Kunden zwar über die Verfügbarkeitssituation, sagt aber nichts über die tatsächlich zu erwartende Lieferzeit aus. Für ein professionelles Kundenerlebnis reicht das selten aus, besonders bei Artikeln mit deutlich längeren Nachproduktionszeiten als der üblichen Versanddauer. Eine praxistaugliche Erweiterung ist ein eigenes Custom-Attribut je Produkt für die geschätzte Nachlieferzeit, das im Frontend anstelle des generischen Backorder-Hinweises angezeigt wird.

Diese Lieferzeit-Angabe sollte nicht statisch im Produkt gepflegt, sondern idealerweise aus dem tatsächlichen Bestelltermin beim Lieferanten abgeleitet werden, sofern eine entsprechende Anbindung existiert. Ohne diese Anbindung ist zumindest eine regelmäßige manuelle Pflege durch den Einkauf notwendig, da eine veraltete Lieferzeit-Angabe das Vertrauen der Kunden stärker beschädigt als ein ganz generischer Hinweis ohne konkretes Datum.

<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 || 'Derzeit nicht auf Lager, bestellbar mit Lieferverzögerung'"></span>
  </p>
  <p class="text-xs text-gray-500 mt-1" x-show="product.expectedRestockDate">
    Voraussichtlich lieferbar ab <span x-text="product.expectedRestockDate"></span>
  </p>
</div>

3. Zusammenspiel mit Reservations und MSI

Technisch ändert eine Backorder-Konfiguration nichts am Reservation-Mechanismus selbst: Auch bei aktiviertem Backorder wird beim Checkout weiterhin eine negative Reservierung angelegt, die die salable_quantity entsprechend reduziert. Der Unterschied liegt lediglich in der Prüfung, ob eine Bestellung überhaupt zugelassen wird, wenn die resultierende salable_quantity negativ wäre. Ist Backorder aktiv, wird dieser Fall zugelassen, ist er deaktiviert, schlägt der Checkout mit einem entsprechenden Fehler fehl.

Das bedeutet auch, dass die salable_quantity bei aktiven Backorders dauerhaft negativ werden kann, was für eigene Reports und Auswertungen berücksichtigt werden muss. Ein einfacher Report, der salable_quantity kleiner null als Fehlerzustand interpretiert, würde bei aktivierten Backorders ständig falsche Alarme auslösen, obwohl der negative Wert in diesem Fall ein gewolltes, korrektes Verhalten darstellt und keinen Datenfehler.

-- Backorder-Fälle von echten Inkonsistenzen unterscheiden:
-- negative salable_quantity ist bei aktivem Backorder erwartetes Verhalten
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. Der Zusammenhang zwischen Backorders und Stornorate

Unkontrolliert aktivierte Backorders führen erfahrungsgemäss zu einer messbar höheren Stornorate, weil Kunden Bestellungen aufgeben, ohne die tatsächliche Lieferzeit einschätzen zu können, und die Geduld verlieren, wenn die erwartete kurze Versanddauer deutlich überschritten wird. Besonders kritisch ist das bei Artikeln, die fälschlich noch als backorder-fähig markiert sind, obwohl der Lieferant das Produkt bereits eingestellt hat und faktisch nie wieder Bestand eintreffen wird.

Ein sinnvoller Kontrollmechanismus ist eine maximale Backorder-Dauer je Produkt: Bleibt eine Bestellung länger als eine konfigurierbare Frist im Backorder-Status, ohne dass neuer Bestand eintrifft, sollte automatisch eine Benachrichtigung an den Einkauf ausgelöst werden, statt die Bestellung unbegrenzt offen zu lassen. Ohne eine solche Eskalation bleiben problematische Backorders oft monatelang unbemerkt liegen, bis sich Kunden aktiv beim Support melden.

5. Eigenes Backorder-Reporting für den Einkauf

Da Magento selbst keinen dedizierten Backorder-Report mitbringt, lohnt sich ein eigenes Modul, das offene Backorder-Bestellungen aggregiert nach SKU auflistet, zusammen mit der Anzahl betroffener Bestellungen und dem Zeitpunkt der ältesten offenen Backorder-Position. Diese Auswertung hilft dem Einkauf, Nachbestellungen zu priorisieren, statt sich ausschließlich auf generische Mindestbestandsschwellen zu verlassen, die Backorder-Nachfrage gar nicht abbilden.

Für ein solches Reporting müssen Order-Items identifiziert werden, deren versendete Menge kleiner als die bestellte Menge ist und deren zugehöriges Produkt zum Bestellzeitpunkt tatsächlich als Backorder verkauft wurde, nicht nur regulär noch nicht versendete Positionen. Diese Unterscheidung ist wichtig, weil eine normale, noch nicht versendete Bestellung mit ausreichend Bestand ein völlig anderes Handlungserfordernis hat als eine echte Backorder-Position ohne jeglichen physischen Bestand.

6. Risiken bei unkontrollierten Backorders

Das größte Risiko ist eine dauerhaft negative salable_quantity ohne realistische Aussicht auf Nachschub, die faktisch zu einer stillen Warteschlange nicht erfüllbarer Bestellungen wird. Ohne aktives Monitoring bemerkt das Unternehmen dieses Problem oft erst, wenn die Zahl der Support-Anfragen wegen ausbleibender Lieferungen spürbar ansteigt, was zu diesem Zeitpunkt bereits erheblichen Reputationsschaden verursacht haben kann.

Ein zweites, oft unterschätztes Risiko betrifft die Zahlungsabwicklung: Wird bei Bestellung sofort der volle Betrag abgebucht, obwohl die tatsächliche Lieferung Wochen oder Monate auf sich warten lässt, verstösst das je nach Zahlungsanbieter und Rechtsraum gegen Vorgaben zur Vorkasse-Abbuchung erst bei tatsächlichem Versand. Für Backorder-Artikel sollte deshalb sorgfältig geprüft werden, ob eine verzögerte Kapture der Zahlung bis zum tatsächlichen Versand rechtlich und technisch die sauberere Lösung ist.

7. Eigene Steuerungslogik statt reiner Magento-Standardkonfiguration

Für Betriebe mit ernsthafter Backorder-Nutzung lohnt sich ein eigenes Modul, das über die reine Ja-Nein-Konfiguration von Backorders hinausgeht: eine maximale Backorder-Menge je Produkt, eine automatische Deaktivierung nach Überschreiten einer konfigurierbaren Frist ohne Nachschub und eine Eskalation an den Einkauf. Dieses Modul sollte, wie jedes andere Mironsoft-Modul, eine eigene system.xml mit acl.xml und einem eigenen Menüpunkt für die Konfiguration mitbringen, statt Schwellenwerte im Code zu verstecken.

Wichtig ist dabei, die eigene Logik als Plugin auf die relevanten Order-Placement- und Stock-Prüfungen zu setzen, statt bestehende Magento-Klassen per Preference zu ersetzen. Ein Plugin auf die Verfügbarkeitsprüfung erlaubt es, zusätzliche eigene Kriterien wie die maximale Backorder-Menge einzubringen, ohne den Kern der Magento-Bestandslogik zu ersetzen und damit bei jedem Update erneut abgleichen zu müssen.

8. Backorder-Artikel in Suche und Kategorienavigation

Backorder-Artikel bleiben standardmäßig in der Layered Navigation und in der Suche sichtbar, solange der Katalog-Sichtbarkeitsstatus nicht separat auf Not Visible Individually gesetzt wird, da die Sichtbarkeit unabhängig vom Lagerbestand gepflegt wird. Das ist meist gewünscht, weil ein Backorder-Artikel ja aktiv verkauft werden soll, kann aber bei einer Sortierung nach Verfügbarkeit zu Verwirrung führen, wenn Backorder-Artikel und regulär lagernde Artikel ununterscheidbar nebeneinander im Grid erscheinen.

Ein eigener, in der Katalog-Sortierung nachgelagerter Layered-Navigation-Filter für den Verfügbarkeitsstatus schafft hier Transparenz, indem Kunden gezielt nach sofort lieferbaren Artikeln filtern können, ohne Backorder-Artikel komplett aus dem Sortiment auszublenden. Technisch lässt sich das über ein eigenes, aus dem Backorder-Status abgeleitetes Filter-Attribut umsetzen, das per Indexer aktuell gehalten wird und in der Facettennavigation neben Preis und Marke erscheint.

9. Typische Fehler bei der Backorder-Strategie

Der häufigste Fehler ist eine globale Backorder-Aktivierung für das gesamte Sortiment ohne Rücksicht auf die Wiederbeschaffungszeit einzelner Produktkategorien. Das führt dazu, dass auslaufende oder saisonale Artikel genauso backorder-fähig sind wie Dauerbrenner mit kurzer Nachproduktionszeit, was die Stornorate unnötig in die Höhe treibt. Eine differenzierte, produktbezogene Konfiguration ist fast immer der bessere Weg.

Ein zweiter Fehler ist fehlendes Monitoring der tatsächlichen Backorder-Dauer. Ohne eine Eskalation bei Überschreiten einer erwarteten Frist bleiben problematische Bestellungen unbemerkt offen, bis Kunden selbst aktiv werden. Ergänzt um die richtige Zahlungsabwicklung, bei der die Kapture idealerweise erst zum tatsächlichen Versand erfolgt, lässt sich das Risiko unkontrollierter Backorders deutlich reduzieren, ohne auf den Umsatzvorteil ganz zu verzichten.

10. Zusammenfassung

11. FAQ: Backorder-Strategie: Das Wichtigste auf einen Blick