Amazon EDI: der Datenaustausch im Vendor-Modell, Nachrichten, Fristen, Fehlerkosten

Was Amazon EDI ist, und warum es selten eine Option bleibt

EDI steht für Electronic Data Interchange und bezeichnet den strukturierten Austausch von Geschäftsdokumenten zwischen zwei IT-Systemen, ohne dass ein Mensch etwas abtippt. Im Amazon-Vendor-Modell ist EDI kein Nice-to-have, sondern die Standard-Betriebsart der Geschäftsbeziehung: Amazon bestellt maschinell, erwartet maschinelle Antworten und rechnet maschinell ab.

Der entscheidende Punkt, den viele Marken vor der Anbindung unterschätzen: EDI ist keine parallele Komfort-Option neben dem Portal. Sobald eine Nachrichtenart in Vendor Central produktiv geschaltet wird, deaktiviert Amazon die manuelle Erfassung für genau diese Nachrichtenart. Wer die Rechnungsstellung auf INVOIC umstellt, kann Rechnungen danach nicht mehr im Portal eintippen. Die Anbindung ist damit keine Migration mit Rückweg, sondern ein Umschalten.

Für Seller (3P) und für Marken im Broker-Modell stellt sich diese Frage nicht. EDI im hier beschriebenen Sinn ist eine Eigenschaft der 1P-Großhandelsbeziehung, in der Amazon als Einkäufer auftritt und deshalb einen Einkaufs-Dokumentenfluss braucht. Wer über Seller Central verkauft, arbeitet stattdessen mit der Selling Partner API und mit Endkundenbestellungen.

Der Bestellzyklus in vier Nachrichten

Der operative Kern von Amazon EDI besteht aus vier Nachrichtentypen, die einen Kreis bilden. In Europa läuft er im EDIFACT-Standard, in Nordamerika im ANSI-X12-Standard. Die Namen unterscheiden sich, die Logik ist identisch.

Ergänzend kommen Nachrichten hinzu, die je nach Programm und Marktplatz aktiviert werden: die Funktions-Quittung (997 / CONTRL), die bestätigt, dass eine Datei technisch angekommen und lesbar ist, Routing-Anfrage und Routing-Anweisung (753 / 754) im Collect-Versand, Bestandsmeldungen (846 / INVRPT) und die Zahlungsavise (820 / REMADV), die eine Überweisung den Rechnungen und Abzügen zuordnet. Wer Abzüge sauber nachvollziehen will, braucht die Zahlungsavise, denn ohne sie bleibt die Zuordnung von Chargebacks zu Lieferungen Handarbeit.

• ORDERS / EDI 850: Amazon sendet die Bestellung (Purchase Order) mit Artikeln, Mengen, Preisen, Lieferfenster und Zielstandort
• ORDRSP / EDI 855: der Vendor bestätigt pro Position, was er liefern kann, ablehnt oder rückständig meldet
• DESADV / EDI 856: das Versandavis (ASN) kündigt die konkrete Sendung an, inklusive Kartons, Paletten und Inhalt je Packstück
• INVOIC / EDI 810: die Rechnung, die sich auf Bestellung und Sendung zurückbeziehen muss

Die Fristen, an denen Anbindungen scheitern

Technisch funktionierende EDI-Anbindungen fallen selten an der Übertragung durch. Sie fallen an Fristen durch. Amazon bewertet nicht nur, ob eine Nachricht korrekt ist, sondern ob sie rechtzeitig kam, und knüpft daran Abzüge.

Die Auftragsbestätigung ist typischerweise innerhalb von 48 Stunden nach Eingang der Bestellung fällig. Wird sie nicht gesendet, gelten Positionen als unbestätigt und Amazon behandelt das als Compliance-Verstoß. Das Versandavis muss vor der physischen Anlieferung im Fulfillment-Center liegen, praktisch also einige Stunden vor Ankunft des Fahrzeugs, nicht am selben Nachmittag. Die Rechnung folgt zeitnah nach der Versandbestätigung. Im Collect-Versand kommt eine eigene Frist für die Routing-Anfrage dazu, die sich am Ende des vereinbarten Lieferfensters orientiert.

