EDI-Rechnung: Datenaustausch, Mapping und E-Rechnung sauber trennen

EDI-Rechnung: Kurzantwort und klare Abgrenzung

Electronic Data Interchange, kurz EDI, bezeichnet den strukturierten Austausch von Geschäftsdaten zwischen Systemen. Eine Rechnung kann dabei etwa als EDIFACT-Nachricht des Typs INVOIC übertragen werden. Syntax, Übertragungsprotokoll und betriebliche Partnervereinbarung sind jedoch unterschiedliche Ebenen. Auch ein proprietäres EDI-Format kann grundsätzlich relevant sein, wenn sich die umsatzsteuerlich erforderlichen Angaben richtig und vollständig extrahieren lassen; das muss im konkreten Verfahren belegt werden.

Die Auswahl zwischen E-Rechnungsformaten gehört zum semantischen Dokument. Peppol besitzt Netzwerk, Teilnehmeridentifikation und Routing, während E-Rechnung versenden den allgemeinen Zustellprozess erklärt. Diese Seite besitzt das bilaterale EDI-Onboarding, Feldmapping, EDIFACT-Beispiel und Rückmeldekonzept. Sie ist kein zweiter XRechnung-, Peppol- oder Pflicht-Owner.

Entscheidungsmatrix für EDI-Rechnung

Bestehendes EN-16931-Format

Beide Partner können ZUGFeRD, XRechnung oder ein anderes vereinbartes EN-16931-konformes Format verarbeiten. Für den Themenbereich EDI-Rechnung folgt daraus eine klare Arbeitsentscheidung: Das Standardformat bleibt fachliche Quelle; ein EDI-Transport oder Gateway wird nur für die Zustellung ergänzt. Die Entscheidung wird nicht nur im fertigen Dokument sichtbar, sondern bereits am zugrunde liegenden Vorgang festgehalten. Als belastbarer Nachweis dienen Profil, Version, Validierungsregeln, Testdatei und Empfangsbestätigung. So kann eine zweite Person später erkennen, welche Tatsachen geprüft wurden und weshalb genau dieses Ergebnis freigegeben wurde.

EDIFACT-INVOIC-Verfahren

Der Empfänger verlangt eine definierte EDIFACT-Nachricht mit eigenen Segmenten, Codes und Referenzen. Für den Themenbereich EDI-Rechnung folgt daraus eine klare Arbeitsentscheidung: Ein versioniertes Mapping übersetzt die fachlichen Rechnungsfelder in die vereinbarte INVOIC-Ausprägung und zurück. Die Entscheidung wird nicht nur im fertigen Dokument sichtbar, sondern bereits am zugrunde liegenden Vorgang festgehalten. Als belastbarer Nachweis dienen Message Implementation Guideline, Mappingtabelle, Code-listen und Partnerkennung. So kann eine zweite Person später erkennen, welche Tatsachen geprüft wurden und weshalb genau dieses Ergebnis freigegeben wurde.

Proprietäres Partnerformat

Ein Großkunde oder Branchenhub schreibt ein eigenes strukturiertes Schema vor. Für den Themenbereich EDI-Rechnung folgt daraus eine klare Arbeitsentscheidung: Vor Produktivstart wird nachgewiesen, dass Pflichtangaben vollständig extrahierbar sind und jede Abweichung kontrolliert behandelt wird. Die Entscheidung wird nicht nur im fertigen Dokument sichtbar, sondern bereits am zugrunde liegenden Vorgang festgehalten. Als belastbarer Nachweis dienen Schema, Beispieldateien, Pflichtfeldmatrix, Extraktionstest und Freigabe. So kann eine zweite Person später erkennen, welche Tatsachen geprüft wurden und weshalb genau dieses Ergebnis freigegeben wurde.

EDI nur als Übertragungsweg

