Seit Januar 2025 gilt für Unternehmen und Selbstständige die Pflicht zur Ausstellung elektronischer Rechnungen. Der Einsatz der beiden Formate XRechnung und ZUGFeRD zieht vielfältige Anpassungen im Betriebsablauf nach sich.
Die elektronische Rechnungsstellung und der Rechnungsversand per E-Mail sind heute Standard, insbesondere zwischen Unternehmen und Selbstständigen. Der Ausdruck auf Papier verschwindet zunehmend und erfolgt immer häufiger nur noch auf Nachfrage. Diesen Trend hat die Gesetzgebung bereits vor Jahren aufgegriffen und Stück für Stück in Gesetze und Verordnungen gegossen. Das Ziel war dabei eine einheitliche Rechnungsstellung samt automatisierter Weiterverarbeitung.
Seit 2025 müssen Betriebe und Selbstständige elektronische Rechnungen entgegennehmen und revisionssicher archivieren. Bis auf Weiteres genügt es, schlicht ein E-Mail-Postfach zum Empfang vorzuhalten. Der Aussteller hat die Rechnungen jedoch so zu strukturieren, dass der Empfänger die darin enthaltenen Rechnungsdaten elektronisch auslesen und weiterverarbeiten kann.
Die elektronische Weiterverarbeitung ist bislang kein Muss, soll aber den Weg zur Einbindung in Buchungsprogramme ebnen. Auch eine automatisierte Prüfung von Unterlagen und die Nachverfolgung von Zahlungsströmen seitens der Behörden stehen auf der Agenda, perspektivisch sogar in Echtzeit. Italien nutzt ein solches System seit 2022 im Produktivbetrieb und verpflichtet alle Unternehmen, sämtliche Rechnungen über diese zentrale Plattform namens Sistema di Interscambio (SDI) auszutauschen [1]. Erst nach formaler Prüfung und Freigabe durch die Finanzaufsicht steht die Rechnung für den eigentlichen Rechnungsempfänger zur Verfügung.
Zulässige Austauschformate
Der elektronische Rechnungsaustausch in Deutschland erfolgt mittlerweile ausschließlich über die beiden Formate XML und PDF mit einer festgelegten Struktur. Das Ausstellen und Übermitteln als reine PDF-Datei allein genügt nicht mehr, neben dem PDF kommen weitere Daten hinzu. PDF-Rechnungen müssen dem Standard PDF/A-3 [2] entsprechen, was sie archivierbar und barrierefrei macht. Einfach ein Bild in ein PDF umzuwandeln oder es einzuscannen, erfüllt die neuen Anforderungen nicht.
Mit dieser rechtlichen Änderung entfallen andere, bislang durchaus übliche Formate zum Rechnungsaustausch, beispielsweise Rich Text Format (RTF), Postscript, DejaVu, Open/LibreOffice und Abiword. Gleichfalls außen vor bleiben nicht ausreichend dokumentierte, plattformeinschränkende und vielfach nur fehlerbehaftet verarbeitbare Formate wie Pages, Google Docs, Microsoft Excel oder Word. Entsprechende Ergänzungen, die anstreben, solche Dokumente zur Rechnungslegung rechtskonform zu erweitern, sind vielfach in Form von halbgaren Makros zweifelhafter Qualität im Umlauf.
Bleibt noch der Umweg, ein Dokument in eine PDF-Datei zu drucken. Allerdings führt das häufig nur zu PDFs in den Versionen 1.4 bis 1.8. Bei vielen Programmen und Druckertreibern (PPDs) fehlt bislang schlicht die Möglichkeit, damit das Format PDF/A-3 zu erzeugen. Für das Umwandeln eines Dokuments in ein ZUGFeRD-PDF (dazu später noch mehr) bedarf es zusätzlicher Schritte.
Gültigkeit der Änderungen
Prinzipiell gelten die Änderungen zum Austausch elektronischer Rechnungen für alle Unternehmen ab dem Januar 2025. Wie immer gibt es auch hier Ausnahmen und Übergangsfristen. Bislang ausgenommen bleiben alle Unternehmen, deren Jahresumsatz unter 100 000 Euro liegt [3]. Dasselbe gilt für Kleinstrechnungen bis 250 Euro, beispielsweise Fahrscheine oder Eintrittskarten sowie steuerfreie Umsätze nach Paragraf 4 Nr. 8 bis 29 Umsatzsteuergesetz.
Hier gibt es kleinere Hürden und Unwägbarkeiten: Als Unternehmen oder Selbstständiger können Sie oft nicht verlässlich voraussagen, wie der Umsatz 2025 oder danach aussehen wird. Er kann unter oder auch über der oben genannten Grenze liegen. Wird es mehr als geplant, ist das zwar erfreulich, heißt aber auch, dass am Ende des fiskalischen Abrechnungszeitraums alle bislang gestellten Rechnungen als XRechnung beziehungsweise im Format ZUGFeRD vorliegen müssen. Sie müssen sie dann aktualisieren und mit den Partnern neu austauschen, damit die Daten beiderseits konsistent bleiben. Da kommt bestimmt Freude auf.
Als Unternehmen wissen Sie zudem nicht, welche Regelungen rückwirkend geltend gemacht werden. Die Erfahrung zeigt, dass die Regierungen hier mitunter nicht konsistent handeln. Auch wenn Ihr Unternehmen aktuell noch nicht betroffen ist, erscheint es bedenklich, die Anpassung im Abrechnungsprozess um ein Jahr oder noch länger hinauszuschieben. Das ändert die Situation nicht wirklich, Sie kommen später ohnehin nicht drumherum. Lieber jetzt oder zumindest in naher Zukunft die Schritte umsetzen, als später ein böses Erwachen haben und blanke Hektik ausbrechen lassen.
Bereits 2021 gab es zu diesem Thema einen Beitrag [4] in unserer Schwesterzeitschrift Linux-Magazin, dessen Ergebnis ziemlich gemischt ausfiel. Um es vorwegzunehmen: Das gilt auch heute noch, aber der Reigen der Tools hat sich vervielfältigt. Sie müssen weitaus stärker auswählen, welche Bibliotheken und Werkzeuge Sie verwenden. Im Folgenden besprechen wir funktionierende Open-Source-Lösungen anhand konkreter Problemstellungen. Sie entscheiden dann, welche Werkzeuge sich für Ihre Zwecke am besten eignen und sich am einfachsten in den bestehenden Ablauf einbinden lassen. Planen Sie zusätzliche Zeit ein, um andere Abläufe und Werkzeuge ebenfalls daraufhin zu prüfen, ob sie unter den veränderten Rahmenbedingungen noch zueinanderpassen.
Protokolle
Was sich in Deutschlands Nachbarländern getan hat beziehungsweise zukünftig ansteht, haben wir im Kasten “Europäische Nachbarländer” zusammengefasst. Ähnlich wie in Österreich werden in Deutschland zukünftig zwei Varianten von E-Rechnungen akzeptiert. Dabei spielt auch XML eine Rolle, jedoch im Format UN/CEFACT-XML [5].
Europäische Nachbarländer
Europa hin, festgelegte Standards her: Bei der elektronischen Rechnung kocht bislang jedes europäische Land sein eigenes Süppchen. Die resultierenden Standards sind ärgerlicherweise nicht miteinander kompatibel.
In der Schweiz gilt seit 2022 die Pflicht, Rechnungen mit einem zusätzlichen QR-Code auszustatten (“QR-Rechnung” [21]). In Abbildung 1 sehen Sie einen Beispielcode aus der Dokumentation. Um diese QR-Codes sauber zu erzeugen, steht seit mehreren Jahren eine passende LaTeX-Vorlage [22] bereit. Die über den QR-Code bereitgestellten Daten folgen dem Standard ISO 20022 [23] für den Nachrichtenaustausch zwischen Banken und Kunden. Übermittelt werden damit nur IBAN, Rechnungsnummer beziehungsweise Betreff, Betrag, Währung und das gewünschte Datum zur Ausführung der Transaktion. Mehr muss die ausführende Bank nicht wissen [24]. Die QR-Rechnung entspricht damit einer Zahlungsanweisung beziehungsweise einem Überweisungsauftrag (TA 836 gemäß der Standardisierung durch die SIX).
Ergänzt wird diese elektronische Zahlungsanweisung durch eBill [25]. Mit diesem Verfahren werden die Daten der Zahlungsanweisung an die Bank des Rechnungsempfängers übertragen und danach im Online-Banking in einer Liste der wartenden, vorbereiteten Transaktionen zusammengestellt. Die Zahlung erfolgt erst nach der Prüfung und manuellen Freigabe der Transaktion durch den Rechnungsempfänger. Das fehlerhafte Abtippen der Bankdaten und Vergessen der Bezahlung wird dadurch wesentlich minimiert.
In Österreich gilt die Pflicht zur E-Rechnung seit 2014 zwischen Unternehmen und staatlichen Stellen und seit 2024 zwischen größeren Unternehmen. Ab 2028 wird das auf alle Unternehmensgrößen ausgeweitet. Ausführliche Informationen dazu hält die Webseite des österreichischen Bundesministeriums für Finanzen [26] bereit. Als Austauschformate gelten ebInterface [27] und Peppol-UBL auf der Basis der OASIS Universal Business Language (UBL [28]). Der österreichische XML-Rechnungsstandard ebInterface wurde von der Wirtschaftskammer Österreich/AUSTRIAPRO gemeinsam mit der Wirtschaft spezifiziert. Bei UBL handelt es sich hingegen um einen offenen internationalen Standard, den die Organization for the Advancement of Structured Information Standards (OASIS [29]) pflegt.
In Frankreich müssen seit Juli 2024 alle Unternehmen elektronische Rechnungen empfangen können [30]. Hierbei gilt wie für Deutschland ein E-Mail-Postfach als ausreichend. Frankreich nutzt zum Austausch den Standard Factur-X [31], der ZUGFeRD 2.3 entspricht. Ab 2026 ist es dann für alle französischen Firmen unabhängig von der Unternehmensgröße verpflichtend, Rechnungen elektronisch zu versenden und empfangen zu können. Meldepflichtig sind dabei auch ausländische Unternehmen, die in Frankreich Umsatzsteuer einnehmen.

