XRechnung oder ZUGFeRD: Welches Format wann sinnvoll ist

Die Frage nach dem richtigen Format wird meist zu früh gestellt. Sie ist eine Folgefrage: Erst steht fest, an wen ein Mandant fakturiert, dann ergibt sich das Format fast von selbst.

Was haben XRechnung und ZUGFeRD gemeinsam?

Beide setzen dieselbe europäische Norm um, die EN 16931, und sind damit umsatzsteuerlich gleichwertig zulässige E-Rechnungen. Die Norm beschreibt, welche Felder eine elektronische Rechnung enthalten muss und wie sie zu benennen sind: Rechnungsnummer, Leistungsdatum, Steuersätze, Nettobeträge, Steuerbeträge, Angaben zu Verkäufer und Käufer. Der Unterschied liegt allein in der Verpackung.

Was ist eine XRechnung?

Eine reine XML-Datei, die die Rechnungsdaten strukturiert enthält und sonst nichts. Öffnet man sie im Texteditor, sieht man Auszeichnungen, keine Rechnung. Wer sie ansehen will, braucht ein Anzeigeprogramm.

Das ist Absicht, kein Mangel: Wer die Datei maschinell verarbeitet, braucht kein Layout. Die XRechnung ist eine deutsche Spezifikation, gepflegt von der Koordinierungsstelle für IT-Standards, und der Standard im öffentlichen Auftragswesen. Wer an Bund, Länder oder Kommunen fakturiert, liefert in aller Regel eine XRechnung.

Was ist ZUGFeRD?

Eine PDF/A-3-Datei, in die dieselben Rechnungsdaten zusätzlich als XML eingebettet sind. Das Ergebnis ist eine Datei mit zwei Gesichtern: Der Mensch öffnet sie und sieht eine gewohnte Rechnung mit Logo und Layout, die Software liest das eingebettete XML und bekommt dieselben Daten strukturiert.

Für den Verkehr zwischen Unternehmen ist das der ruhigere Weg, weil er keine Annahme über die Gegenseite trifft. Ob der Empfänger automatisch verarbeitet oder die Rechnung ausdruckt, spielt keine Rolle mehr.

Erst ab ZUGFeRD 2.x im Profil EN 16931 oder höher liegt eine E-Rechnung im Sinne des Gesetzes vor. Die schlankeren Profile MINIMUM und BASIC WL enthalten zu wenige Felder und erfüllen die Norm nicht. Sie sind als Zusatzinformation zu einem PDF gedacht, nicht als Rechnung.

Was gilt bei Abweichung zwischen PDF und XML?

Bei einem Hybridformat ist der strukturierte Datensatz maßgeblich. Weicht die PDF-Ansicht vom eingebetteten XML ab, gilt das XML, und die Rechnung sagt damit etwas anderes aus als das, was der Empfänger liest.

Das ist kein akademischer Fall. Er tritt regelmäßig auf, wenn Rechnungsprogramme das PDF nachträglich anpassen, ohne das XML zu aktualisieren, oder wenn Skonto und Rabatte im Layout stehen, im Datensatz aber nicht. Für die Kanzlei folgt daraus eine schlichte Prüfregel: bei Zweifeln in den Datensatz schauen, nicht auf das Bild.

Welches Format für welchen Fall?

Fakturiert ein Mandant an beide Gruppen, braucht er keine Entscheidung zwischen den Formaten. Er braucht eine Regel, welcher Empfänger welches bekommt. Diese Regel gehört an den Kundenstamm und nicht in den Kopf der fakturierenden Person, weil sie sonst bei Vertretung und Personalwechsel verloren geht.

Wie prüft man, ob eine Datei wirklich normkonform ist?

Die Auskunft, man liefere ZUGFeRD, ist eine Herstellerangabe und keine Prüfung. Belastbar wird sie an einer erzeugten Datei in drei Schritten, die zusammen wenige Minuten dauern.

Schritt eins: nachsehen, ob überhaupt etwas eingebettet ist. Jedes gängige PDF-Anzeigeprogramm zeigt eingebettete Dateien in einer eigenen Ansicht. Fehlt dort ein XML, ist die Datei ein gewöhnliches PDF mit einem Etikett. Das tritt häufiger auf als vermutet, insbesondere wenn ein Rechnungsprogramm die Funktion als nie freigeschaltetes Zusatzmodul führt.

Schritt zwei: das Profil feststellen. Das eingebettete XML nennt das verwendete Profil. Steht dort MINIMUM oder BASIC WL, liegt keine E-Rechnung im Sinne der Norm vor.

Schritt drei: den Datensatz gegen die Ansicht halten. Rechnungsnummer, Rechnungsdatum, Nettobetrag, Steuerbetrag, Gesamtbetrag und die Steuersätze der Positionen.

Der Dreischritt gehört einmal je eingesetztem Rechnungsprogramm durchgeführt, nicht je Rechnung. Wiederholt wird er, wenn der Hersteller eine neue Version ausliefert, denn genau dann verschieben sich Felder, ohne dass es auffällt.

