i-effecteRechnungsinspektor

E-Rechnungsanalyse: warum XRechnung, ZUGFeRD und Factur-X geprüft werden müssen

Eine E-Rechnung ist mehr als nur eine PDF mit Logo. Sie ist ein strukturiertes Datenpaket, das von Buchhaltungssystemen automatisiert gelesen wird und dessen Inhalt rechtlich verbindlich ist. Diese Seite erklärt, welche Risiken dabei entstehen und warum sich eine Prüfung und Visualisierung in jedem Eingangs- und Ausgangsprozess lohnt.

Warum E-Rechnungen geprüft und visualisiert werden müssen

Rechtssicherheit & Vorsteuerabzug

Eine Rechnung ist nur dann umsatzsteuerlich anerkannt, wenn die Pflichtangaben nach § 14 UStG vollständig und in der vorgeschriebenen Form enthalten sind. Fehlt ein Pflichtfeld in der XML, kann das Finanzamt den Vorsteuerabzug nachträglich versagen, auch dann, wenn die PDF-Anzeige korrekt aussieht.

Compliance mit der gesetzlichen Pflicht

Seit dem 1. Januar 2025 müssen alle inländischen Unternehmen E-Rechnungen empfangen können. Ab 2027 gilt im B2B-Bereich für die meisten Unternehmen auch eine Versandpflicht. Ohne Prüfung weiß der Empfänger nicht, ob die eingegangene Datei den gesetzlichen Anforderungen tatsächlich genügt.

Schemafehler & fehlerhafte Codelisten erkennen

Schon kleine Abweichungen wie ein falscher Steuerschlüssel, eine ungültige Codeliste oder eine fehlende Bankverbindung im Kontext SEPA können dazu führen, dass die Rechnung im automatisierten Eingangsworkflow abgelehnt wird. Der Inspektor zeigt jeden dieser Fehler punktgenau mit Regel-ID und Sprung zur betroffenen Stelle in der XML.

Inhalte für Menschen lesbar machen

Die strukturierte XML einer E-Rechnung ist für Menschen nicht direkt lesbar. Eine Visualisierung übersetzt Geschäftstermini (BT- und BG-Codes), löst Codelisten in Klartext auf und zeigt die Rechnung in einer für Buchhaltung und Fachabteilungen verständlichen Form. So werden auch fachliche Fehler sichtbar, etwa ein vertauschter Liefer- und Leistungsempfänger.

Lieferanten- und Kundenkommunikation

Beanstandungen lassen sich nur dann konkret formulieren, wenn man weiß, an welcher Stelle die Rechnung fehlerhaft ist. Mit klar benannten Befunden (Schweregrad, Regel-ID, Position) kann eine Korrektur beim Aussteller schnell und nachvollziehbar angefordert werden.

Besonderheit: Hybride Formate (ZUGFeRD und Factur-X)

ZUGFeRD und Factur-X sind hybride Formate: Eine einzige PDF/A-3-Datei enthält gleichzeitig zwei voneinander unabhängige Inhalte. Diese Doppelnatur ist der häufigste Grund für Verwirrung im Rechnungsprozess.

Sichtbarer Teil: das PDF

Eine grafische Darstellung der Rechnung mit Layout, Logo, Schriften, Texten und Tabellen. Wird vom menschlichen Empfänger geöffnet, gelesen und in vielen Fällen abgeheftet.

Maschinenlesbarer Teil: die XML

Eine strukturierte Datendatei nach EN 16931, eingebettet als Anhang in der PDF. Wird vom Buchhaltungs- bzw. ERP-System automatisiert eingelesen und verbucht.

Beide Teile können sich unterscheiden

Bild und XML sind technisch unabhängig. Niemand zwingt rein technisch dazu, dass beide Teile dieselben Werte zeigen. In der Praxis kommt es regelmäßig vor, dass ein Rabatt im PDF erscheint, aber nicht in der XML steht; dass Zwischensummen unterschiedlich gerundet sind; dass ein Skontotext im PDF formuliert ist, in der XML aber nicht strukturiert hinterlegt wurde.

Rechtliche Bindung: Bei Abweichung zählt die XML

Maßgeblich ist der strukturierte Datensatz

§ 14 UStG definiert die elektronische Rechnung über das strukturierte Format, also die XML. Die PDF-Sichtdatei ist ausdrücklich nicht Teil der gesetzlichen Definition einer E-Rechnung; sie dient lediglich der menschlichen Lesbarkeit. Weichen Bild und XML voneinander ab, ist umsatzsteuerlich der Inhalt der XML bindend. Buchhaltung, Vorsteuerabzug und Archivierung müssen sich daher an der XML orientieren, auch wenn das PDF für den Menschen klarer wirkt.

Praktische Konsequenz: Wer eine Rechnung nur anhand des PDF-Bildes prüft und freigibt, übernimmt das Risiko, einen anderen Betrag zu zahlen oder zu verbuchen, als ihn der Lieferant tatsächlich strukturiert in Rechnung gestellt hat. Die XML muss zumindest stichprobenartig auf inhaltliche Übereinstimmung mit dem PDF kontrolliert werden.

Warum PDF und XML in der Praxis auseinanderlaufen

Die beiden Teile einer hybriden E-Rechnung entstehen häufig aus unterschiedlichen Quellen. Genau dort liegt die Hauptursache für Diskrepanzen:

Das PDF stammt oft aus einer eigenen Layout-Engine