Abbildung 1: QR-Code für Schweizer Rechnungen (Symbolbild).
Tauschen Sie sich mit jedem Ihrer Projektpartner hierzulande vorab und rechtzeitig aus, welches Format beiderseitig akzeptiert wird. So vermeiden Sie Überraschungen im späteren Ablauf, die den Zahlungsfluss ins Stocken bringen könnten. Es wäre fatal, wenn am Ende ein Disput über akzeptierte Austauschformate für Rechnungen die erfolgreiche Umsetzung eines Projekts trübte.
Die erste Variante der in Deutschland zulässigen E-Rechnungen firmiert unter der Bezeichnung XRechnung. Eine solche besteht aus zwei Dateien, einem PDF-Dokument und einer separaten XML-Datei. Das PDF enthält den visuellen Anteil, das XML den Datenanteil. Versenden oder empfangen Sie eine Rechnung in digitaler Form, werden bei dieser Variante stets zwei Dateien übertragen, die beide Parteien auf Korrektheit und inhaltliche Übereinstimmung prüfen und später revisionssicher archivieren müssen. Inwieweit die XRechnung auch für alle nicht technisch versierten Beteiligten im Alltag tatsächlich praktikabel ist, muss sich noch erweisen.
In der zweiten Variante bilden die XML-Daten einen Bestandteil des PDF-Dokuments. Diese Spielart heißt ZUGFeRD [6], was für Zentraler User Guide des Forums elektronische Rechnung Deutschland steht. Eine ZUGFeRD-Rechnung wird als einzelne Datei übertragen. Dabei müssen ebenfalls beide Parteien den visuellen und den Datenanteil auf Korrektheit und inhaltliche Übereinstimmung prüfen. Auch hier gilt die Pflicht zur revisionssicheren Archivierung.
Der Standard wurde im Juni 2014 erstmals veröffentlicht. Im März 2019 erschien die ZUGFeRD-Version 2.0, die auf der Europäischen Norm EN 16931 vom Juni 2017 basiert. Zudem erfüllt sie die Anforderungen des Standards XRechnung und ist weitgehend identisch mit dem französischen Standard Factur-X. Seit März 2020 gibt es ZUGFeRD 2.1, das vollständig kompatibel mit Factur-X 1.0.05 ist [7]. Das erleichtert den länderübergreifenden Austausch.
Maßgeblich für die elektronische Rechnung ist seit dem 1. Januar 2025 der XML-Anteil und nicht mehr wie bisher die visuelle Umsetzung. Unterscheiden sich die beiden Teile, gilt das automatisiert weiterverarbeitbare XML als maßgeblich [8]. Somit kommt der Extraktion und Validierung des XML eine größere Bedeutung zu als bisher.
Aus den beiden zuvor genannten Formaten ergeben sich eine ganze Reihe von Fragen. Im vorliegenden Artikel gehen wir davon aus, dass Sie eine elektronische Rechnung erhalten haben. Wir sehen uns an, wie Sie das XML aus dem ZUGFeRD-PDF extrahieren und wie Sie eine elektronische Rechnung auf Korrektheit prüfen.
In einem zweiten Teil [9] der Artikelserie geht es dann darum, selbst eine elektronische Rechnung zu erstellen. Dazu sehen wir uns an, welche Daten eine elektronische Rechnung enthalten muss und womit Sie die XML-Daten für eine XRechnung erstellen. Außerdem zeigen wir, wie Sie das PDF-Dokument mit dem XML ZUGFeRD-konform erstellen. Dabei ordnen wir die Open-Source-Werkzeuge gleich zu, sofern das möglich ist.
XML aus ZUGFeRD extrahieren
Es gibt zwei Wege zur Extraktion des XML-Anteils aus einer ZUGFeRD-Rechnung. Am einfachsten gelingt das mit grafischen PDF-Betrachtern, die es ermöglichen, die Anhänge eines Dokuments als separate Datei(en) zu speichern. Hier mussten in unserem Test sowohl Xpdf als auch Evince und Zathura passen. Problemlos gelang der Vorgang hingegen mit Okular (Abbildung 2), dem Adobe Acrobat Reader sowie VeraPDF [10]. Letzteres haben wir Ihnen bereits 2017 in einem Beitrag [11] ausführlich vorgestellt. Das Programm hat den Vorteil, dass es gleich noch entsprechende Validierungsfunktionen mitbringt.
Als weniger komfortable Alternative bleibt die Kommandozeile. In den Ring steigen hier Pdfdetach aus dem Poppler-Projekt [12], das Mustang Project [13], das PDF Toolkit mit Pdftk [14], Factur-x [15] mit seinem Werkzeug Facturx-pdfextractxml und Qpdf [16]. Zunächst einmal geht es an das Auflisten der Anhänge einer PDF-Datei. Das übernimmt Pdfdetach mithilfe des praktischen Schalters -list (Listing 1, erste Zeile). Anschließend wissen Sie, welche Anhänge sich in der PDF-Datei befinden, und können sie extrahieren.
Mithilfe von Pdftk oder Pdfdetach kopieren Sie alle Anhänge in einem Rutsch in das aktuelle Verzeichnis. Pdftk kombiniert dafür die beiden Unterkommandos unpack_files und output, Pdfdetach hingegen begnügt sich mit dem Schalter -saveall. Als Ausgabeverzeichnis geben Sie bei Pdftk explizit . an, bei Pdfdetach ist diese Angabe hingegen nicht erforderlich (Listing 1, Zeile 4 und 5). Sollen die Anhänge in einem Wunschverzeichnis landen, ersetzen Sie bei Pdftk den Punkt durch den tatsächlichen Pfad. Bei Pdfdetach ergänzen Sie die Option -o. gefolgt vom Namen des Zielverzeichnisses (Zeile 6 und 7).
Geht es nur um eine bestimmte Datei aus dem PDF, hilft Ihnen Pdfdetach weiter. Es kennt dafür die Direktive -savefile, an die Sie den Namen der Datei anhängen. Das Beispiel aus der letzten Zeile von Listing 1 zeigt, wie Sie die Datei rechnung.xml aus dem PDF rechnung-komplett.pdf ins aktuelle Verzeichnis extrahieren. Für ein Wunschverzeichnis ergänzen Sie den Aufruf wieder um die Option -o, gefolgt vom Namen des Ordners.
Listing 1
Anhänge auflisten und extrahieren
$ pdfdetach -list rechnung-komplett.pdf 1 embedded files 1: rechnung.xml $ pdftk rechnung-komplett.pdf unpack_files output . $ pdfdetach -saveall rechnung-komplett.pdf $ pdftk rechnung-komplett.pdf unpack_files output Verzeichnis $ pdfdetach -saveall -o Verzeichnis rechnung-komplett.pdf $ pdfdetach -savefile rechnung.xml rechnung-komplett.pdf
Korrektheit prüfen
Selbst, wenn Sie keine elektronischen Rechnungen erstellen und versenden, empfangen Sie ja möglicherweise welche, etwa bei einem Einkauf bei einem größeren Unternehmen, das bereits auf digitale Rechnungen umgestellt hat. Als Marktteilnehmer müssen Sie sicherstellen, dass sowohl in der visuellen Darstellung (PDF) als auch im XML dieselben Angaben stehen. Dieser zusätzliche Prüfschritt trägt dazu bei, spätere Irritationen oder gar Konflikte zu vermeiden.
Wie bereits eingangs erwähnt, gilt bei der elektronischen Rechnung der XML-Anteil als maßgeblich. Uns ist derzeit kein Werkzeug bekannt, das den visuellen Anteil mit dem XML-Anteil abgleicht und dabei eine verlässliche Aussage trifft, ob beide Teile zusammenpassen. Dieser Schritt gelingt nur manuell.
Als geeignete Werkzeuge für den XML-Anteil rücken wiederum das Mustang Project und ZF/FX Validation [17] ins Rampenlicht. ZF/FX Validation kombiniert ZUGFeRD mit VeraPDF. Es überprüft die Konformität zum Standard PDF/A-3 mittels VeraPDF. Die Gültigkeit der XML-Daten gemäß ZUGFeRD 1.0, 2.0 oder 2.1 mit dem Profil EN 16931 gleicht es anhand der jeweiligen Schematron-Dateien ab. Das Programm installieren Sie wahlweise lokal oder nutzen es online (Abbildung 3). Letzteres setzt jedoch eine zuvor abgeschlossene Registrierung beim Projekt voraus.
Einen anderen Weg geht die OpenXRechnungToolbox [18], die für Linux, Mac OS X und Microsoft Windows bereitsteht. Dieses in Java entwickelte Werkzeug ist unter der GPLv3 lizenziert und kombiniert die Kommandozeile mit einer grafischen Bedienoberfläche. Der Autor Dr. Dr. Jan C. Thiele hat den Standard XRechnung mitentwickelt und pflegt OpenXRechnungToolbox in seiner Freizeit.
Das Programm analysiert ebenfalls nur die XRechnung und kein ZUGFeRD-PDF, bereitet dessen Inhalte jedoch übersichtlich auf und erstellt auf Wunsch auch einen Prüfbericht. Damit sehen Sie alle Felder und erhalten zudem eine Einschätzung, ob das Dokument gemäß der Spezifikation plausibel ist. Eine Prüfung der Rechnung in kurzer Zeit gelingt auf diesem Weg selbst nicht IT-affinen Nutzern problemlos. In der Abbildung 4 sehen Sie, wie sich die Gesamtsumme einer XRechnung zusammensetzt. Abbildung 5 zeigt einen Ausschnitt des Prüfberichts zur XRechnung.
Selbst mit intensiver Recherche waren offizielle, behördliche Plattformen zur Überprüfung von XRechnung/ZUGFeRD-PDF nur schwer aufzuspüren. Gefunden haben wir lediglich den E-Rechnungs-Validator des Landes Baden-Württemberg [19]. Auch damit lässt sich eine XRechnung unkompliziert prüfen (Abbildung 6).
Fazit
Das Verarbeiten elektronischer Rechnungen macht das Leben ein Stück komplizierter als bisher. Sie müssen sich nicht nur mit neuer Software vertraut machen: Die Prüfschritte erfordern einen Blick für Details, insbesondere wenn Sie eine Automatisierung anstreben. Als hilfreich erweist sich zumindest, dass das genutzte Austauschformat offen liegt und somit der Integration in eigene Abläufe und Werkzeuge keine Grenzen gesetzt sind. Weitere Informationen zum Thema XRechnung und dem Umgang damit finden Sie in den entsprechenden FAQ [20] des Bundes.
Im folgenden zweiten Teil unserer kleinen XRechnung/ZUGFeRD-Serie wenden wir uns der Erstellung elektronischer Rechnungen zu. Dabei fokussieren wir hauptsächlich auf LaTeX, da Sie damit am besten den Einblick in alle notwendigen Details wahren. (jlu)
Der Autor
Frank Hofmann arbeitet zumeist von unterwegs als Entwickler, Trainer und Autor. Bevorzugte Arbeitsorte sind Berlin, Genf und Kapstadt. Er gehört zu den Verfassern des Debian-Paketmanagement-Buchs [32].
Glossar
-
SIX
-
Schweizer Börse SIX, die größte Schweizer Börse. Entstand 1995 durch den Zusammenschluss der Börsen Genf, Basel und Zürich.
-
Schematron
-
Schemasprache zur Validierung von Inhalt und Struktur von XML-Dokumenten (ISO/IEC 19757-3:2006). Dient anders als DTD oder XML Schema nicht zur Definition von Inhalten in XML-Dokumenten, sondern zur deren Validierung.
Infos
-
“eInvoicing in Italy”: https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/eInvoicing+in+Italy
-
“Bundesrat: Kleinunternehmer von E-Rechnungspflicht teilweise befreit”: https://www.heise.de/news/Bundesrat-Kleinunternehmer-von-E-Rechnungspflicht-teilweise-befreit-10129342.html
-
Bitparade – E-Rechnung: Erik Bärwaldt, “Vereinfacht”, LM 03/2021, S. 38, https://www.lm-online.de/44674
-
UN/CEFACT-XML: https://unece.org/trade/uncefact/xml-schemas
-
“Die Formate ZUGFeRD und Factur-X für elektronische Rechnungen”: https://www.pdflib.com/de/pdf-know-how/zugferd-und-factur-x/
-
“FAQ: Wie unterscheiden sich die E-Rechnung und PDF technisch?”: https://www.heise.de/ratgeber/FAQ-Was-unterscheiden-sich-die-E-Rechnung-und-PDF-technisch-10020051.html
-
ZUGFeRD/XRechnung (Teil 2): Frank Hofmann, “Davongetrabt”, LU 06/2025, S. 22, https://www.linux-community.de/51936
-
VeraPDF: https://verapdf.org
-
VeraPDF: Frank Hofmann, “Genau durchleuchtet”, LU 05/2017, S. 50, https://www.linux-community.de/38741
-
Poppler: https://poppler.freedesktop.org
-
The Mustang Project: https://github.com/ZUGFeRD/mustangproject
-
ZF/FX Validation: https://www.zugferd-community.net/de/open_community/validation
-
OpenXRechnungToolbox: https://github.com/jcthiele/OpenXRechnungToolbox
-
E-Rechnungs-Validator des Landes Baden-Württemberg: https://erechnungsvalidator.service-bw.de
-
XRechnung-FAQ: https://www.e-rechnung-bund.de/faq/xrechnung/
-
“All you need to know about the Swiss QR bill”: https://www.pikon.com/en/blog/everything-you-need-to-know-about-the-swiss-qr-bill/
-
Swiss QR Code LaTeX Template: https://github.com/peiTeX/qrbill
-
ISO 20022: https://www.iso20022.org
-
“Validation of a Swiss QR Code” (PDF): https://www.six-group.com/dam/download/banking-services/standardization/validation-swiss-qr-code-user-guide-en.pdf
-
eBill: https://www.ebill.ch
-
Informationen zur E-Rechnung: https://www.erechnung.gv.at/erb
-
ebInterface: https://www.ebinterface.at
-
OASIS UBL TC: https://oasis.connectedcommunity.org/communities/tc-community-home2?CommunityKey=556949c8-dac8-40e6-bb16-018dc7ce54d6
-
OASIS: https://www.oasis-open.org
-
“E-Invoicing wird in Frankreich ab 2024 auch für B2B verpflichtend”: https://www.retarus.com/blog/de/e-invoicing-wird-in-frankreich-ab-2024-auch-fuer-b2b-verpflichtend/
-
Debian-Paketmanagement-Buch: https://dpmb.org










