ZUGFeRD, XRechnung und Co.: Wie elektronische Rechnungen zum Sicherheitsrisiko werden

Unternehmen müssen zunehmend E-Rechnungen nutzen. Im Grunde sinnvoll – sie wurden jedoch unnötig komplex und unsicher umgesetzt.

12. Dezember 2025 um 12:00 Uhr / Ein IMHO von Hanno Böck

XML statt Papier: Elektronische Rechnungen sollen die Bekämpfung von Steuerbetrug erleichtern. Bild: Pixabay

Rechnungen auf Papier oder reine PDF-Dokumente sollen in der EU bald an vielen Stellen verschwinden und durch maschinenlesbare Dokumente ersetzt werden. Der Grundstein für diese Entwicklung wurde bereits 2014 mit der europäischen eInvoicing-Direktive gelegt.

Schon länger üblich sind solche elektronischen Rechnungen, wenn Unternehmen sie an staatliche Stellen senden. Wer etwa für Bundesbehörden einen Auftrag erledigt, muss die Rechnung bereits seit 2020 in einem unterstützten elektronischen Format ausstellen.

Seit 2025 ist auch für Rechnungen zwischen Unternehmen (B2B) eine elektronische Rechnungsstellung vorgesehen , es gelten allerdings verschiedene Ausnahmen und Übergangsregelungen. Die Stoßrichtung ist jedoch klar: Unternehmen müssen zunehmend elektronische Rechnungen empfangen und ausstellen können. Perspektivisch soll damit auch Umsatzsteuerbetrug auf EU-Ebene besser bekämpft werden können.

Grundsätzlich spricht nichts gegen maschinenlesbare Rechnungen, sie hätten einige Vorteile. Doch die technische Umsetzung ist alles andere als optimal. Das gesamte E-Rechnungswesen ist unnötig komplex und auf die Sicherheit wurde bei der Entwicklung offenbar wenig Wert gelegt.

Auf europäischer Ebene gilt für elektronische Rechnungen der Standard EN 16931. Wobei: "Standard" ist nicht ganz korrekt. Es handelt sich eher um einen Meta-Standard, unter dem sich eine Vielzahl von Syntaxen, Profilen, Erweiterungen und weiteren Standards versammeln.

EN 16931 wurde vom Europäischen Komitee für Normung (CEN) spezifiziert. Es gibt hierbei zunächst eine semantische Spezifikation, die lediglich beschreibt, welche Informationen in einer elektronischen Rechnung enthalten sein müssen. In weiteren Teilen der Spezifikation werden sie dann auf konkrete Syntaxen gemappt.

Ein Konglomerat an Standards, Syntaxen, Profilen und Erweiterungen

Dabei gibt es zwei für öffentliche Stellen verpflichtende XML-Syntaxen namens CII (Cross Industry Invoice) und UBL (Universal Business Language). Neben CII und UBL können optionale Syntaxen definiert werden. Weiterhin gibt es die Möglichkeit, die Spezifikation weiter einzuschränken, was als CIUS (Core Invoice Usage Specification) bezeichnet wird, oder Erweiterungen zu definieren.

In Deutschland gibt es den Standard XRechnung, der mit EN 16931 kompatibel ist und gleichzeitig eine CIUS und eine Erweiterung ist. XRechnung wurde von der beim Bremer Senator für Finanzen angesiedelten Koordinierungsstelle für IT-Standards (KoSIT) definiert.

Neben XRechnung gibt es eine weitere deutsche Spezifikation für elektronische Rechnungen namens ZUGFeRD . Von ZUGFeRD gibt es mehrere Profile, von denen einige mit EN 16931 kompatibel sind, andere nicht. Ebenso gibt es ein ZUGFeRD-Profil, das mit XRechnung kompatibel ist.

Viel komplexer, als es sein sollte

Falls die geneigten Leser nun verwirrt sind, sei ihnen versichert: Sie sind damit nicht alleine. Dieses Konglomerat an Standards und Profilen ist viel komplexer, als es sein sollte.

