Amazon EDI vs. SP-API: Was sich für Vendoren ändert

Amazon betreibt zwei getrennte Programme für alle, die über die Plattform verkaufen. Amazon Vendor Central ist das geschlossene Lieferantenportal: Amazon kauft Bestand über Bestellungen (Purchase Orders) und verkauft ihn selbst als Einzelhändler weiter, sodass Vendoren mit Amazon selbst und nicht mit dem Endkunden zu tun haben, und der Eintrag erscheint für Kunden als „Verkauf und Versand durch Amazon“. Das Amazon Seller Central ist die Marktplatzseite, auf der Verkäufer direkt an Kunden listen und verkaufen. 

Vendor selbst teilt sich wiederum in zwei Abläufe: den sogenannten „Retail”-Weg, bei dem Amazon die Ware physisch in seine eigenen Fulfillment-Center übernimmt, und „Direct Fulfillment” (DF), im Grunde Amazons Version von Dropshipping, bei dem Amazon die Bestellung entgegennimmt, der Vendor sie aber aus seinem eigenen Lager versendet. Alles Folgende gilt für Vendoren in beiden Abläufen, da beide über denselben Zyklus aus Bestellung, Versand und Rechnungsstellung laufen.

Für den größten Teil der Zeit, in der es Vendor Central gibt, war EDI der einzige Weg, sich als Großhandelslieferant elektronisch mit Amazon zu verbinden – was Amazon selbst noch immer „elektronische Integration” nennt. Amazons Selling Partner API (SP-API) hat sich erst vor etwa zwei bis drei Jahren speziell für Vendor-Konten geöffnet, statt wie zuvor nur Seller Central vorbehalten zu sein. Viele Vendor-Ops-Teams wissen bis heute nicht, dass API für sie überhaupt eine Option ist. EDI wurde vor Jahren eingerichtet, es funktioniert, und niemand hatte einen Grund, nach einer Alternative zu suchen. Unternehmen ohne bestehende EDI-Infrastruktur, oder solche, die die hohen Anfangskosten für deren Aufbau scheuten, haben eine direkte Vendor-Central-Beziehung oft ganz übersprungen und stattdessen auf anderem Weg an Amazon verkauft.

EDI selbst gab es schon Jahrzehnte vor Amazon

Große Hersteller und Distributoren nutzen es mit Handelspartnern im Einzelhandel schon lange, bevor Amazon überhaupt ein relevanter Vertriebskanal war. Die Infrastruktur und die Erwartung, dass ein Lieferant EDI beherrscht, waren bereits vorhanden, als es Vendor Central noch gar nicht gab – EDI wurde deshalb auch dort zum Standard. Selbst diese seit langem etablierten EDI-Marktplätze ergänzen inzwischen API, angezogen von derselben Flexibilität, die API auch für mittelgroße Vendoren attraktiv macht und für alle, die nicht die spezielle Middleware, Übersetzungssoftware und das Value-Added Network aufbauen wollen, die EDI traditionell schon zum Einstieg erfordert. Diese Flexibilität geht über die Einrichtungskosten hinaus: Ein Marktplatz kann für jeden neuen Datenpunkt, den er braucht – Berichte, Werbemodule, Echtzeit-Datenaustausch – flexibel eigene APIs bauen, was das starre, feste EDI-Format nie unterstützen konnte.

Für viele Großhandelsbetriebe funktioniert EDI nach wie vor und ist weiterhin wichtig – nichts hier spricht dafür, es über Nacht abzuschaffen. Im Folgenden geht es darum, was die beiden Wege tatsächlich unterscheidet und warum API inzwischen eine echte Option für Vendoren ist, nicht nur eine Seller-spezifische Technik-Randnotiz. Zehn Minuten gut investiert, wenn Sie dafür zuständig sind, wie Ihr Betrieb mit Amazon kommuniziert.

Was EDI ist und warum es bisher gut funktioniert hat

EDI, kurz für Electronic Data Interchange (elektronischer Datenaustausch), bedeutet, dass Standard-Geschäftsdokumente – Bestellungen, Rechnungen, Versandavise – als strukturierte, maschinenlesbare Nachrichten ausgetauscht werden statt als PDFs, E-Mails oder Telefonanrufe. Zwei parallele Standards legen fest, wie diese Nachrichten tatsächlich aussehen: X12, festgelegt von einem US-amerikanischen ANSI-akkreditierten Gremium, und EDIFACT, die von der UN verwaltete Version, die außerhalb der USA weiter verbreitet ist. Amazons Vendor-Zyklus läuft über fünf dieser Dokumente, und beide Bezeichnungssysteme tauchen je nachdem auf, wen man fragt – es lohnt sich also, beide zu kennen:

