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 beide gemeinsam haben

XRechnung und ZUGFeRD sind keine Konkurrenten im eigentlichen Sinn. Beide setzen dieselbe europäische Norm um, die EN 16931. Diese 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.

Solange ein Format diese Norm erfüllt, ist es umsatzsteuerlich eine E-Rechnung. Beide tun das. Der Unterschied liegt allein in der Verpackung.

XRechnung: nur die Daten

Die XRechnung ist eine reine XML-Datei. Sie enthält die Rechnungsdaten strukturiert und sonst nichts. Öffnet man sie im Texteditor, sieht man Auszeichnungen, keine Rechnung.

Das ist kein Mangel, sondern die Absicht. Wer die Datei maschinell verarbeitet, braucht kein Layout. Wer sie ansehen will, braucht ein Anzeigeprogramm oder eine Software, die sie darstellt.

Die XRechnung ist eine deutsche Spezifikation, genauer eine nationale Ausprägung der Norm, gepflegt von der Koordinierungsstelle für IT-Standards. Sie ist der Standard im öffentlichen Auftragswesen. Wer an Bund, Länder oder Kommunen fakturiert, liefert in aller Regel eine XRechnung.

ZUGFeRD: Daten und Bild in einer Datei

ZUGFeRD löst das Lesbarkeitsproblem anders. Eine ZUGFeRD-Rechnung ist 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, Layout und Fußzeile. 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 eine automatische Verarbeitung betreibt oder die Rechnung ausdruckt und abheftet, spielt keine Rolle mehr.

Entscheidend ist die Version: 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.

Der Punkt, der in der Praxis Streit erzeugt

Bei einem Hybridformat gilt der strukturierte Datensatz. Weicht die PDF-Ansicht vom eingebetteten XML ab, ist das XML maßgeblich.

Das klingt akademisch, ist es aber nicht. Es passiert regelmäßig, 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 nicht auf das Bild schauen, sondern in den Datensatz. Und für den Mandanten, der ZUGFeRD selbst erzeugt, die Empfehlung, das erzeugte XML einmal gegen die Norm prüfen zu lassen, bevor die erste Rechnung rausgeht.

Welches Format für welchen Fall

Was für den Empfang daraus folgt

Auf der Eingangsseite ist die Formatfrage weniger relevant, weil sich der Empfänger nicht aussuchen kann, was er bekommt. Wer die Empfangspflicht ernst nimmt, muss beide Formate verarbeiten können, dazu weiterhin PDF und Papier, denn die verschwinden nicht über Nacht.

Für die Kanzlei heißt das konkret: Die Belegstrecke muss drei Wege parallel beherrschen. Aus einer XRechnung werden die Felder direkt gelesen. Aus einem ZUGFeRD-PDF wird das eingebettete XML gezogen und nicht etwa das Bild durch die Texterkennung geschickt. Und ein klassisches PDF ohne Datensatz läuft weiter über die Texterkennung.

Wer den zweiten Fall falsch behandelt, verschenkt den eigentlichen Gewinn: Die Daten liegen exakt vor, und trotzdem wird geraten.

Wie eine Formatprüfung praktisch abläuft

Die Auskunft „wir liefern ZUGFeRD" ist keine Prüfung, sondern eine Herstellerangabe. Belastbar wird sie erst an einer erzeugten Datei, und dafür genügen drei Schritte.

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. Dieser Fall tritt häufiger auf als vermutet, insbesondere wenn ein Rechnungsprogramm die Funktion als Zusatzmodul führt, das nie freigeschaltet wurde.

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. Diese Profile sind als ergänzende Information zu einem PDF gedacht und enthalten zu wenige Felder, um die Anforderungen zu erfüllen. Erst ab dem Profil EN 16931 ist die Norm abgedeckt.

Schritt drei: den Datensatz gegen die Ansicht halten. Rechnungsnummer, Rechnungsdatum, Nettobetrag, Steuerbetrag, Gesamtbetrag und die Steuersätze der Positionen. Stimmen diese Werte zwischen Bild und Datensatz überein, ist der praktisch wichtigste Teil geprüft. Weichen sie ab, gilt der Datensatz, und die Rechnung sagt etwas anderes aus als das, was der Empfänger liest.