Dabei muss man unterscheiden zwischen Komplexität, die durch die Rahmenbedingungen unvermeidbar ist, und unnötiger Komplexität, die noch obendrauf kommt. Dass elektronischen Formaten für Rechnungen eine gewisse Komplexität inhärent ist, liegt schlicht daran, dass die dahinterliegende Gesetzgebung, etwa was Umsatzsteuern angeht, oft bereits komplex ist. Noch mehr gilt das für europaweite Standards, die Dutzende unterschiedliche rechtliche Rahmenbedingungen abbilden müssen.

Doch nichts davon rechtfertigt, dass etwa die gleichen Informationen in zwei verschiedenen Syntaxen abbildbar sind. Die Ursache für die unterschiedlichen Syntaxen dürfte vor allem sein, dass man sich nicht getraut hat, eine echte Standardisierung durchzusetzen, da die Verfechter der jeweiligen Syntaxen alle darauf beharrt hätten, ihre Syntax zum Standard zu machen.

Zwei Syntaxen für die EU-Standards

Wer mit Personen spricht, die mit der Thematik vertraut sind, hört, dass manche schon froh sind, dass es "nur" zwei Syntaxen sind. Ursprünglich wurden fünf Syntaxen für die EU-Standards in Erwägung gezogen.

Dass in Deutschland mit XRechnung und ZUGFeRD zwei unterschiedliche Standards für E-Rechnungen existieren, hängt zumindest teilweise auch mit den unterschiedlichen Syntaxen zusammen. Bei ZUGFeRD nutzt man CII; XRechnung, das für die öffentliche Verwaltung vorgesehen ist, muss aber aufgrund der EU-Regelungen beide Syntaxen unterstützen. Das wollte man bei ZUGFeRD nicht.

Dazu kommt: ZUGFeRD ist ein hybrides Format, bei dem eine PDF-Datei eine menschenlesbare Rechnung enthält. Zusätzlich sind die Rechnungsdaten als XML-Anhang enthalten. Bei XRechnung wollte man auf ein reines maschinenlesbares Format setzen.

PDF-Lösung hat ihre Tücken

Die Verwendung von einem Hybridformat wie ZUGFeRD ist einerseits verständlich. In der Praxis dürften die wenigsten Personen Software auf ihrem Computer haben, die in der Lage ist, elektronische Rechnungen anzuzeigen. Doch die PDF-Lösung hat auch ihre Tücken. So ist es etwa möglich, eine ZUGFeRD-Rechnung zu erstellen, bei der im menschenlesbaren PDF-Teil andere Geldbeträge verzeichnet sind als im XML-Anhang.

Dass der Wildwuchs an Standards demnächst eingedämmt wird, ist wohl nicht zu erwarten. Wie man hört, soll EN-16931 demnächst überarbeitet und eine dritte Syntax namens EDIFACT aufgenommen werden. Grund dafür ist der Druck aus der Industrie, die bereits EDIFACT an vielen Stellen einsetzt.

Neben der hohen Komplexität erlebt man, wenn man sich mit dem E-Rechnungs-Ökosystem beschäftigt, auch manche Kuriositäten und vieles, das schlicht unprofessionell wirkt.

Defekte Downloads und verwirrende Varianten desselben Standards

Die Bundesdruckerei betreibt etwa eine Webseite , auf der man die Rechnungen für die Behörden von verschiedenen Bundesländern einreichen kann. Auf der Startseite findet sich ein Link, der verspricht, Neulingen zu erklären, wie das Ganze funktioniert. Auf der englischsprachigen Version führt dieser Link zu einer 404-Fehlermeldung. Die Bundesdruckerei haben wir bereits vor Wochen darüber informiert, korrigiert wurde der fehlerhafte Link bislang nicht.