Auf der Eingangsseite kommen drei Fragen hinzu, die die eigene Kanzlei betreffen: Sind die Pflichtangaben inhaltlich vollständig, denn ein valides Format ersetzt diese Prüfung nicht? Hat die eigene Verarbeitung den Datensatz gelesen oder das Bild? Und ist die Datei in ursprünglicher Form gesichert, siehe Aufbewahrungsfristen? Die letzten beiden führen in der Praxis zu mehr Korrekturbedarf als alle Fragen an den Aussteller zusammen, weil sie im eigenen Haus liegen und niemand von außen darauf hinweist.

Welche Fehlerbilder treten auf?

Das Profil unterhalb der Norm. Die häufigste Konstellation. Das Programm erzeugt zuverlässig eine Datei, nur eben im Profil MINIMUM. Für den Aussteller sieht alles richtig aus, umsatzsteuerlich liegt keine E-Rechnung vor.

Der nachträglich geänderte Beleg. Eine Rechnung wird korrigiert, das Layout neu erzeugt, das eingebettete XML aber nicht aktualisiert. Danach zeigen Bild und Datensatz zwei verschiedene Rechnungen, und maßgeblich ist der alte Stand im Datensatz.

Rabatt oder Skonto nur im Layout. Ein Nachlass steht als Fußzeile im PDF und fehlt im strukturierten Teil. Der Empfänger sieht einen Abzug, die Verarbeitung bucht den vollen Betrag. Tückisch ist der Fall, weil er beim Zahlungsabgleich als Differenz auftaucht und dort als Zahlungsfehler des Kunden gedeutet wird.

Die Steuersätze auf Positionsebene fehlen. Der Gesamtbetrag stimmt, die Positionen tragen keinen eigenen Steuersatz. Bei einheitlichem Steuersatz fällt das nicht auf, bei einer gemischten Rechnung geht genau der Vorteil verloren, wegen dessen sich der Aufwand lohnt.

Die Konvertierung im Archiv. Die Datei wird beim Import in ein Dokumentenmanagement in ein anderes PDF-Format überführt, und das eingebettete XML verschwindet. Aus der E-Rechnung wird rückwirkend ein Bild. Aufzubewahren ist die vollständige PDF/A-3-Datei mit eingebettetem XML, nicht ein daraus erzeugtes Bild.

Die Datei mit zwei Anhängen. Manche Programme betten neben dem normkonformen XML weitere Dateien ein, etwa einen Lieferschein. Das ist zulässig und wird zum Problem, wenn die empfangende Verarbeitung die erste eingebettete Datei nimmt statt der richtigen.

Wie läuft eine Formatumstellung ab?

In acht Phasen, von denen die Softwareeinstellung die kleinste ist.

Phase 4 wird am häufigsten übersprungen. Eine Demodatei des Herstellers ist auf Korrektheit optimiert und sagt nichts darüber, was bei gemischten Steuersätzen, einem Rabatt auf Summenebene und einem Freitext im Positionsfeld passiert. Genau dort brechen die Formate.

Der größte Aufwand steckt in den Stammdaten, nicht in der Software. Die Norm verlangt Felder, die in gewachsenen Systemen unvollständig gepflegt sind: Steuernummer oder Umsatzsteuer-Identifikationsnummer, vollständige Kundenanschriften, eindeutige Zahlungsbedingungen, korrekte Bankverbindung. Solange diese Felder in einem PDF standen, war ein fehlendes Feld nur eine Lücke im Layout. Im strukturierten Datensatz ist es ein fehlendes Pflichtfeld, und die Datei wird beim Empfänger abgewiesen. Die erste Frage im Mandantengespräch lautet deshalb, wie vollständig die Kundenstammdaten gepflegt sind, nicht welches Programm eingesetzt wird.

Was regelt die Formatfrage nicht?

Drei Abgrenzungen ersparen Diskussionen, die regelmäßig unter dieser Überschrift geführt werden, obwohl sie andere Themen betreffen.

Format und Übertragungsweg sind zwei Dinge. Eine XRechnung per E-Mail und eine XRechnung über ein Netzwerk sind dasselbe Format. Die Wahl des Wegs folgt aus den Anforderungen des Empfängers.

Format und Verarbeitung sind zwei Dinge. Ein normkonformes Format garantiert nicht, dass die empfangende Seite es nutzt. Wird ein Hybridformat als Bild durch die Texterkennung geschickt, ist das Ergebnis dasselbe wie bei einem gewöhnlichen PDF, nur mit mehr Aufwand davor. Für die Eingangsseite heißt das, dass die Belegstrecke drei Wege parallel beherrschen muss, denn PDF und Papier verschwinden nicht über Nacht. Was das für die automatisierte Verarbeitung bedeutet, steht in E-Rechnung und KI-Buchhaltung.

Format und Inhalt sind zwei Dinge. Die Norm legt fest, welche Felder vorhanden sein müssen, nicht dass die Werte darin richtig sind. Ein falsch ausgewiesener Steuerbetrag bleibt falsch, auch strukturiert übermittelt, und ein leerer Leistungszeitraum bleibt eine Lücke, auch wenn das Feld formal vorhanden ist.