Der Dreischritt dauert bei einer Datei wenige Minuten. Er gehört einmal je eingesetztem Rechnungsprogramm durchgeführt, nicht einmal je Rechnung. Wiederholt wird er erst, wenn der Hersteller eine neue Version ausliefert, denn genau dann verschieben sich in der Praxis Felder, ohne dass es jemandem auffällt.

Ein Fahrplan für die Formatumstellung eines Mandanten

Die Formatentscheidung ist eine Folgefrage, die Umstellung dagegen ein Ablauf mit einer festen Reihenfolge. Sie lässt sich für nahezu jedes Mandat gleich schneiden.

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

Sechs Fehlerbilder, die in der Praxis auftreten

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. Auffallen kann das erst beim Empfänger, und der prüft es meistens nicht.

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. Maßgeblich ist der Datensatz, und der trägt den alten Stand.

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. Der Fall ist deshalb tückisch, 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 einzelnen Positionen tragen aber keinen eigenen Steuersatz. Bei einer Rechnung mit 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 dabei. Aus der E-Rechnung wird rückwirkend ein 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. Der Fall lässt sich in einer Demo mit genau einer solchen Datei prüfen.

Checkliste für eine eingehende Datei

Auf der Eingangsseite lässt sich das Format nicht wählen, wohl aber prüfen. Sechs Fragen genügen, um eine strittige Rechnung einzuordnen.

1. Liegt ein strukturierter Datensatz vor, oder ist es ein reines Bild? Bei einem PDF entscheidet der Blick in die eingebetteten Dateien, bei einer XML-Datei erübrigt sich die Frage.
2. Welches Profil? Alles unterhalb von EN 16931 ist umsatzsteuerlich keine E-Rechnung, auch wenn es so aussieht.
3. Stimmen Bild und Datensatz überein? Bei Abweichung gilt der Datensatz, und darauf beruht die Buchung.
4. Sind die Pflichtangaben inhaltlich vollständig? Ein valides Format ersetzt die Prüfung der Pflichtangaben nicht.
5. Wurde der Datensatz gelesen oder das Bild? Wenn die eigene Verarbeitung die Werte aus dem Bild geschätzt hat, obwohl der Datensatz vorlag, ist das ein Befund über das eigene System, nicht über die Rechnung.
6. Ist die Datei in ursprünglicher Form gesichert? Der Punkt, der erst Jahre später relevant wird und sich dann nicht mehr reparieren lässt. Siehe Aufbewahrungsfristen.

Die Punkte 1 bis 3 betreffen den Aussteller, die Punkte 4 bis 6 die eigene Kanzlei. In der Praxis führen die Punkte 5 und 6 zu mehr Korrekturbedarf als die ersten drei zusammen, weil sie im eigenen Haus liegen und deshalb niemand von außen darauf hinweist.

Was die Formatfrage nicht regelt

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

Format und Übertragungsweg sind zwei Dinge. Ein Format beschreibt, wie die Daten aufgebaut sind. Der Übertragungsweg beschreibt, wie die Datei zum Empfänger kommt. 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, nicht aus dem Format.

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. 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 und wie sie heißen. Sie legt nicht fest, dass die Werte darin richtig sind. Ein falsch ausgewiesener Steuerbetrag bleibt falsch, auch wenn er strukturiert übermittelt wurde, und ein leerer Leistungszeitraum bleibt eine Lücke, auch wenn das Feld formal vorhanden ist.

Wer diese drei Ebenen trennt, kann in einem Auswahlgespräch gezielt fragen und bekommt Antworten, die sich überprüfen lassen. Wer sie vermischt, bekommt eine Funktionsliste.

Wenn beide Formate im selben Mandat vorkommen

Ein Mandant, der sowohl an öffentliche Auftraggeber als auch an Unternehmen fakturiert, braucht keine Entscheidung zwischen den Formaten, sondern 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.

Praktisch wird je Kunde ein Merkmal gepflegt, das den Zielweg festlegt. Bei einem Programm, das dieses Merkmal nicht kennt, ist der pragmatische Ausweg eine getrennte Kundengruppe. Beides ist einmaliger Aufwand und ersetzt eine wiederkehrende Einzelfallentscheidung, die im Alltag regelmäßig falsch ausfällt.

