ATN

Ratgeber

EDIFACT, EANCOM und INVOIC: Die Formate hinter der Handelsrechnung

Lieferanten, die zum ersten Mal an eine große Handelsgruppe fakturieren, stolpern fast immer über dieselbe Irritation: Sie haben ihre Rechnungsstellung gerade auf ZUGFeRD oder XRechnung umgestellt — und der Handelspartner verlangt trotzdem etwas anderes, nämlich EDI. Das ist kein Widerspruch und auch kein veralteter Sonderweg. Beide Welten lösen unterschiedliche Probleme, und man braucht sie in der Regel gleichzeitig.

Drei Begriffe, die aufeinander aufbauen

  • EDIFACT ist der UN-Standard für den elektronischen Datenaustausch zwischen Unternehmen. Er definiert, wie Geschäftsnachrichten strukturiert werden — branchenübergreifend und bewusst sehr allgemein.
  • EANCOM ist das von GS1 gepflegte Subset von EDIFACT für den Handel. Es engt den allgemeinen Standard auf das ein, was Handel und Konsumgüterindustrie tatsächlich brauchen, und verzahnt ihn mit den GS1-Kennungen GTIN und GLN.
  • INVOIC ist innerhalb dieser Familie die Nachrichtenart für die Rechnung — so wie ORDERS die Bestellung und DESADV die Lieferavisierung ist.

Wenn ein Handelspartner also „INVOIC nach EANCOM“ verlangt, sagt er damit: eine Rechnungsnachricht, aufgebaut nach dem Handels-Subset von EDIFACT, mit Artikeln und Standorten identifiziert über GTIN und GLN.

Warum es nicht bei einer Version bleibt

EANCOM existiert in mehreren Ausgaben, und die einzelnen Nachrichtenarten in mehreren Verzeichnisversionen. Im deutschen Lebensmittelhandel ist die Ausgabe EANCOM 1997 mit dem EDIFACT-Verzeichnis D.96A bis heute verbreitet — die Markant-Zentralregulierung etwa arbeitet damit. Andere Handelspartner setzen auf neuere Ausgaben.

Damit nicht genug: Auf das Subset legt jeder Handelspartner noch eine eigene Anwendungsempfehlung. Dort steht, welche der im Standard optionalen Felder bei ihm Pflicht sind, wie Konditionen abgebildet werden, welche Qualifier zulässig sind. Zwei Lieferanten, die beide „EANCOM INVOIC“ senden, können deshalb völlig unterschiedliche Nachrichten erzeugen — und beide korrekt sein.

Für Sie als Lieferant ist das der eigentliche Aufwandstreiber. Nicht der Standard ist das Problem, sondern die Zahl der Auslegungen und deren Pflege über die Jahre.

Wie sich das zur gesetzlichen E-Rechnung verhält

Die deutsche E-Rechnungspflicht knüpft nicht an ein Dateiformat an, sondern an die europäische Norm EN 16931: Eine Rechnung muss strukturierte, maschinenlesbare Daten enthalten, die den dort definierten inhaltlichen Anforderungen genügen. ZUGFeRD und XRechnung sind die beiden in Deutschland gebräuchlichen Ausprägungen dieser Norm.

Entscheidend für Sie: EDI-Verfahren bleiben auch nach den Stichtagen 2027 und 2028 zulässig, sofern die übermittelten Daten inhaltlich die Anforderungen an eine E-Rechnung erfüllen. Sie müssen also nicht zwischen „EDI für den Handel“ und „E-Rechnung fürs Gesetz“ wählen und auch nicht zwei getrennte Prozesse betreiben. Es geht um dieselbe Rechnung, die beide Anforderungen zugleich trägt.

Wer das trennt, pflegt zwei Systeme, zwei Stammdatensätze und zwei Fehlerquellen — und hat am Ende trotzdem nur eine Forderung, die bezahlt werden soll.

Warum der Handel bei EDI bleibt

Die naheliegende Frage lautet, warum große Handelsunternehmen nicht einfach XRechnungen entgegennehmen. Der Grund ist selten Trägheit. EDI im Handel ist kein reiner Rechnungskanal, sondern ein durchgehender Prozess: Bestellung, Lieferavis, Wareneingang und Rechnung sind dieselbe Kette, über dieselben Kennungen verknüpft. Eine Rechnung, die aus dieser Kette herausfällt, kann nicht automatisch gegen Bestellung und Wareneingang abgeglichen werden — und genau dieser Abgleich ist der Zweck der Übung.

Dazu kommt die Zentralregulierung: Läuft die Abrechnung über einen Regulierer, muss die Rechnung nicht nur formal stimmen, sondern auch gegen dort hinterlegte Konditionen prüfbar sein. Auch das setzt strukturierte, standardisierte Daten voraus.

Was Sie praktisch brauchen

  • Einen Übertragungsweg zum Handelspartner beziehungsweise zu dessen Regulierer — klassisch über einen EDI-Dienstleister oder eine eigene Anbindung.
  • Ein Mapping, das Ihre Rechnungsdaten in die vom Handelspartner erwartete Nachrichtenstruktur überführt, inklusive seiner Pflichtfelder.
  • Gepflegte Kennungen: GTIN je fakturierter Verpackungsebene, GLN je beteiligter Rolle und Standort, dazu die Referenzen auf Bestellung und Lieferung.
  • Jemanden, der mitbekommt, wenn der Handelspartner seine Anwendungsempfehlung ändert — und das Mapping nachzieht, bevor Rechnungen zurückkommen.

Der letzte Punkt wird bei der ersten Anbindung fast immer unterschätzt. Der Aufbau ist ein Projekt mit Ende; die Pflege ist eine Daueraufgabe, die nur dann sichtbar wird, wenn sie ausbleibt.

Genau dafür gibt es ATN

ATN erzeugt aus Ihren Verkaufsdaten die Nachricht in der Form, die Ihr Handelspartner erwartet, und übermittelt sie per EDI — ohne dass Sie eine eigene EDI-Anbindung aufbauen, ein Subset pflegen oder ein Mapping-Projekt starten. 199 € im Monat, keine Einrichtungskosten.

Dieser Beitrag ersetzt keine steuerliche oder rechtliche Beratung.