Im Streckengeschäft verkauft ein Händler Ware, die er nicht selbst lagert: Die Bestellung geht ein, doch versendet wird direkt vom Lieferanten an den Endkunden. Das schont Kapital und Lagerfläche, verlagert aber die kritische Frage in die Schnittstelle: Ist der Artikel beim Lieferanten überhaupt verfügbar, zu welchem Preis und in welcher Lieferzeit? Wie groß der Rahmen ist, zeigt der B2B-Handel: Der B2B-Internethandel von Großhandel und Herstellern über Onlineshops und Marktplätze wuchs 2024 um 7 Prozent auf 509 Milliarden Euro (IFH Köln), Marktplätze stehen inzwischen für 56 Prozent des E-Commerce-Umsatzes mit Waren (bevh). Dieser Artikel zeigt, wie Streckengeschäft technisch sauber läuft, wenn das ERP das führende System bleibt: Lieferanten-Feeds über EDI, CSV/SFTP oder REST-API einlesen, Verfügbarkeit und Lieferzeit im Shop spiegeln, Bestellungen automatisch nach Lieferant splitten und Tracking zurückführen. Wir orchestrieren solche Multi-Lieferanten-Flows über eine Middleware, damit Strecken- und Lagerware ohne Doppelpflege in einem Prozess zusammenlaufen.
Das Wichtigste in Kürze
- Streckengeschäft steht und fällt mit verlässlichen Lieferanten-Feeds: Bestand, Preis und Lieferzeit müssen automatisiert einlaufen, nicht als manuell gepflegte Liste.
- Lieferanten liefern in unterschiedlichen Formaten -- EDIFACT, CSV über SFTP oder REST-API. Eine Middleware normalisiert diese Formate auf ein gemeinsames Datenmodell.
- Verfügbarkeit und Lieferzeit gehören je Lieferant in den Shop gespiegelt, damit Kunden nicht bestellen, was beim Lieferanten längst vergriffen ist.
- Eingehende Bestellungen werden automatisch nach Lieferant gesplittet und beauftragt; Versandbestätigung, Tracking und Wareneingangsmeldung laufen zurück in Shop und ERP.
- Lager- und Streckenware brauchen eine klare Trennung im Datenmodell, damit ein Bestell- und Bestandsprozess beide Beschaffungswege ohne Widerspruch abbildet.
Warum das Streckengeschäft 2026 an Bedeutung gewinnt
Streckengeschäft ist im Großhandel keine Randerscheinung, sondern professionalisiert sich als margenschonende Alternative zum Eigenlager. Wer ein breites Sortiment anbietet, ohne jeden Artikel selbst vorzuhalten, senkt gebundenes Kapital und Lagerrisiko und erweitert das Angebot über die eigene Lagerkapazität hinaus. Der Markt liefert den Rückenwind: Der gesamte B2B-E-Commerce von Großhandel und Herstellern lag 2024 bei über 1,5 Billionen Euro, davon 509 Milliarden Euro über Onlineshops und Marktplätze (IFH Köln). Für den B2C-Onlinehandel hebt der Handelsverband seine Prognose für 2025 auf 92,4 Milliarden Euro an, ein Plus von 4 Prozent gegenüber den 88,8 Milliarden Euro des Vorjahres (HDE).
Zugleich verschiebt sich das Gewicht zu Plattformen und Sortimentsbreite. Marktplätze stehen laut Handelsverband für 57 Prozent des Onlinehandelsumsatzes (HDE), der bevh weist ihren Anteil am E-Commerce mit Waren mit 56 Prozent beziehungsweise 46,2 Milliarden Euro aus (bevh). Wer auf Plattformen und im eigenen Shop mit breitem Sortiment bestehen will, kommt an Streckenware kaum vorbei -- und damit an der Frage, wie Lieferantendaten verlässlich und aktuell in den Verkaufskanal kommen. Genau hier trennt sich professionelles Streckengeschäft von der Bastellösung: nicht in der Idee, sondern in der Schnittstelle.
Streckengeschäft ist ein Datenproblem, kein Logistikproblem
Lieferantenfeeds einlesen: EDI, CSV/SFTP und REST-API
Lieferanten stellen Bestands- und Preisdaten auf sehr unterschiedliche Weise bereit. Große Distributoren fahren oft klassisches EDI mit EDIFACT-Nachrichten wie PRICAT für Preis- und Katalogdaten oder INVRPT für Bestandsberichte; mittelständische Anbieter legen eine CSV-Datei per SFTP ab, meist nächtlich; moderne Anbieter stellen eine REST-API bereit, über die sich Verfügbarkeit nahezu in Echtzeit abfragen lässt. Für einen Multi-Lieferanten-Betrieb heißt das: Ein Shop muss mit mehreren Kanälen gleichzeitig umgehen, ohne für jeden Lieferanten eine eigene Insellösung zu bauen. Die Details der klassischen Variante vertieft unser Beitrag zur EDI-Anbindung mit EDIFACT.
| Kanal | Typisch für | Aktualität | Charakteristik |
|---|---|---|---|
| EDI / EDIFACT | Große Distributoren, Industrie | Batch bis ereignisnah | Standardisiert (PRICAT, INVRPT), aber formatstreng |
| CSV über SFTP | Mittelstand, klassischer Großhandel | Meist nächtlich | Einfach, aber ohne Schema-Garantie |
| REST-API | Plattformnahe, moderne Anbieter | Nahezu Echtzeit | Flexibel, mit Ratenlimits und Auth |
| Punchout / OCI | Beschaffungsnahe Kataloge | Interaktiv | Katalog beim Lieferanten, Warenkorb zurück |
Keiner dieser Kanäle ist per se besser. Entscheidend ist, dass die Middleware alle einlesen und auf ein gemeinsames Datenmodell abbilden kann, statt die Anbindung an das schwächste Format zu koppeln. Ein Lieferant mit nächtlicher CSV liefert eben eine tagesaktuelle Momentaufnahme, ein API-Lieferant eine nahezu aktuelle Sicht -- und beide Realitäten müssen im Shop korrekt als Lieferzeit und Verfügbarkeit ankommen. Der Anspruch an die Aktualität steigt mit dem Sortiment: Wer schnelldrehende Artikel im Streckengeschäft führt, braucht häufigere Feeds als jemand, der langlebige C-Teile vertreibt.
Feed-Frequenz an die Drehgeschwindigkeit koppeln
Datenqualität und Mapping unterschiedlicher Lieferantenformate
Der anspruchsvollste Teil im Streckengeschäft ist selten die Verbindung, sondern die Übersetzung. Jeder Lieferant benennt Felder anders, misst in anderen Einheiten und definiert Bestand unterschiedlich. Ohne konsequentes Mapping laufen zwei Feeds nebeneinander her und der Shop zeigt widersprüchliche Angaben. Wie sich heterogene Quellen auf ein einheitliches Modell abbilden lassen, behandelt unser Beitrag zum Daten-Mapping zwischen ERP und Shop im Detail. Die folgenden sechs Felder sind die häufigsten Stolpersteine (Projekterfahrung).
Artikelnummern-Mapping
Lieferanten-Artikelnummer, eigene Artikelnummer, EAN und Hersteller-Nummer müssen eindeutig verknüpft sein -- sonst wird der falsche Artikel beim Lieferanten beauftragt.
Einheiten und Mengen
Verpackungseinheit, Mindestbestellmenge und Staffelung variieren je Lieferant. Ein Feed in Gebinden muss auf die Verkaufseinheit im Shop umgerechnet werden.
Preislogik
Einkaufspreis, Staffelpreise, Zu- und Abschläge und Währung kommen unterschiedlich. Der Verkaufspreis entsteht daraus im ERP, nicht im Feed.
Bestandsdefinition
Ist der gemeldete Bestand frei verfügbar, reserviert oder inklusive Zulauf? Dieselbe Zahl bedeutet je Lieferant etwas anderes und muss normalisiert werden.
Zeitpunkt und Zeitzone
Ein nächtlicher Feed ist eine Momentaufnahme mit Zeitstempel. Ohne sauberen Zeitbezug wirkt veralteter Bestand fälschlich wie aktueller.
Kategorien und Attribute
Klassifikation, Attribute und Beschreibungen folgen je Lieferant eigenen Schemata und müssen auf die Kategorien und die Produktdaten-Pipeline des Shops gemappt werden.
Ein Datenmodell, viele Lieferanten
Datenqualität ist dabei kein Selbstzweck. Unzureichende Produktangaben zählen zu den Gründen, warum Käufe abbrechen; die durchschnittliche Warenkorbabbruchrate liegt bei rund 70 Prozent (Baymard Institute). Wenn Bestand, Lieferzeit oder Preis im Shop nicht stimmen, kostet das Conversion und produziert Nacharbeit. Der Aufwand, Lieferantendaten sauber zu mappen, zahlt sich damit unmittelbar im Verkauf aus -- gerade weil der durchschnittliche Bestellwert im E-Commerce 2025 mit 146,19 Euro angegeben wird (bevh) und jede vermeidbare Stornierung einen realen Deckungsbeitrag kostet.
Verfügbarkeit und Lieferzeit je Lieferant im Shop spiegeln
Sobald die Feeds normalisiert einlaufen, muss der Shop die richtige Aussage treffen: Ist der Artikel verfügbar, und wann kommt er an? Bei Streckenware setzt sich die Lieferzeit aus der Bearbeitungszeit des Lieferanten und dem Versand zusammen -- sie unterscheidet sich von der Lagerware, die sofort ab eigenem Lager geht. Diese Differenz gehört transparent in den Shop, nicht in eine pauschale Standardangabe. Wie sich Bestände über mehrere Quellen konsistent halten lassen, zeigt unser Beitrag zur Bestandssynchronisation über mehrere Lager.
- Bestand normalisieren: Aus dem Lieferanten-Feed wird der frei verfügbare Bestand ermittelt -- bereinigt um Reservierungen und je Lieferant einheitlich definiert.
- Lieferzeit berechnen: Bearbeitungszeit des Lieferanten plus Versanddauer ergeben die Streckenlieferzeit, die der Shop je Artikel und Lieferant ausweist.
- Puffer und Schwellen: Ein kleiner Sicherheitsabzug auf knappe Bestände verhindert, dass die letzte gemeldete Einheit doppelt verkauft wird.
- Alter des Feeds bewerten: Ist der Feed zu alt, wird der Artikel konservativer dargestellt oder auf Anfrage gesetzt, statt veraltete Verfügbarkeit zu zeigen.
- Anzeige im Shop: Kunden sehen Verfügbarkeit und realistische Lieferzeit je Lieferant -- nicht eine geschönte Sammelangabe für das ganze Sortiment.
Fehlender Bestand ist der Normalfall, nicht die Ausnahme
Diese Ausfallmuster sind kein Nischenthema, sondern der Alltag im Multi-Lieferanten-Betrieb. Robuste Schnittstellen behandeln fehlende oder fehlerhafte Daten als Regelfall und nicht als Störung -- die Prinzipien dazu vertieft unser Beitrag zur Fehlerbehandlung in Schnittstellen. Für den Kunden zählt am Ende, dass die Zusage im Shop hält: Eine hohe Kundenzufriedenheit im E-Commerce von 96,2 Prozent (bevh) entsteht auch daraus, dass Verfügbarkeit und Lieferzeit verlässlich stimmen.
Bestellungen automatisch nach Lieferant splitten
Ein Warenkorb enthält im Streckengeschäft oft Positionen von mehreren Lieferanten, teils gemischt mit eigener Lagerware. Geht die Bestellung ein, muss sie automatisch nach Lieferant zerlegt und beauftragt werden -- jede Teilbestellung an den zuständigen Lieferanten, jede Lagerposition an das eigene Lager. Diese Zerlegung gehört in die Middleware, weil der Shop die Beschaffungslogik nicht kennen soll und das ERP als führendes System die Bestellung sauber abbildet. Das Grundmuster ist überschaubar:
def split_order(order, catalog):
groups = {}
for line in order.lines:
item = catalog.lookup(line.sku)
# Bezugsquelle je Position: eigenes Lager oder Lieferant
if item.source == 'stock':
key = 'WAREHOUSE'
else:
key = item.supplier_id # Streckenlieferant
groups.setdefault(key, []).append(line)
purchase_orders = []
for key, lines in groups.items():
if key == 'WAREHOUSE':
purchase_orders.append(pick_from_stock(lines))
else:
po = build_supplier_po(key, lines) # je Lieferant
purchase_orders.append(po)
return purchase_orders # ans ERP zur BestaetigungWichtig ist, dass die Aufteilung nachvollziehbar bleibt: Zu jeder Kundenbestellung gehören eine oder mehrere Lieferantenbestellungen, die als zusammengehörig verknüpft sind. Nur so lassen sich später Teillieferungen, Tracking und Rechnungen korrekt zuordnen. Das ERP führt dabei die Bestellung, die Preise und die Beschaffung; die Middleware orchestriert den Fluss und übergibt an das führende System, statt eine zweite Bestell-Engine im Shop aufzubauen.
- Gruppierung nach Bezugsquelle: Jede Position wird ihrer Quelle zugeordnet -- eigenes Lager oder ein konkreter Streckenlieferant.
- Verknüpfung erhalten: Kundenbestellung und alle abgeleiteten Lieferantenbestellungen bleiben referenziert, damit Status und Tracking eindeutig bleiben.
- Mindestmengen berücksichtigen: Staffelung und Mindestbestellmenge je Lieferant fließen in die Teilbestellung ein, bevor sie beauftragt wird.
- Idempotenz sichern: Eine wiederholte Verarbeitung derselben Bestellung darf keine doppelte Beauftragung auslösen.
- Übergabe ans ERP: Die Teilbestellungen laufen ins ERP, das Bestellung, Einkaufspreis und Buchung führt.
Tracking und Wareneingangsmeldungen zurückführen
Der Fluss endet nicht mit der Beauftragung. Der Lieferant bestätigt den Versand, liefert eine Sendungsnummer und meldet, was tatsächlich versandt wurde. Diese Rückmeldungen müssen den Weg zurück in Shop und ERP finden, damit der Kunde eine Sendungsverfolgung erhält und die Bestellung korrekt als erfüllt gilt. Ohne diesen Rücklauf bleibt die Streckenbestellung im System offen, obwohl die Ware längst beim Kunden ist. Die technischen Muster teilt der Rücklauf mit anderen Logistikprozessen, wie unser Beitrag zu Versand- und Logistik-Schnittstellen zeigt.
Versandbestätigung und Tracking
Die Sendungsnummer des Lieferanten wird der Kundenbestellung zugeordnet und dem Kunden bereitgestellt -- je Teilsendung, wenn mehrere Lieferanten beteiligt sind.
Teillieferungen abbilden
Versendet ein Lieferant nur einen Teil, bleibt die Bestellung teilweise offen. Der Status je Position spiegelt genau, was schon unterwegs ist und was noch aussteht.
Wareneingangsmeldung
Die Meldung, was tatsächlich versandt oder als Wareneingang gebucht wurde, fließt zurück ins ERP -- Grundlage für Rechnung, Bestandsführung und Abgleich.
Streckengeschäft ist erst dann automatisiert, wenn nicht nur die Bestellung hinaus-, sondern auch Tracking und Wareneingang zurückläuft. Der Rücklauf schließt den Kreis, den die Beauftragung geöffnet hat.
Lager- und Streckenware sauber trennen in einem Shop
Ein Shop führt selten reine Streckenware. Meist mischen sich eigene Lagerartikel und Streckenartikel, manche Artikel sind sogar aus beiden Quellen beziehbar. Damit ein Bestell- und Bestandsprozess beide Wege ohne Widerspruch abbildet, braucht das Datenmodell eine klare Kennzeichnung der Bezugsquelle je Artikel und je Position. Die Trennung ist kein kosmetisches Detail, sondern entscheidet über Verfügbarkeit, Lieferzeit und die Beauftragung im Bestell-Split.
| Merkmal | Lagerware | Streckenware |
|---|---|---|
| Bestandsquelle | Eigenes Lager im ERP | Lieferanten-Feed (EDI/CSV/API) |
| Lieferzeit | Sofort ab Lager | Bearbeitung Lieferant plus Versand |
| Beauftragung | Kommissionierung im eigenen Lager | Bestellung beim Streckenlieferanten |
| Aktualisierung | Echtzeit aus dem ERP | Feed-Frequenz des Lieferanten |
| Rücklauf | Eigener Versanddienstleister | Tracking und WE-Meldung des Lieferanten |
Ist ein Artikel aus beiden Quellen beziehbar, entscheidet eine definierte Regel über den Bezugsweg -- etwa Vorrang für eigenen Lagerbestand, solange verfügbar, sonst Strecke. Diese Logik gehört ins führende System und in die Middleware, nicht in eine Einzelentscheidung pro Bestellung. Grundlage bleibt eine konsistente Stammdatenbasis, wie sie unser Beitrag zur Stammdaten-Synchronisation mit MDM beschreibt: Nur wenn Artikel, Preise und Bezugsquellen zentral geführt sind, bleibt die Trennung von Lager- und Streckenware belastbar.
Steuer und Retouren gelten auch für Streckenware
Fehlerbehandlung und Umsetzung als Middleware
Die Einführung eines automatisierten Streckengeschäfts folgt einem überschaubaren Ablauf. Entscheidend ist, die Lieferanten und ihre Formate früh zu erfassen und die Fehlerbehandlung von Anfang an mitzudenken -- denn im Multi-Lieferanten-Betrieb ist nicht die Frage, ob ein Feed ausfällt, sondern wann. Der B2B-Internethandel wächst laut IFH Köln 2025 voraussichtlich um weitere 6,3 Prozent (IFH Köln); wer Streckenware sauber automatisiert, kann dieses Wachstum ohne proportional wachsende Handarbeit mitnehmen.
Von der Lieferantenaufnahme zum produktiven Streckenprozess
- 1
Lieferanten und Formate erfassen
Je Lieferant Kanal (EDI, CSV/SFTP, REST-API), Frequenz, Feldstruktur und Bestandsdefinition dokumentieren -- die Grundlage für das Mapping.
- 2
Kanonisches Datenmodell definieren
Ein gemeinsames Modell für Artikel, Bestand, Preis und Lieferzeit festlegen, auf das jeder Lieferant per eigenem Mapping abgebildet wird.
- 3
Feeds und Mapping bauen
Konnektoren je Kanal, Normalisierung der Formate und die Spiegelung von Verfügbarkeit und Lieferzeit in den Shop entwickeln.
- 4
Bestell-Split und Rücklauf
Automatisches Splitten nach Lieferant, Übergabe ans ERP sowie die Rückführung von Tracking und Wareneingangsmeldung umsetzen.
- 5
Test, Ausfallverhalten, Go-Live
Mit echten Feeds testen, Ausfall- und Grenzfälle kalibrieren und den Produktivbetrieb mit Überwachung von Feed-Aktualität und Fehlerquoten starten.
Aus Projekten kristallisieren sich wiederkehrende Fehler heraus, die sich mit etwas Vorausschau vermeiden lassen (Projekterfahrung). Wer sie einplant, verhindert falsche Verfügbarkeiten, doppelte Beauftragungen und offene Bestellungen im Livebetrieb.
- Ein Feed als einzige Wahrheit: Ohne Zeitstempel und Ausfallregel gilt veralteter Bestand fälschlich als aktuell.
- Fehlendes Artikelnummern-Mapping: Wird die falsche Lieferanten-Artikelnummer beauftragt, kommt der falsche Artikel beim Kunden an.
- Keine Trennung von Lager- und Streckenware: Vermischen sich die Bezugsquellen, wird der Bestell-Split unzuverlässig.
- Rücklauf vergessen: Ohne Tracking- und Wareneingangsmeldung bleiben Bestellungen offen, obwohl die Ware geliefert ist.
- Keine Idempotenz: Wiederholt verarbeitete Bestellungen lösen doppelte Beauftragungen beim Lieferanten aus.
- Feed-Frequenz zu grob: Schnelldrehende Artikel mit zu seltenem Feed führen zu Verkäufen ohne Deckung durch echten Bestand.
Wir bauen diese Orchestrierung als Middleware, die mehrere Lieferantenkanäle einliest, auf ein Datenmodell normalisiert und Strecken- wie Lagerware in einen Bestell- und Bestandsprozess zusammenführt. Welche Kanäle, Formate und Frequenzen für Ihr Sortiment sinnvoll sind, klären wir im Rahmen unserer Leistungen rund um ERP- und Shop-Integration.
Quellen und Studien