• 850 (X12) / ORDERS (EDIFACT): Bestellung (Purchase Order)
• 855 / ORDRSP: Auftragsbestätigung
• 856 / DESADV: Versandavis (Advance Ship Notice, ASN)
• 810 / INVOIC: Rechnung
• 846: Bestandsaktualisierung

Das Format jedes einzelnen ist durch den Standard selbst festgelegt, nicht etwas, das Vendor oder Amazon von Fall zu Fall anpassen – und genau diese feste Struktur ist es, die diese Dokumente über Jahre hinweg bei Tausenden von Vendoren zuverlässig und unverändert funktionieren lässt. Es ist zudem reine Vendor-Sache: Seller-Konten, Buy Shipping und andere Logistikprogramme liegen außerhalb des EDI-Geltungsbereichs und benötigen ohnehin API-Zugang.

Dieses feste Format hat auch bei der Umsetzung seinen Preis. EDI zum Laufen zu bringen bedeutet spezielle Middleware, Übersetzungssoftware und die Zuordnung jedes einzelnen Feldes zu Amazons Nachrichtenspezifikationen – oft mit einem Value-Added Network (VAN), einem Drittanbieter-Dienst, der EDI-Nachrichten zwischen Handelspartnern empfängt, übersetzt und weiterleitet, der noch zusätzlich zwischen Seller und Amazon sitzt. Die Einrichtungszeit folgt derselben Reihenfolge: am schnellsten über eine moderne Integrationsplattform, langsamer über ein klassisches VAN, am langsamsten beim Eigenbau. Das ist kein spezifisches Problem des Eigenbaus, sondern liegt in der Natur jeder komplexen Integration: mehrere zu kombinierende Ebenen (ERP, Middleware, Übersetzungssoftware, Feldzuordnungen) und ebenso viele Systeme, die nicht dieselbe Sprache sprechen – und das alles, bevor die Zertifizierungstests gegen Amazons Nachrichtenspezifikationen überhaupt beginnen können. Eine moderne Plattform nimmt dem Seller den größten Teil dieser Arbeit ab, ein VAN einen Teil davon, und der Eigenbau bedeutet, alles selbst zu erledigen.

Diese Starrheit setzt sich im Tagesgeschäft der Integration an zwei Stellen fort:

Timing. Amazon hält feste Fristen ein, unabhängig von der gewählten Verbindungsmethode: eine 855-Bestätigung (ORDRSP) innerhalb von 48 Stunden nach der 850-Bestellung (ORDERS), eine 810-Rechnung (INVOIC) innerhalb von 24 Stunden nach Versandbestätigung, und das 856-Versandavis (DESADV) ASN, bevor die Sendung physisch im Fulfillment-Center ankommt. Bei EDI fressen Übersetzung und VAN-Zwischenschritte bereits an diesem festen Zeitfenster, bevor das Team das Dokument überhaupt zu Gesicht bekommt – es bleibt also weniger Spielraum, als die Frist selbst vermuten lässt.

Inhalt. Garbage in, garbage out: Die Nachricht muss auf beiden Seiten sauber validieren, und wenn die Produktkennungen zwischen dem System des Vendors und dem von Amazon nicht übereinstimmen, wird sie schlicht abgelehnt – bei der Warenannahme, bei der Auftragsbestätigung, wo immer die Diskrepanz zuerst auffällt.

Wer diese Fristen verpasst oder Daten sendet, die Amazon als fehlerhaft markiert, bekommt das als Chargebacks (Vertragsstrafen) zu spüren. Vendoren führen ihren Katalog zudem meist über EAN- oder GTIN-Kennungen statt über Amazons eigene ASINs, und wenn diese beiden Kennungen auseinanderlaufen (ein Produkt wird umbenannt, eingestellt oder neu gelistet, oder die ASIN ist falsch eingerichtet für die tatsächliche Versandart – Innenverpackungsmenge, Kartonmenge, Bundle-Inhalt und Ähnliches) – ist das Ergebnis: abgelehnte Bestellungen, ASN-Abweichungen und Rechnungsstreitigkeiten. Bei Vendoren, die die Compliance nicht engmaschig überwachen, summieren sich die chargeback-bedingten Abzüge über ein Jahr hinweg. Nicht bestätigte Bestellungen (Unconfirmed PO Chargebacks) und nicht konforme Versandavise sind meist die beiden größten Kostentreiber, und die Strafhöhe richtet sich in der Regel danach, wie spät oder ungenau die Meldung war.

Was SP-API ändert