Die Rechnung entsteht bereits in einem anderen strukturierten Format und EDI transportiert lediglich die Datei. Für den Themenbereich EDI-Rechnung folgt daraus eine klare Arbeitsentscheidung: Dokumentformat, Transport und Empfangsprotokoll werden getrennt dokumentiert; es findet keine unnötige fachliche Transformation statt. Die Entscheidung wird nicht nur im fertigen Dokument sichtbar, sondern bereits am zugrunde liegenden Vorgang festgehalten. Als belastbarer Nachweis dienen Originalrechnung, Hash beziehungsweise Referenz, Transportprotokoll und Statusmeldung. So kann eine zweite Person später erkennen, welche Tatsachen geprüft wurden und weshalb genau dieses Ergebnis freigegeben wurde.

Altes EDI-Verfahren ohne E-Rechnungsnachweis

Ein historischer Austausch funktioniert technisch, erfüllt die aktuellen strukturellen Anforderungen aber nicht nachweisbar. Für den Themenbereich EDI-Rechnung folgt daraus eine klare Arbeitsentscheidung: Das Verfahren wird nicht als E-Rechnung etikettiert; Übergangsregel und rechtzeitige Umstellung werden fallbezogen geprüft. Die Entscheidung wird nicht nur im fertigen Dokument sichtbar, sondern bereits am zugrunde liegenden Vorgang festgehalten. Als belastbarer Nachweis dienen Gap-Liste, rechtlicher Prüfvermerk, Zielverfahren, Testplan und Umstellungstermin. So kann eine zweite Person später erkennen, welche Tatsachen geprüft wurden und weshalb genau dieses Ergebnis freigegeben wurde.

EDI-Rechnung Schritt für Schritt umsetzen

1. Partneranforderung aufnehmenErfasse Rechnungstypen, Länder, Empfängerkennungen, Volumen, Pflichtreferenzen und erwartete Rückmeldungen.
2. Datenmodell festlegenOrdne Verkäufer, Käufer, Positionen, Mengen, Preise, Steuern, Leistungsdaten, Zahlungsbedingungen und Referenzen einem stabilen Quellmodell zu.
3. Mapping versionierenÜbersetze Felder, Segmente, Codes, Dezimalstellen und Einheiten in die konkrete Zielausprägung.
4. Testdaten aufbauenErzeuge Standardrechnung, Rabatt, Gutschrift, abweichende Lieferadresse, Rundungsfall und absichtlichen Pflichtfeldfehler.
5. Fachlich und technisch validierenPrüfe Summen, Steuergruppen, Referenzen und Extrahierbarkeit getrennt von Syntax und Schema.
6. Transport und Rückmeldung testenSende über den vereinbarten Kanal und ordne technische sowie fachliche Statusmeldungen eindeutig zu.
7. Produktivbetrieb überwachenBeobachte Ablehnungsgründe, Mappingfehler, Dubletten, Versionswechsel und ausstehende Bestätigungen.
8. Archiv und Korrektur sichernHalte Original, Transformation, Protokoll, sichtbare Darstellung und Folgebeleg zusammen.

Partneranforderung aufnehmen

Erfasse Rechnungstypen, Länder, Empfängerkennungen, Volumen, Pflichtreferenzen und erwartete Rückmeldungen. Der Schritt ist abgeschlossen, sobald ein gemeinsamer fachlicher Scope statt nur eines Dateinamens vereinbart ist. Das Ergebnis wird mit Datum und verantwortlicher Person am Vorgang dokumentiert. Für EDI-Rechnung ist diese kleine Kontrolle wichtiger als eine bloße Statusmarkierung, weil sie Eingabe, Entscheidung und Beleg miteinander verbindet. Widersprüchliche Vorgaben werden mit Einkauf, Buchhaltung und IT des Partners geklärt. In diesem Fall wird nicht improvisiert, sondern die Abweichung mit einer konkreten Rückfrage und einem nächsten Prüftermin weitergegeben.

Datenmodell festlegen