Wenn man sich mit dem elektronischen Rechnungswesen beschäftigt, stößt man immer wieder auf Derartiges: defekte Links, Downloads, die nicht funktionieren oder zur falschen Datei führen , Softwarebeispiele, die nicht funktionieren, oder Informationen auf offiziellen Webseiten, die nicht stimmen. Alles Kleinigkeiten, aber durch die Häufigkeit solcher Probleme bleibt das Gefühl, dass man es mit einem Ökosystem zu tun hat, in dem auf Qualität wenig Wert gelegt wird.

Interessantes erlebt man auch, wenn man versucht, an die Dokumente des europäischen "Standards" EN 16931 zu gelangen. Er wurde, wie erwähnt, von der Standardisierungsorganisation CEN entwickelt und besteht aus mehreren Teilen. Teil eins und zwei sind hierbei kostenlos, die weiteren Teile kosten Geld. Letzteres kann man sicher fragwürdig finden.

Doch auch die kostenlosen Teile zu bekommen, ist nicht ganz einfach. Auf den Webseiten der EU gibt es eine Seite mit dem vielversprechenden Titel Obtaining a copy of the European standard on eInvoicing . Doch dort gibt es keine Download-Links.

Die entsprechenden Verweise führen auf die Webseite der CEN, sie sind aber nicht mehr aktuell. Wer den Links folgt, landet nur bei einer Fehlermeldung und einem Verweis auf die Suche der CEN. Auf diesen fehlerhaften Link haben wir die Verantwortlichen bereits vor Monaten hingewiesen, korrigiert wurde er nicht.

Wer es schafft, bei der CEN die entsprechende Seite der Standards zu finden – möglich ist das etwa, wenn man weiß, dass EN 16931 von der Arbeitsgruppe "CEN/TC 434" verfasst wurde -, kann dort die Standards ebenfalls nicht herunterladen. Man wird auf "Sales Points" (Verkaufsstellen) verwiesen und findet dort eine Liste der nationalen Standardisierungsorganisationen, etwa das für Deutschland zuständige DIN.

Im Shop der DIN findet man dann tatsächlich zahlreiche Dokumente zu EN 16931. Die aktuelle von der DIN herausgegebene Version des ersten Teils trägt samt Versionsnummer den Titel "EN 16931-1:2017+A1:2019 + AC:2020". (Man könnte anmerken, dass diese Versionsnummern ebenfalls komplizierter als notwendig sind.)

Die deutsche englische Version kostet, die spanische englische Version ist kostenlos

Die deutschsprachige Version kann man kostenlos "kaufen", die englischsprachige Version ist allerdings teuer: 374,80 Euro will man bei der DIN dafür haben. Auch die kostenlosen Teile des Standards kann man bei der DIN nicht einfach herunterladen, man benötigt hierfür einen Account.

Allerdings findet man im Shop der DIN weitere Variationen des ersten Teils von EN 16931. So gibt es ihn etwa auch in einer von der spanischen Standardisierungsorganisation AENOR herausgegebenen Variante . Die gibt es wenig überraschend auf Spanisch sowie ebenso auf Englisch. Allerdings erhält man die englische Version des von AENOR herausgegebenen Standards im Shop der DIN kostenlos.

Wer nur auf die kostenlosen Teile des Standards zugreifen möchte, aber keine Lust hat, sich hierfür einen Account zu erstellen, kann sich das auch sparen. Bei der estländischen Standardisierungsorganisation EVS kann man Teil 1 und Teil 2 ohne Registrierung herunterladen. Und wer auf die kostenpflichtigen Teile des Standards zugreifen möchte, sollte ebenfalls den Shop aus Estland bevorzugen. Die Preise sind hier deutlich günstiger.

Kuriose Rundungsregeln

Eine weitere Kuriosität in Sachen EN 16931 sei hier ebenfalls erwähnt: Wer versucht, eine standardkonforme Rechnung für einen Bruttopreis von 99,99 Euro mit 19 Prozent Umsatzsteuer zu erstellen, wird daran scheitern. Die europäische Norm sieht für die Ermittlung der Preise Rundungsregeln vor, die bestimmte Preise unmöglich machen.

