Definition
EDI steht für Electronic Data Interchange und bezeichnet den Austausch strukturierter Geschäftsdokumente zwischen den IT-Systemen zweier Unternehmen. Statt eine Bestellung als PDF zu mailen und im ERP abzutippen, wird sie als maschinenlesbare Nachricht in einem vereinbarten Standard übertragen und automatisch verbucht. Die beiden dominierenden Standards sind UN/EDIFACT (international, in Europa vorherrschend) und ANSI X12 (überwiegend Nordamerika). Ein EDI-Setup besteht immer aus drei Teilen: dem Standard (welches Nachrichtenformat), dem Mapping (wie die Felder des Standards auf die Felder des eigenen ERP passen) und dem Transportweg (wie die Datei physisch übertragen wird, etwa per AS2 oder SFTP). Der aufwendige Teil ist fast nie der Standard, sondern das Mapping.
Warum ist das wichtig?
Für den Amazon-Kontext ist entscheidend, in welchem Modell verkauft wird. Im Vendor-Modell (1P) tritt Amazon als Einkäufer auf und erwartet eine EDI-Anbindung: Purchase Orders kommen automatisiert herein, Lieferavis und Rechnung müssen strukturiert und fristgerecht zurückgehen. Fehlende, verspätete oder inhaltlich abweichende Nachrichten führen im Vendor-Modell regelmäßig zu Abzügen und Rückbelastungen. Im Seller-Modell (3P) verkauft der Händler selbst über Seller Central; hier gibt es keine EDI-Anbindung, die Automatisierung läuft über die SP-API. Wer als Hersteller mit einem ERP arbeitet und über Amazon verkaufen will, steht deshalb vor einer Architekturentscheidung — Vendor mit EDI-Projekt, Seller mit API-Projekt, oder ein Broker-Modell, bei dem ein Partner als Verkäufer auftritt und das eigene ERP nur noch eine Schnittstelle bedienen muss.
So funktioniert es
Ein Amazon-Vendor-EDI-Setup umfasst typischerweise diese Nachrichten (EDIFACT-Bezeichnung, X12-Nummer in Klammern): ORDERS (850) für die Bestellung, ORDRSP (855) für die Bestellbestätigung inklusive Absagen und Mengenkorrekturen, DESADV (856) für das Lieferavis, INVOIC (810) für die Rechnung, ORDCHG (860) für Bestelländerungen, RECADV für die Wareneingangsmeldung und INVRPT/SLSRPT für Bestands- und Absatzdaten. Als Transportweg bevorzugt Amazon AS2; daneben werden ein von Amazon gehostetes SFTP sowie die Anbindung über einen VAN (Value Added Network) unterstützt. Die verbindlichen Feldanforderungen, Fristen und regionalen Abweichungen stehen in Amazons EDI-Spezifikation, die Vendoren über Vendor Central erhalten — sie unterscheidet sich je nach Region und Warengruppe und ist die einzig maßgebliche Quelle für ein konkretes Setup.
Praxis-Beispiele
• Ein Möbelhersteller im Vendor-Modell empfängt montags eine ORDERS über 400 Positionen, bestätigt sie am selben Tag per ORDRSP mit zwei Mengenkorrekturen, meldet den Versand per DESADV mit SSCC-Nummern je Palette und stellt nach Wareneingang per INVOIC die Rechnung — ohne dass ein Mitarbeiter eine Zeile tippt. • Ein Nahrungsergänzungs-Hersteller verkauft im Seller-Modell und sucht nach „Amazon EDI", findet aber keine EDI-Anbindung: Für Seller Central gibt es keine, Bestände und Bestellungen laufen über die SP-API. • Ein Zulieferer der Automobilbranche hat seit Jahren EDIFACT-Anbindungen an OEM-Kunden im ERP und will diese Logik für Amazon wiederverwenden — das Mapping ist ein anderes, die vorhandene EDI-Infrastruktur und das Know-how lassen sich aber weiternutzen. • Ein Händler sucht „AWS EDI" und landet beim falschen Thema: Amazon Web Services bietet mit AWS B2B Data Interchange einen eigenen Cloud-Dienst zur EDI-Verarbeitung. Der hat mit dem Verkauf auf amazon.de nichts zu tun.
Typische Fehler
• **EDI mit ERP verwechseln:** Ein ERP ist das System, in dem die Daten leben; EDI ist der Weg, auf dem sie das Haus verlassen. Ein ERP ersetzt kein EDI und umgekehrt. • **EDI als Seller suchen:** Wer über Seller Central verkauft, wird nie eine EDI-Anbindung an Amazon bekommen. Das richtige Stichwort ist SP-API. • **Das Mapping unterschätzen:** Der Standard ist dokumentiert, die eigenen Artikel-, Verpackungs- und Preisstammdaten sind es meist nicht. Erfahrungsgemäß liegt hier der größte Teil des Projektaufwands. • **Fristen ignorieren:** Im Vendor-Modell sind Bestätigungs- und Avis-Fristen Teil der Vereinbarung. Verspätete oder fehlende Nachrichten sind ein häufiger Grund für Rückbelastungen. • **Nur an den Bestellweg denken:** Ein EDI-Projekt endet nicht bei der ORDERS. Ohne saubere DESADV mit korrekten Verpackungseinheiten und ohne INVOIC, die zur Bestellung passt, entstehen Abweichungen, die später mühsam geklärt werden müssen.
Häufige Fragen
Was ist Amazon EDI?+
Amazon EDI ist der automatisierte, standardisierte Belegaustausch zwischen Amazon und seinen Lieferanten im Vendor-Modell (1P). Amazon sendet Bestellungen als EDIFACT- oder X12-Nachricht an das System des Lieferanten, dieser antwortet mit Bestellbestätigung, Lieferavis und Rechnung auf demselben Weg. Ziel ist ein Bestellprozess ohne manuelle Erfassung auf beiden Seiten.
Welche EDI-Nachrichten verlangt Amazon?+
Im Kern ORDERS (X12 850) für die Bestellung, ORDRSP (855) für die Bestätigung, DESADV (856) für das Lieferavis und INVOIC (810) für die Rechnung. Je nach Region und Warengruppe kommen ORDCHG (860) für Bestelländerungen, RECADV für den Wareneingang sowie INVRPT und SLSRPT für Bestands- und Absatzdaten dazu. Maßgeblich ist immer Amazons EDI-Spezifikation für den konkreten Account, die über Vendor Central bereitgestellt wird.
Brauche ich als Amazon-Seller EDI?+
Nein. EDI ist die Anbindung des Vendor-Modells (1P). Wer über Seller Central verkauft, automatisiert über die SP-API — eine EDI-Schnittstelle zu Amazon gibt es dort nicht. Relevant wird EDI für Seller nur indirekt: wenn das eigene ERP ohnehin EDI spricht, etwa gegenüber Handelskunden, und diese Logik auch für den Amazon-Kanal genutzt werden soll.
Was ist der Unterschied zwischen EDI und einer API?+
EDI überträgt fertige Belege in einem normierten Format, meist gebündelt und zeitversetzt — ein Dateistrom zwischen zwei Firmen. Eine API stellt einzelne Datensätze in Echtzeit auf Abruf bereit und ist enger an das jeweilige System gebunden. EDI ist branchenübergreifend standardisiert und deshalb zwischen beliebigen Partnern wiederverwendbar; eine API ist herstellerspezifisch, dafür aktueller und flexibler.
Welche Transportwege unterstützt Amazon für EDI?+
AS2 ist der von Amazon bevorzugte Weg. Daneben werden ein von Amazon gehostetes SFTP und die Anbindung über einen VAN (Value Added Network) unterstützt. Welcher Weg für einen konkreten Account möglich ist, legt Amazon im Onboarding fest.
Ist AWS EDI dasselbe wie Amazon EDI?+
Nein, das sind zwei verschiedene Dinge. AWS B2B Data Interchange ist ein Cloud-Dienst von Amazon Web Services, mit dem Unternehmen EDI-Nachrichten beliebiger Handelspartner verarbeiten können. Amazon EDI meint die Anbindung an Amazon als Einkäufer im Vendor-Modell. Wer auf amazon.de verkauft, braucht das zweite, nicht das erste.