Ordne Verkäufer, Käufer, Positionen, Mengen, Preise, Steuern, Leistungsdaten, Zahlungsbedingungen und Referenzen einem stabilen Quellmodell zu. Der Schritt ist abgeschlossen, sobald jede erforderliche Information eine fachliche Herkunft besitzt. Das Ergebnis wird mit Datum und verantwortlicher Person am Vorgang dokumentiert. Für EDI-Rechnung ist diese kleine Kontrolle wichtiger als eine bloße Statusmarkierung, weil sie Eingabe, Entscheidung und Beleg miteinander verbindet. Ein fehlendes Quellfeld wird nicht durch einen leeren EDI-Platzhalter kaschiert. In diesem Fall wird nicht improvisiert, sondern die Abweichung mit einer konkreten Rückfrage und einem nächsten Prüftermin weitergegeben.

Mapping versionieren

Übersetze Felder, Segmente, Codes, Dezimalstellen und Einheiten in die konkrete Zielausprägung. Der Schritt ist abgeschlossen, sobald jede Transformation bidirektional erklärt und einem Versionsstand zugeordnet ist. Das Ergebnis wird mit Datum und verantwortlicher Person am Vorgang dokumentiert. Für EDI-Rechnung ist diese kleine Kontrolle wichtiger als eine bloße Statusmarkierung, weil sie Eingabe, Entscheidung und Beleg miteinander verbindet. Neue Partnerguides werden als neue Mappingversion getestet statt still produktiv ersetzt. In diesem Fall wird nicht improvisiert, sondern die Abweichung mit einer konkreten Rückfrage und einem nächsten Prüftermin weitergegeben.

Testdaten aufbauen

Erzeuge Standardrechnung, Rabatt, Gutschrift, abweichende Lieferadresse, Rundungsfall und absichtlichen Pflichtfeldfehler. Der Schritt ist abgeschlossen, sobald Normal- und Ausnahmefälle reproduzierbar geprüft werden können. Das Ergebnis wird mit Datum und verantwortlicher Person am Vorgang dokumentiert. Für EDI-Rechnung ist diese kleine Kontrolle wichtiger als eine bloße Statusmarkierung, weil sie Eingabe, Entscheidung und Beleg miteinander verbindet. Echte personenbezogene oder vertrauliche Daten werden nicht ungeprüft in Tests kopiert. In diesem Fall wird nicht improvisiert, sondern die Abweichung mit einer konkreten Rückfrage und einem nächsten Prüftermin weitergegeben.

Fachlich und technisch validieren

Prüfe Summen, Steuergruppen, Referenzen und Extrahierbarkeit getrennt von Syntax und Schema. Der Schritt ist abgeschlossen, sobald Datei und sichtbarer wirtschaftlicher Inhalt übereinstimmen. Das Ergebnis wird mit Datum und verantwortlicher Person am Vorgang dokumentiert. Für EDI-Rechnung ist diese kleine Kontrolle wichtiger als eine bloße Statusmarkierung, weil sie Eingabe, Entscheidung und Beleg miteinander verbindet. Eine syntaktisch gültige Nachricht mit falschem Steuerfall stoppt die Freigabe. In diesem Fall wird nicht improvisiert, sondern die Abweichung mit einer konkreten Rückfrage und einem nächsten Prüftermin weitergegeben.

Transport und Rückmeldung testen

Sende über den vereinbarten Kanal und ordne technische sowie fachliche Statusmeldungen eindeutig zu. Der Schritt ist abgeschlossen, sobald Versand, Empfang, Annahme oder Ablehnung unterscheidbar sind. Das Ergebnis wird mit Datum und verantwortlicher Person am Vorgang dokumentiert. Für EDI-Rechnung ist diese kleine Kontrolle wichtiger als eine bloße Statusmarkierung, weil sie Eingabe, Entscheidung und Beleg miteinander verbindet. Timeout oder technische Quittung wird nicht als fachliche Rechnungsannahme gewertet. In diesem Fall wird nicht improvisiert, sondern die Abweichung mit einer konkreten Rückfrage und einem nächsten Prüftermin weitergegeben.