In manchen Integrationsleitfäden findet sich noch immer die klare Trennlinie: EDI für Vendor Central, API für Seller Central, entlang des Geschäftsmodells Großhandel versus Marktplatz. Das traf noch vor einigen Jahren zu, bevor Amazon eigene Vendor-Endpunkte direkt in die SP-API integriert hat, die Bestellungen, Versand und Rechnungsstellung abdecken. Amazons eigene Entwicklerdokumentation für Vendoren stellt beide Verbindungsmethoden für die zentralen operativen Abläufe auf dieselbe Automatisierungsstufe, wobei die API zusätzlich Reichweite in Berichte, Listings und Marketing bietet, die EDI nie abdecken konnte. Vendoren müssen sich nicht für eines entscheiden, und viele betreiben beides gleichzeitig für unterschiedliche Unternehmensbereiche.

SP-API funktioniert in einigen konkreten Punkten anders:

• Umfang. Während EDI Lieferkettendokumente abdeckt, reicht SP-API zusätzlich in Listings, Reporting, Werbung und A+-Content hinein. Eine einzige Integrationstechnologie kann nun sowohl die Transaktionsseite als auch die Katalog-/Marketingseite eines Vendor-Kontos abdecken, und das erstreckt sich auch auf Seller- und Fulfillment-Programme, nicht nur auf Vendor.
• Format und Geschwindigkeit. Statt fester X12-/EDIFACT-Dokumente, die durch Übersetzungsebenen laufen, nutzt SP-API Standard-REST-Aufrufe: GET zum Abfragen, POST zum Übermitteln. Die Payloads sind leichter, und es ist keine VAN- oder Middleware-Schicht zur Formatübersetzung nötig – genau dort entsteht bei EDI-Abläufen ein Großteil der Verzögerung.
• Katalogabgleich. Das ist der Punkt, der für die Reduzierung von Chargebacks am wichtigsten ist. EDI-Nachrichten können technisch zwar auch ein ASIN-Feld enthalten, aber die ERPs und Middleware, mit denen die meisten Unternehmen für EDI arbeiten, sind meist nicht flexibel genug dafür. Ihr starres Framework orientiert sich in der Regel ausschließlich an EAN oder GTIN, sodass die Verknüpfung zur ASIN gar nicht erst erfasst wird. API-basierte Systeme – ein Omnichannel-System wie Base eingeschlossen – bieten mehr Spielraum, um beides einzubeziehen. SP-API selbst gibt sowohl ASIN als auch externe Kennungen (EAN, GTIN) im selben Aufruf zurück und nimmt sie entgegen, sodass ein darauf aufbauendes System eine Live-Momentaufnahme dessen ziehen kann, was tatsächlich im Amazon-Katalog eines Vendors gelistet ist, und diese mit anderen Kanälen abgleichen kann – statt sich auf eine statische EAN-/GTIN-Zuordnung zu verlassen, die still und leise veraltet.

SP-API hat allerdings noch keine vollständige Parität. Eine Handvoll Programme benötigt weiterhin EDI. WePay/Collect, Amazons Frachtkollekt-Logistikmodell, läuft über routingspezifische Dokumente (das X12-Paar 753/754 bzw. IFTMBF/IFTMIN in EDIFACT), die Abholort, genaue Lageradresse, Gewicht, Palettenanzahl und AMZNCC-Etiketten transportieren – ein Detailgrad in der Versandabwicklung, den SP-API noch nicht vollständig abbildet. Das ist aber nur eine Option neben SSCC-Etiketten.

EDI vs. SP-API im Überblick

Warum das mehr als eine technische Randnotiz ist

Für ein Vendor-Ops-Team zeigt sich der Wechsel von EDI zu API in ein paar sehr konkreten Ergebnissen:

• Potenziell weniger Chargebacks durch Katalogabweichungen, da der ASN-basierte Abgleich eine der häufigsten Ursachen für abgelehnte Bestellungen und ASN-Diskrepanzen beseitigt.
• In der Regel schnellere Bestellbestätigungs- und Auftragszyklen, da keine Übersetzungsschicht mehr zwischen dem System des Vendors und dem von Amazon sitzt.
• Geringere Kosten für neue Amazon-Programme. Sobald ein Betrieb per API integriert ist, bedeutet die Erweiterung auf Seller, FBA oder MCF kein zweites, separates Integrationsprojekt mehr – dieselbe Technologie leistet einfach mehr.
• Keine laufenden VAN-Gebühren oder EDI-Middleware-Wartung mehr – oft die am wenigsten sichtbaren, aber hartnäckigsten Kosten eines EDI-Setups. Ohne diesen Aufwand können sich das Omnichannel-System und das darüberliegende ERP auf die wirklich wertschöpfenden Aufgaben konzentrieren – Automatisierung, Reporting, kanalübergreifende Logik – statt hauptsächlich Felder zwischen Formaten zuzuordnen.