Bei einem Nettopreis von 84,02 Euro kommt man auf einen Bruttopreis von 99,98 Euro. Ein Cent mehr – 84,03 Euro – und der Bruttopreis landet bei 100,00 Euro. (Auf diesen Sachverhalt hat Raphael Michel in einem sehenswerten Vortrag auf der vom Chaos Computer Club in Darmstadt organisierten Konferenz MRMCD hingewiesen .)

Doch wie steht es eigentlich um die Sicherheit bei elektronischen Rechnungen? Egal ob ZUGFeRD oder XRechnung, ob CII, UBL oder EDIFACT, all diese Formate und Syntaxen basieren auf XML.

Java und XML – eine riskante Kombination

XML ist, das dürfte den meisten Lesern bekannt sein, ein Meta-Dateiformat, in dem sich Daten strukturiert ablegen lassen. XML stammt aus einer Zeit, in der viele noch glaubten, dass IT-Technologie vor allem dann gut ist, wenn sie möglichst komplex ist und viele Features hat.

Wer den XML-Standard streng nach Spezifikation implementiert, endet fast automatisch bei Software, die gravierende Sicherheitslücken hat. Die meisten Sicherheitsprobleme von XML hängen mit der Verarbeitung sogenannter Entities zusammen.

Durch einen Entity kann man im Header eines Dokuments eine kurze Zeichenfolge definieren, die durch eine andere Zeichenfolge ersetzt wird. Ein normaler Entity fängt dabei immer mit einem &-Zeichen an und endet mit einem Strichpunkt (;).

Entities lassen sich auch verschachteln, und damit besteht die Möglichkeit, Dokumente zu erzeugen, die bei der Verarbeitung Unmengen an Rechenzeit und Speicher benötigen. Anwendungen benötigen dann entweder sehr lange zur Verarbeitung oder stürzen ab. Diese Schwachstelle ist als Billion-Laughs-Angriff bekannt.

Solche Billion-Laughs-Angriffe führen "nur" dazu, dass eine Anwendung potenziell abstürzt oder sehr viel Rechenzeit benötigt, daher sind die Auswirkungen begrenzt. Erwähnenswert ist, dass es sich hierbei nicht um einen einzelnen Angriff handelt, sondern um eine ganze Klasse von verwandten Problemen. Immer wieder werden auch in viel verwendeten XML-Parsern neue derartige Probleme entdeckt. Aktuell gibt es etwa zwei bislang nicht gefixte Sicherheitslücken in Expat , eine der am häufigsten verwendeten XML-Bibliotheken.

XXE-Angriffe – schon lange bekannt

Weit gravierender als diese Denial-of-Service-Probleme sind XXE-Sicherheitslücken (Xml eXternal Entity Injection). Dabei nutzt man als Angreifer aus, dass Entities auch Dateien auslesen können. Das lässt sich am besten mit einem einfachen Beispiel zeigen:

        
<!DOCTYPE xxe [
<!ENTITY e SYSTEM "file:///etc/passwd">
]>
<x>&e;</x>

Hier wird ein Entity &e; definiert, der den Inhalt der Datei /etc/passwd ausgibt. Anschließend wird dieser Entity im XML-Dokument verwendet. In Fällen, in denen man einer auf einem fremden System laufenden Software eine XML-Datei geben und die verarbeitete Ausgabe sehen kann, kann man hiermit Dateien auslesen. In Bezug auf Rechnungen wäre ein Beispiel etwa ein Onlineservice, bei dem man eine Rechnung hochladen und anzeigen kann.

Auch in Situationen, in denen eine XML-Datei verarbeitet wird, aber der Angreifer die Ausgabe nicht zu Gesicht bekommt, ist eine Exfiltrierung von Dateien möglich. Hierfür ist ein sogenannter Blind-XXE-Angriff nötig, der etwas komplexer ist und hier nicht im Detail erklärt werden soll. Die Kernidee ist dabei, eine URL zu konstruieren, die auf einen vom Angreifer kontrollierten Hostnamen verweist und an die der Inhalt einer Datei angehängt wird. Blind-XXE-Angriffe haben einige Einschränkungen, so lassen sich etwa bei vielen XML-Parsern keine URLs aufrufen, die Sonderzeichen oder Newlines enthalten.