Produktivbetrieb überwachen

Beobachte Ablehnungsgründe, Mappingfehler, Dubletten, Versionswechsel und ausstehende Bestätigungen. Der Schritt ist abgeschlossen, sobald jede Nachricht einen nachvollziehbaren Endstatus oder Klärfall erhält. Das Ergebnis wird mit Datum und verantwortlicher Person am Vorgang dokumentiert. Für EDI-Rechnung ist diese kleine Kontrolle wichtiger als eine bloße Statusmarkierung, weil sie Eingabe, Entscheidung und Beleg miteinander verbindet. Wiederholtes Senden verwendet stabile Referenzen und erzeugt keine unkontrollierte Doppelrechnung. In diesem Fall wird nicht improvisiert, sondern die Abweichung mit einer konkreten Rückfrage und einem nächsten Prüftermin weitergegeben.

Archiv und Korrektur sichern

Halte Original, Transformation, Protokoll, sichtbare Darstellung und Folgebeleg zusammen. Der Schritt ist abgeschlossen, sobald der gesamte Rechnungsweg später rekonstruiert werden kann. Das Ergebnis wird mit Datum und verantwortlicher Person am Vorgang dokumentiert. Für EDI-Rechnung ist diese kleine Kontrolle wichtiger als eine bloße Statusmarkierung, weil sie Eingabe, Entscheidung und Beleg miteinander verbindet. Eine Korrektur überschreibt die ursprüngliche Nachricht nicht, sondern verweist auf sie. In diesem Fall wird nicht improvisiert, sondern die Abweichung mit einer konkreten Rückfrage und einem nächsten Prüftermin weitergegeben.

Praxisbeispiele für EDI-Rechnung

Handelskette verlangt EDIFACT

Ein Lieferant soll jede Rechnung als INVOIC mit Bestellnummer, Lieferstellencode und branchenspezifischen Qualifiern senden. Die verantwortliche Person entscheidet deshalb: Er erstellt eine Partner-Mappingtabelle, testet mehrere Bestell- und Rabattfälle und wertet fachliche Ablehnungen getrennt von Transportbestätigungen aus. Im Ergebnis bleibt nachvollziehbar, ob ein Fehler aus Stammdaten, Rechnung, Mapping oder Kanal stammt. Das Beispiel zeigt, dass EDI-Rechnung nicht durch eine einzelne Checkbox erledigt ist. Erst das Zusammenspiel aus Ausgangsdaten, dokumentierter Prüfung und kontrolliertem Ergebnis macht den Vorgang für Empfänger, Team und spätere Prüfungen nachvollziehbar.

XRechnung über externes Gateway

Die Ausgangsrechnung liegt bereits als validierte XRechnung vor, der Empfänger nutzt aber einen EDI-Dienstleister als Eingang. Die verantwortliche Person entscheidet deshalb: Das Gateway transportiert die Originaldatei ohne unnötige Neuberechnung und liefert eine referenzierbare Empfangsmeldung. Im Ergebnis werden Dokumentkonformität und Übertragungsnachweis nicht miteinander verwechselt. Das Beispiel zeigt, dass EDI-Rechnung nicht durch eine einzelne Checkbox erledigt ist. Erst das Zusammenspiel aus Ausgangsdaten, dokumentierter Prüfung und kontrolliertem Ergebnis macht den Vorgang für Empfänger, Team und spätere Prüfungen nachvollziehbar.

Historische CSV-Schnittstelle

Zwei Partner tauschen seit Jahren strukturierte CSV-Rechnungsdaten aus, ohne dokumentierte Pflichtfeld- oder Extraktionsprüfung. Die verantwortliche Person entscheidet deshalb: Sie behandeln den Bestand nicht automatisch als E-Rechnung, erstellen eine Gap-Analyse und planen ein nachweisbares Zielprofil. Im Ergebnis wird ein funktionierender Import nicht mit aktueller rechtlicher Eignung gleichgesetzt. Das Beispiel zeigt, dass EDI-Rechnung nicht durch eine einzelne Checkbox erledigt ist. Erst das Zusammenspiel aus Ausgangsdaten, dokumentierter Prüfung und kontrolliertem Ergebnis macht den Vorgang für Empfänger, Team und spätere Prüfungen nachvollziehbar.