Die konkreten Fristen und Schwellen unterscheiden sich nach Marktplatz, Programm und Kategorie, und Amazon passt sie an. Die belastbare Regel ist deshalb nicht die einzelne Stundenzahl, sondern das Prinzip: Jede Nachricht des Zyklus hat ein Zeitfenster, und die Prozesskette dahinter (Lager, Buchhaltung, Freigaben) muss in dieses Fenster passen. Wer die Anbindung baut, ohne die interne Ablaufkette daran auszurichten, produziert eine automatisierte Verspätung.

Warum EDI-Qualität direkt auf die Marge durchschlägt

Amazon sanktioniert Abweichungen im Vendor-Modell über Chargebacks, also Abzüge von der Rechnung. Ein großer Teil dieser Abzüge hat keine logistische Ursache, sondern eine datenseitige: Das Versandavis nennt andere Mengen als der Karton enthält, die Bestellreferenz stimmt nicht, Kartonlabels passen nicht zur angekündigten Struktur, eine Bestätigung fehlt.

Die Höhe wird üblicherweise als Prozentsatz der Warenkosten oder als Betrag je Einheit berechnet und ist bei mehreren Verstoßarten nach Compliance-Quote gestaffelt: Wer knapp unter der Zielquote liegt, zahlt spürbar weniger als wer deutlich darunter liegt. Damit entsteht eine unangenehme Dynamik, denn schlechte Datenqualität wird überproportional teuer, statt linear.

In der Praxis heißt das: Die EDI-Anbindung ist kein IT-Projekt mit einmaligem Abschluss, sondern ein laufender Qualitätsprozess. Der wirksamste Hebel liegt fast nie im EDI-Konverter selbst, sondern eine Stufe davor, im Lagersystem. Wenn Versandavis-Daten aus derselben Quelle kommen wie die tatsächliche Kommissionierung, verschwindet die häufigste Fehlerklasse. Wenn jemand Mengen aus einer Liste in ein zweites System überträgt, kommt sie zuverlässig wieder.

Wie die Verbindung technisch zustande kommt

Für den Transport der Nachrichten lässt Amazon im Wesentlichen drei Wege zu: AS2 als verschlüsselte Direktverbindung über HTTPS, die Amazon selbst bevorzugt, ein von Amazon bereitgestelltes SFTP-Postfach, das in festen Intervallen abgeholt wird, und die Anbindung über ein Value Added Network (VAN), also einen Netzbetreiber, der als Zwischenstation fungiert.

Vor dem Produktivbetrieb steht ein Zertifizierungsprozess, den Vendoren in Vendor Central selbst durchlaufen. Getestet wird nicht nur, ob die Datei dem Format entspricht, sondern ob die Antworten inhaltlich zu den Testszenarien passen: vollständige Verfügbarkeit, Teilverfügbarkeit, ausgelisteter Artikel, ungültige Position. Erst wenn alle Szenarien einer Nachrichtenart bestanden sind, gibt Amazon diese Nachrichtenart produktiv frei, und zwar einzeln.

Diese Freigabe je Nachrichtenart ist der Grund, warum eine EDI-Einführung meist gestaffelt läuft: erst Bestellung und Bestätigung, dann Versandavis, zuletzt Rechnung. Das ist sinnvoll, denn jede Stufe deckt eigene Prozessprobleme auf.

EDI, SP-API oder manuell: die drei Betriebsmodi

Neben EDI existiert die Selling Partner API (SP-API), über die Amazon auch Vendor-Prozesse abbildbar macht. Beide Wege bestehen derzeit nebeneinander, mit unterschiedlichen Schwerpunkten: Das klassische Großhandelsgeschäft mit Bestellungen an Amazon-Lager läuft weit überwiegend über EDI, während neue Direct-Fulfillment-Anbindungen, bei denen der Vendor direkt an den Endkunden versendet, über die API eingerichtet werden. Ein angekündigtes Ende von EDI gibt es nicht.