XXE-Angriffe sind keine Neuheit, und viele Softwareprojekte haben inzwischen darauf reagiert und sind standardmäßig nicht mehr verwundbar. So gab es etwa bereits 2013 ein entsprechendes Update für die Standardbibliothek in Python , das den Aufruf von lokalen und externen URLs standardmäßig deaktiviert. Bei .NET änderte man die Defaults 2016 . Die LibXML2-Bibliothek löst seit 2013 standardmäßig keine Entities auf , in Expat muss man zur Nutzung von URLs einen speziellen Handler konfigurieren .

All das bietet keine 100-prozentige Sicherheit, doch zumindest in der Standardkonfiguration sind viele XML-Parser nicht mehr für XXE verwundbar. Man muss aktiv potenziell gefährliche Features aktivieren, um verwundbar zu werden.

Doch es gibt auch im Jahr 2025 noch Bibliotheken und APIs, die standardmäßig keinerlei Schutz gegen XXE-Angriffe bieten. Das gilt etwa für die Programmiersprache Java und die in der Standard-Bibliothek verfügbare XML-Funktionalität.

XSLT 2.0 führt zur Nutzung einer unsicheren Bibliothek

Hier haben wir bereits eine gefährliche Mischung. Java wird sowohl in der öffentlichen Verwaltung, als auch im Bereich von Enterprise- und Business-Software sehr häufig verwendet. Wir haben es mit einem inhärent unsicheren Datenformat zu tun, das häufig mit einer Programmiersprache verarbeitet wird, die standardmäßig verwundbar ist. Doch bei den elektronischen Rechnungen kommt noch etwas hinzu.

Von der EU werden Validierungsartefakte bereitgestellt , mit denen man prüfen kann, ob sich eine Rechnung an die Vorgaben von EN 16931 hält. Das ist natürlich erst einmal praktisch, es bietet eine einfache Möglichkeit für Software, Rechnungen, die sich nicht an den Standard halten, zu erkennen. Doch diese Validierungsartefakte sorgen indirekt für noch mehr Sicherheitsrisiken.

Die Validierungsartefakte sind in einer Sprache namens Schematron geschrieben und werden anschließend in XSLT-Dateien übersetzt. Sie nutzen die XSLT-Spezifikation in Version 2.0.

Von XSLT gibt es drei Versionen (1.0, 2.0, 3.0), von den meisten Implementierungen wird jedoch nur XSLT 1.0 unterstützt. Für die späteren XSLT-Versionen gibt es nur eine frei verfügbare Implementierung, eine in Java geschriebene Bibliothek namens Saxon. Für andere Programmiersprachen (PHP, Python, C) existieren Bindings.

Saxon ist nun ebenfalls standardmäßig für XXE-Sicherheitslücken verwundbar. Gegenüber dem Autor dieses Textes haben dessen Entwickler klargemacht, dass sich daran auch nichts ändern wird.

XSLT 2.0 ist bereits seit 2007 eine Empfehlung des W3C. Die gesamte Konstellation – ein "Standard", der von den meisten Implementierungen nicht unterstützt wird, nur eine frei verfügbare Implementierung, die nicht besonders sicher ist – kann man problematisch finden. Der Autor dieses Textes hat auch das W3C auf diese Problematik aufmerksam gemacht , aber dort scheint man darin kein Problem zu sehen.

Für die elektronischen Rechnungen der EU bedeutet das ein zusätzliches Risiko. Wer Software schreibt, die Rechnungen nach EN 16931 verarbeitet, und sie mit den Validierungsartefakten prüfen möchte, dürfte dafür in den allermeisten Fällen Saxon verwenden. Wer Saxon verwendet und nichts von den inhärenten Sicherheitsproblemen weiß, ist für XXE-Angriffe verwundbar.