Typische Fehler bei EDI-Rechnung

EDI automatisch als E-Rechnung bezeichnen

Der Begriff beschreibt zunächst den Datenaustausch und beweist nicht die gesetzlichen Formatmerkmale. Die fachliche Korrektur lautet: Semantik, Extrahierbarkeit und aktueller Rechtsstand werden separat geprüft. Als dauerhafte Kontrolle wird eine Pflichtfeld- und Formatmatrix je Partner geführt. Dadurch wird der Fehler nicht nur in einem Einzelfall repariert. Der Ablauf rund um EDI-Rechnung erhält eine Regel, die denselben Fehler bei der nächsten Rechnung, Datei oder Bestandsbewegung früh sichtbar macht.

Nur die Happy-Path-Datei testen

Rabatte, Gutschriften, Rundungen und Ablehnungen scheitern erst im Produktivbetrieb. Die fachliche Korrektur lautet: Testkatalog und erwartete Statusreaktion decken Normal- und Fehlerfälle ab. Als dauerhafte Kontrolle wird jede Mappingversion dieselben Regressionstests durchläuft. Dadurch wird der Fehler nicht nur in einem Einzelfall repariert. Der Ablauf rund um EDI-Rechnung erhält eine Regel, die denselben Fehler bei der nächsten Rechnung, Datei oder Bestandsbewegung früh sichtbar macht.

Technische Quittung als Annahme lesen

Ein Server kann die Nachricht empfangen haben, obwohl der Empfänger sie fachlich ablehnt. Die fachliche Korrektur lautet: Transportstatus und fachlicher Rechnungsstatus erhalten getrennte Codes. Als dauerhafte Kontrolle wird jede Statusart einen Owner und eine Reaktionsfrist besitzt. Dadurch wird der Fehler nicht nur in einem Einzelfall repariert. Der Ablauf rund um EDI-Rechnung erhält eine Regel, die denselben Fehler bei der nächsten Rechnung, Datei oder Bestandsbewegung früh sichtbar macht.

Original nach Transformation verlieren

Spätere Prüfung kann nicht feststellen, welche Datei tatsächlich versendet wurde. Die fachliche Korrektur lautet: Quellartefakt, Zielnachricht, Mappingversion und Protokoll bleiben referenziert. Als dauerhafte Kontrolle wird Archivstichproben die vollständige Kette öffnen. Dadurch wird der Fehler nicht nur in einem Einzelfall repariert. Der Ablauf rund um EDI-Rechnung erhält eine Regel, die denselben Fehler bei der nächsten Rechnung, Datei oder Bestandsbewegung früh sichtbar macht.

Freigabe-Checkliste: EDI-Rechnung

• Geschäftspartner, Rechnungstyp und fachlicher Anwendungsfall eindeutig benannt
• Pflichtdaten und Partnerfelder unabhängig von Syntax und Transport beschrieben
• Semantisches Quellformat und Zielsyntax mit Versionsstand festgehalten
• Codewerte, Einheiten, Referenzen und Rundungsregeln vollständig gemappt
• Testfälle für Standard, Gutschrift, Ablehnung und Korrektur abgenommen
• Transport, Authentisierung und technische Empfangsbestätigung vereinbart
• Originaldatei, sichtbare Darstellung, Protokolle und Korrekturpfad auffindbar
• EDI-Verfahren nicht ungeprüft mit einer steuerlich gültigen E-Rechnung gleichgesetzt

Die Checkliste wird nicht erst am Ende eines Monats abgearbeitet. Sie gehört an den einzelnen Vorgang, solange Rückfragen noch ohne aufwendige Rekonstruktion beantwortet werden können. Pflichtfelder verhindern einfache Lücken; fachliche Ausnahmen brauchen zusätzlich eine kurze Begründung. So bleibt EDI-Rechnung auch dann kontrollierbar, wenn mehrere Personen Eingang, Prüfung, Freigabe und Versand übernehmen.