Die Kanzlei sollte in einem solchen Fall darauf achten, dass die Regel nachvollziehbar dokumentiert ist. Bei einer späteren Beanstandung ist die erste Frage, warum ein bestimmter Empfänger ein bestimmtes Format bekommen hat, und eine Antwort aus dem Kundenstamm trägt, eine aus der Erinnerung nicht.

Wo der Aufwand einer Umstellung tatsächlich liegt

In der Vorstellung der meisten Mandanten ist die Formatumstellung ein Softwarethema. Tatsächlich verteilt sich der Aufwand anders, und die Verteilung ist über die Mandate hinweg erstaunlich stabil.

Der kleinste Teil ist die Softwareeinstellung. Bei einem Programm, das das Zielformat beherrscht, ist es eine Auswahl in den Einstellungen. Bei einem Programm, das es nicht beherrscht, ist es ein Wechsel, und der ist ein eigenes Vorhaben mit eigenem Zeitbedarf.

Der größte Teil sind die Stammdaten. Die Norm verlangt Felder, die in vielen gewachsenen Systemen unvollständig gepflegt sind: die Steuernummer oder Umsatzsteuer-Identifikationsnummer des eigenen Unternehmens, vollständige Anschriften der Kunden, eindeutige Zahlungsbedingungen, korrekte Angaben zur Bankverbindung. Solange diese Felder in einem PDF standen, hat niemand ihre Vollständigkeit geprüft, weil ein fehlendes Feld nur eine Lücke im Layout war. Im strukturierten Datensatz ist es ein fehlendes Pflichtfeld, und die Datei wird beim Empfänger abgewiesen.

Der unterschätzte Teil sind die Sonderfälle in der Fakturierung. Anzahlungen, Teilrechnungen, Gutschriften, Rabatte auf Summenebene, Rechnungen mit Bezug auf mehrere Aufträge. In einem PDF lassen sich solche Fälle durch einen Freitext lösen. Im strukturierten Datensatz brauchen sie eine korrekte Abbildung, und ob das eingesetzte Programm sie beherrscht, zeigt sich erst am konkreten Fall. Deshalb ist die Musterrechnung aus dem echten Datenbestand so wichtig: Sie bringt genau diese Fälle ans Licht, bevor sie beim Kunden landen.

Der Teil, der niemandem auffällt, ist die Nummernvergabe. Wer bisher Rechnungsnummern über mehrere Wege vergeben hat, etwa manuell für Sonderfälle und automatisch für den Regelfall, bekommt in einer strukturierten Welt Doppelvergaben, die vorher folgenlos blieben. Der Schnitt zum Monatsersten begrenzt den Schaden, weil er die Umstellung an einer klar benennbaren Stelle in der Nummernfolge sichtbar macht.

Aus dieser Verteilung folgt eine praktische Empfehlung für das Mandantengespräch: Die Frage nach dem Programm ist die zweite. Die erste lautet, wie vollständig die Stammdaten der Kunden gepflegt sind. Ist die Antwort unbestimmt, ist das der Arbeitsschwerpunkt der nächsten Wochen, unabhängig davon, welches Format am Ende gewählt wird.

Für die Kanzlei ergibt sich daraus zugleich ein nützlicher Nebeneffekt. Ein Mandant, der seine Kundenstammdaten für die Formatumstellung bereinigt, liefert anschließend auch bessere Ausgangsrechnungsdaten für die eigene Buchführung. Der Aufwand fällt einmal an und wirkt an zwei Stellen.

Aufbewahrung

Aufzubewahren ist der strukturierte Datensatz in seiner ursprünglichen Form, unverändert und maschinell auswertbar. Bei ZUGFeRD ist das die vollständige PDF/A-3-Datei mit eingebettetem XML, nicht ein daraus erzeugtes Bild.

Ein häufiger Fehler in der Praxis: Die Rechnung wird ins Dokumentenmanagement übernommen, dabei aber in ein anderes PDF-Format konvertiert. Das eingebettete XML geht dabei verloren, und aus der E-Rechnung wird rückwirkend ein Bild. Wer ein Archivsystem einsetzt, sollte diesen Fall einmal gezielt testen.