Wir haben also ein Konglomerat an Rechnungsstandards, die auf XML basieren. Ein Großteil der Software, die diese Rechnungen verarbeitet, ist entweder in Java geschrieben oder nutzt Saxon – oder beides. Sowohl Java als auch Saxon sind standardmäßig für XXE-Sicherheitslücken verwundbar.

13 Sicherheitslücken während Recherche gefunden

Das Resultat ist erwartbar: viel Software mit Sicherheitslücken. Im Zuge der Recherche hat der Autor dieses Textes insgesamt 13 XXE-Sicherheitslücken an die Entwickler verschiedener Tools gemeldet.

Dazu sollte man erwähnen, dass es in dem Bereich viel Software gibt, die wir nicht testen konnten. Viele Softwareprodukte, die mit elektronischen Rechnungen arbeiten, sind kommerzielle Lösungen ohne frei verfügbare Testinstallationen oder Accounts. Getestet haben wir primär kostenlos verfügbare Tools und Onlineservices, mit denen Rechnungen verarbeitet, geprüft oder visualisiert werden können.

Um auch anderen Menschen zu ermöglichen, entsprechende Software auf Sicherheitslücken zu prüfen, steht eine vom Autor dieses Textes erstellte Testsuite bereit .

Viel zu komplexes und enorm anfälliges Konstrukt

Fassen wir also zusammen: Maschinenlesbare Rechnungen sind im Grunde eine sinnvolle Sache. Doch verschiedene unglückliche Entscheidungen von Standardisierungsgremien und der EU haben hier ein Konstrukt geschaffen, das viel zu komplex und enorm anfällig für Sicherheitsprobleme ist.

Was kann man daraus lernen? Zunächst einmal sollten natürlich bestehende Sicherheitsprobleme erkannt und behoben werden. All diejenigen, die Software entwickeln, die elektronische Rechnungen verarbeitet, sollten sich mit der Problematik von XXE-Sicherheitslücken vertraut machen und ihre Produkte auf Verwundbarkeit prüfen.

Wünschenswert wäre, dass der Wildwuchs an Standards, Syntaxen und Profilen bei den EU-Rechnungen eingedämmt wird. Klar, Rechnungen sind inhärent komplex, aber das heißt nicht, dass man ohne Not noch unnötige technische Komplexität obendraufpacken muss.

Für neue Standards und Dokumentenformate XML nicht mehr nutzen

Perspektivisch sollte man daraus lernen. Zumindest für neue Standards und Dokumentenformate sollte man XML nicht mehr nutzen. Ein Format, das inhärent unsicher ist, ist ungeeignet für Dateien, die zwischen zahlreichen Akteuren ausgetauscht und dabei von unterschiedlichster Software verarbeitet werden. Doch auch Softwarehersteller tragen hier eine Verantwortung. Dass manche Software wie Saxon und Oracles Java standardmäßig unsichere XML-Parser ausliefern, ist absolut unverantwortlich.

Weniger unsichere Datenformate wie JSON – nicht perfekt , aber definitiv weniger riskant als XML – würden viele Sicherheitsrisiken von vornherein ausschließen.

Weiterhin sollte es selbstverständlich sein, dass bei der Entwicklung von technischen Standards IT-Sicherheit generell berücksichtigt wird. Erst recht gilt das für Standards, die durch Regulierungen und Gesetze verwendet werden müssen. Ein Abschnitt über Sicherheit ist in der Welt der Internet-Standards übliche Praxis (häufig als "Security Considerations" bezeichnet). Derartiges findet sich weder im europäischen Standard EN 16931 der CEN, noch in den deutschen Standards Xrechnung oder ZUGFeRD.

Der Autor hat auf dem German OWASP Day 2025 einen Vortrag zum Thema gehalten . Weitere Informationen sowie einen Überblick über die gefundenen Sicherheitslücken sind hier zu finden .

IMHO ist der Kommentar von Golem. IMHO = In My Humble Opinion (Meiner bescheidenen Meinung nach)