Ein Vier-Augen-Prinzip ist besonders bei neuen Geschäftsfällen, geänderten Stammdaten und rechtlich sensiblen Entscheidungen sinnvoll. Wiederkehrende Standardfälle können nach dokumentierter Freigabe stärker automatisiert werden. Die Automatisierung übernimmt jedoch nur die freigegebene Regel. Sie darf eine fehlende Information nicht still durch einen plausibel wirkenden Standardwert ersetzen.

Dokumentation, Verantwortlichkeit und regelmäßige Pflege

Für EDI-Rechnung werden Eingangsdaten, Entscheidung, Ergebnis und Nachweis als zusammenhängender Vorgang geführt. Eine reine Dateiablage zeigt zwar das Endprodukt, aber nicht zwingend den Entscheidungsweg. Deshalb erhält jede Ausnahme einen Owner, einen Status und einen nächsten Schritt. Änderungen werden ergänzt oder versioniert; sie werden nicht durch stilles Überschreiben unsichtbar gemacht.

Die zugrunde liegende Arbeitsanweisung nennt außerdem ein Prüfdatum. Rechtliche Schwellen, technische Standards, externe Portale und interne Produktfunktionen können sich ändern. Bei der turnusmäßigen Kontrolle werden Primärquelle, tatsächlicher Prozess und veröffentlichte Aussage miteinander verglichen. Ändert sich nur eine Zahl, wird derselbe Intent-Owner aktualisiert; eine neue Jahres-URL ist dafür nicht erforderlich.

Formate und Profile erklärt E-Rechnungsformate. Für die Übertragung folgen E-Rechnung versenden und Peppol erklärt; die Dateiprüfung bleibt bei E-Rechnung validieren.

EDI-Rechnung und die Produktgrenzen von Invoify

Invoify kann deutsche Ausgangsrechnungen als ZUGFeRD oder XRechnung erzeugen und technisch validieren. Es enthält derzeit keinen eigenen EDI-/EDIFACT-Konverter, keine Partner-Mappingverwaltung, keinen AS2- oder VAN-Zugang und keine Verarbeitung von EDI-Bestätigungsnachrichten. Ein externer Integrationsdienst kann eine von Invoify exportierte, freigegebene Datei übernehmen; Mapping, Transport, Partner-Onboarding und EDI-Status bleiben dann außerhalb von Invoify.

Eine Funktion wird in diesem Leitfaden nur dann als Invoify-Funktion bezeichnet, wenn sie in der aktuellen Produktdokumentation belegt ist. Steuerliche Würdigung, rechtliche Einzelfallprüfung und externe Behördenverfahren bleiben bei den verantwortlichen Personen beziehungsweise deren Beratung. Diese Trennung verhindert, dass ein formal erzeugter Beleg mit einer fachlich freigegebenen Entscheidung verwechselt wird.

Offizielle Quellen und Prüfstand

Das BMF-FAQ zur E-Rechnung erläutert mit Stand März 2026, dass auch ein vereinbartes EDI-Format die Anforderungen erfüllen kann, wenn sich die nach dem Umsatzsteuergesetz erforderlichen Angaben richtig und vollständig extrahieren lassen. Es weist zugleich auf die Übergangsbehandlung nicht ausreichend konformer EDI-Verfahren bis Ende 2027 hin. Die allgemeinen Rechnungsanforderungen stehen in § 14 UStG; die EU-Empfehlung 94/820/EG enthält ein europäisches EDI-Vertragsmodell. Produktangaben wurden gegen die implementierte ZUGFeRD-/XRechnung-Erzeugung und Validierung geprüft. Letzter Quellen- und Produktcheck: 5. August 2026; nächste turnusmäßige Prüfung: Januar 2027.