Base betreibt Amazon-Vendor-Integrationen bereits über SP-API und arbeitet auch bei mehreren anderen Amazon-Programmen mit Amazon zusammen. Mit „Automatisierten Aktionen” kann ein Vendor genau festlegen, wie Bestellungen, Versand und Rechnungen sich innerhalb von Base bewegen – abgestimmt auf den eigenen Workflow statt auf ein festes Nachrichtenformat. Die niedrigeren Implementierungskosten, die mit API einhergehen, fließen in genau diese Art von Individualisierung – in die Anbindung der Integration an den Rest des eigenen Systems, Lager, Onlineshops, andere Marktplatz-Kataloge – statt in das Zuordnen und Übersetzen von Feldern, wie es ein EDI-Setup erfordert. Ist ein Katalog erst einmal so synchronisiert, reiht er sich neben mehr als 2.000 weitere Plug-and-Play-Integrationen für Marktplätze, ERPs und Versaddienstleistern ein, sodass ein späteres neues Amazon-Programm nicht wieder ein Integrationsprojekt bei null bedeutet.

Wie es weitergeht

Wenn Sie gerade prüfen, wie Ihr Amazon-Vendor-Konto angebunden ist – ob noch auf EDI, bereits auf API oder eine Mischung aus beidem –, lohnt sich ein Blick darauf, wie ein vollständig API-basiertes Setup in der Praxis aussieht: Die Amazon-Vendor-Integration beschreibt, wie Bestell-, Versandavis- und Rechnungsabläufe für Vendor Retail von Anfang bis Ende funktionieren, und die Amazon-Direct-Fulfillment-Integration deckt dasselbe für Direct-Fulfillment-Bestellungen ab, von der Bestellung über den Versand bis zur Rechnung. Für die Einrichtung selbst führt der Amazon-Vendor-Integrationskonfigurationsleitfaden durch die konkreten Konfigurationsschritte und die Feature-Einrichtung, und „Amazon Vendor Central mit Base.com” zeigt, wie Listings, Bestand und Bestellungen nach der Anbindung über ein einziges Dashboard laufen.

FAQ

Sollte ich EDI jetzt sofort aufgeben?

Nicht unbedingt. Wenn EDI zuverlässig läuft und Ihr Team seine Prozesse darauf aufgebaut hat, besteht keine Eile, es herauszureißen. Der Punkt ist, zu verstehen, dass API-basierte Integration inzwischen mehr Bereiche abdeckt als früher und für bestimmte Anwendungsfälle andere Vorteile bietet – es lohnt sich also, sie bei der Erweiterung auf neue Programme oder bei der Fehlersuche wiederkehrender EDI-Probleme in Betracht zu ziehen.

Wird Amazon irgendwann API statt EDI für Vendoren vorschreiben – oder umgekehrt?

Es gibt weder eine angekündigte Frist noch einen öffentlichen Plan, der das vorsieht, und die meisten etablierten Vendor-Betriebe laufen weiterhin problemlos über EDI. API deckt zwar mehr vom Vendor-Lebenszyklus ab, aber niemand zwingt zu einer Migration.

Bedeutet der Wechsel zu API, meinen gesamten Katalog neu zuordnen zu müssen?

Eigentlich nicht. Eine korrekt aufgebaute API-Integration gleicht ASIN und externe Kennungen miteinander ab, statt eine durch die andere zu ersetzen – bestehende EAN-/GTIN-basierte Katalogdaten müssen also nicht verworfen werden.

Kann ich EDI und API parallel betreiben?

Ja, und viele Vendoren tun das tatsächlich – entweder während einer Übergangsphase oder dauerhaft parallel für unterschiedliche Anwendungsfälle, da sich EDI und API zwar überschneiden, aber nicht deckungsgleich sind.

Was ist für den SP-API-Zugang tatsächlich nötig?

Amazons eigener Weg umfasst wenige Schritte: als Entwickler in Vendor Central registrieren, die Anwendung registrieren, sie für das Konto autorisieren, Sandbox-Tests durchlaufen und dann in den Produktivbetrieb gehen. Der Austausch von APIs, die auch personenbezogene Kundendaten umfassen, beinhaltet ein detaillierteres Prüfverfahren zur Sicherheitslage des Vendors, das bei Nutzung eines Drittanbieters (wie Base) von diesem übernommen wird.