Für die Praxis bedeutet das: Die Frage lautet nicht EDI oder API, sondern welcher Prozess über welchen Kanal läuft. Marken mit beiden Programmen betreiben in der Regel beides parallel.

Der dritte Modus ist die manuelle Bearbeitung direkt im Vendor-Central-Portal. Sie ist der Startzustand jeder neuen Vendor-Beziehung und funktioniert bei kleinen Bestellvolumen. Ihre Grenze ist keine technische, sondern eine arbeitszeitliche: Sobald mehrere Bestellungen pro Woche mit vielen Positionen eingehen, ist die Portal-Bearbeitung nicht mehr zuverlässig fristgerecht zu leisten, und genau dann beginnen die Abzüge.

• Manuell im Portal: kleine Volumen, kein Setup-Aufwand, aber fristanfällig und personengebunden
• EDI: Standard für das Großhandelsgeschäft, Setup- und Betriebsaufwand, dafür belastbar im Volumen
• SP-API: Weg für neue Direct-Fulfillment-Anbindungen, ergänzt EDI, ersetzt es im Kerngeschäft nicht

Wer die Anbindung betreibt, und woraus die Kosten bestehen

Für den Betrieb gibt es drei übliche Konstellationen. Erstens: Das ERP- beziehungsweise Warenwirtschaftssystem bringt eine Amazon-Vendor-Anbindung mit oder es gibt einen Connector dafür. Zweitens: Ein EDI-Dienstleister oder eine Middleware sitzt zwischen Amazon und dem eigenen System und übernimmt Konvertierung, Transport und Monitoring. Drittens: Die Anbindung wird intern entwickelt, was in der Regel nur bei eigener IT-Mannschaft und hohem Volumen sinnvoll ist.

Die Kosten setzen sich fast immer aus denselben Blöcken zusammen, unabhängig vom Anbieter: einmaliger Aufwand für Mapping und Zertifizierung, laufende Gebühren für Plattform oder Netzbetreiber, häufig mit einer volumenabhängigen Komponente, und interne Betreuung für Fehlerbearbeitung. Der dritte Block wird am häufigsten vergessen und ist der einzige, der dauerhaft Personalzeit bindet, denn Fehlermeldungen aus dem Zyklus müssen jemanden erreichen, der sie am selben Tag versteht und behebt.

Bei den Einführungszeiten gehen die Angaben der Anbieter weit auseinander, von wenigen Wochen bei fertigen Plattform-Anbindungen bis zu mehreren Monaten bei klassischen Netzbetreiber-Projekten oder Eigenentwicklung. Realistisch kalkuliert man nicht die Anbindungszeit, sondern die Zeit bis zur stabilen Fehlerquote, und die liegt regelmäßig deutlich später, weil die ersten echten Lieferungen die Prozesslücken zeigen.

Wann sich die EDI-Frage strukturell erledigt

EDI ist eine Konsequenz des Vendor-Modells, keine eigenständige Entscheidung. Wer als Vendor bei Amazon liefert, braucht ab einem gewissen Volumen diese Datenleitung, weil die Fristen sonst nicht zu halten sind. Wer das Modell wechselt, verliert die Anforderung mit dem Modell: Im 3P-Seller-Betrieb gibt es keine Amazon-Bestellungen und damit keinen Bestellzyklus, und im Broker-Modell liegt der gesamte Marktplatz-Betrieb inklusive etwaiger Anbindungen beim Merchant of Record, während die Marke im klassischen B2B-Rhythmus an den Broker liefert.

Das ist kein Argument gegen EDI und schon gar keine Empfehlung, das Modell wegen einer Schnittstelle zu wechseln. Es ist eine Einordnung für Marken, die gerade beides gleichzeitig auf dem Tisch haben, eine anstehende EDI-Investition und eine grundsätzliche Unzufriedenheit mit den Vendor-Konditionen. In dieser Konstellation lohnt es sich, die Reihenfolge bewusst zu wählen, statt eine mehrjährige Integration zu bauen, deren Geschäftsgrundlage im nächsten Verhandlungsjahr zur Debatte steht.