Ratgeber
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.
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.
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.
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.
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.
Weiterlesen
GLN und GTIN auf der Rechnung: warum Nummern über Zahlung oder Klärfall entscheidenZUGFeRD oder XRechnung: welches Format wann giltEigene EDI-Anbindung oder Dienstleister: was der Anschluss wirklich kostetDieser Beitrag ersetzt keine steuerliche oder rechtliche Beratung.