PDFs werden in vielen Unternehmen aus Word-Vorlagen, Reporting-Werkzeugen oder externen Druckdiensten erzeugt. Diese Werkzeuge bringen ihre eigene Logik mit: andere Rundungsregeln, andere Sortierung, automatisch eingefügte Zwischensummen, Texte aus Bausteinen, Mehrsprachigkeit, gestalterische Aggregationen. Was im PDF steht, ist häufig das, was die Layout-Engine daraus gemacht hat, nicht zwingend, was im Datenmodell tatsächlich enthalten ist.

Die XML wird in der Regel separat aus dem ERP exportiert

Die strukturierte XML entsteht meist parallel zum PDF direkt aus dem führenden System (ERP, Faktura). Dabei wird streng nach EN 16931 gemappt. Fehlende Felder bleiben leer, Codelisten werden auf zugelassene Werte eingeschränkt, freie Texte werden nicht in strukturierte Felder übernommen. Was nicht ins Datenmodell passt, fehlt schlicht in der XML.

Empfangssystem und Mensch sehen unterschiedliche Daten

Das eingehende ERP- oder DMS-System wertet ausschließlich die XML aus und zeigt dem Sachbearbeiter nur das, was dort strukturiert vorhanden ist. Der Lieferant hingegen hat seine Rechnung im PDF entworfen und davon ausgegangen, dass der Empfänger genau dieses Bild sieht. Wenn das PDF einen Skontosatz oder einen Lieferzeitraum enthält, der in der XML nicht vorhanden ist, entstehen Rückfragen, Verzögerungen oder im schlimmsten Fall fehlerhafte Zahlungen.

So unterstützt der eRechnungsinspektor

PDF und XML im direkten Vergleich

Bei hybriden Formaten zeigt der Inspektor das Original-PDF und die strukturierte XML nebeneinander, sodass Abweichungen sofort sichtbar werden.

Lesbare Visualisierung der XML

Statt rohem XML-Code zeigt eine an die offiziellen Stylesheets der KoSIT angelehnte HTML-Ansicht den tatsächlichen Inhalt der Rechnung, mit aufgelösten Codelisten und Sprung zur Quellzeile.

Vollständige Konformitätsprüfung

Schema- und Geschäftsregelprüfung gegen EN 16931, XRechnung und Peppol BIS, mit klar gelisteten Fehlern, Warnungen und eindeutigen Regel-IDs.

Klarheit über das rechtlich Bindende

Da der Inspektor immer auch die XML als verbindlichen Teil ausweist, bleibt nachvollziehbar, welche Daten tatsächlich in den Buchhaltungs- und Steuerprozess einfließen.

Häufige Fragen zur E-Rechnungsanalyse

Warum reicht die PDF-Ansicht einer hybriden E-Rechnung nicht aus?+

Bei ZUGFeRD und Factur-X enthält das PDF eine eingebettete XML, die das rechtlich verbindliche Datenmodell darstellt. Die PDF-Sichtdatei dient nur der menschlichen Lesbarkeit. Weichen PDF und XML voneinander ab, ist umsatzsteuerlich der Inhalt der XML bindend. Vorsteuerabzug, Verbuchung und Archivierung müssen sich an der XML orientieren.

Welche Risiken bestehen, wenn nur das PDF geprüft wird?+

Wer eine hybride E-Rechnung nur anhand des PDFs freigibt, übernimmt das Risiko, einen anderen Betrag zu zahlen oder zu verbuchen, als der Lieferant strukturiert in Rechnung gestellt hat. Fehlt ein Pflichtfeld nach § 14 UStG in der XML, kann das Finanzamt den Vorsteuerabzug versagen, auch wenn das PDF korrekt aussieht.

Müssen Unternehmen E-Rechnungen ab 2025 zwingend empfangen?+

Ja. Seit dem 1. Januar 2025 müssen alle inländischen Unternehmen im B2B-Bereich E-Rechnungen nach EN 16931 empfangen können. Eine Zustimmung des Empfängers ist nicht mehr erforderlich. Für den Versand gelten Übergangsfristen bis Ende 2026 bzw. 2027.

Welche Formate gelten als zulässige E-Rechnung in Deutschland?+

Zulässig sind alle der EN 16931 entsprechenden strukturierten Formate: XRechnung 3.0 (CIUS und Extension), ZUGFeRD ab Version 2.0.1 in den Profilen BASIC, EN 16931 und EXTENDED, Factur-X sowie Peppol BIS Billing 3.0. Die ZUGFeRD-Profile MINIMUM und BASIC WL gelten laut BMF nicht als vollwertige E-Rechnung. Ebenfalls zulässig sind EDI-Rechnungen (z. B. EDIFACT INVOIC), sofern der ausgetauschte Datensatz der EN 16931 entspricht. Wer seine Handelspartner also bereits per EDIFACT INVOIC anbindet, erfüllt die gesetzliche Anforderung, solange die Nachricht normkonform ist.

Warum laufen PDF und XML einer hybriden Rechnung in der Praxis auseinander?+

Das PDF entsteht oft aus einer Layout-Engine (Word-Vorlage, Reporting-Tool) mit eigenen Rundungsregeln und Aggregationen, während die XML direkt aus dem ERP nach EN 16931 exportiert wird. Freie Texte, Skontosätze oder Lieferzeiträume aus dem PDF fehlen häufig im strukturierten Datenmodell.

Hinweis: Diese Seite dient der allgemeinen Erläuterung. Für die rechtliche Bewertung im Einzelfall wenden Sie sich bitte an Ihren steuerlichen Berater.