Noch 80 Tage bis XML: Die E-Rechnungspflicht ist ein Integrationsproblem, kein PDF-Problem

Im ersten Halbjahr 2026 liefen rund 51 Millionen E-Rechnungen durch die Systeme der DATEV. Im gesamten Jahr 2025 waren es etwa 64 Millionen. Das sind 80 % des Vorjahresvolumens in der halben Zeit, und trotzdem sprach der DATEV-Chef im Juli von einem kleinen Anteil am gesamten Rechnungsverkehr in Deutschland. Für einen großen Teil des kleineren Mittelstands, so seine Einschätzung, stehe das Thema schlicht nicht im Fokus (CIO, Juli 2026 (opens in new tab); it-daily, Juli 2026 (opens in new tab)).

Nach dem heutigen Tag hat das Jahr 2026 noch 80 Tage. 58 davon fallen auf Montag bis Freitag, Feiertage und Jahresabschluss noch nicht abgezogen. Am 1. Januar 2027 endet die Übergangsfrist für das Ausstellen für jedes Unternehmen oberhalb der Umsatzgrenze.

Unsere These: In Schwierigkeiten geraten im Januar die Unternehmen, die das Vorhaben als „unser Rechnungsprogramm muss ein anderes Dateiformat exportieren“ zugeschnitten haben. Das Dateiformat ist das leichte Zehntel der Arbeit. Alles, was eine E-Rechnung gültig, zustellbar, verarbeitbar und prüfbar macht, liegt vor oder hinter dem XML.

Ein Hinweis, bevor es weitergeht: Dieser Beitrag ist eine technische Einordnung und keine Steuer- oder Rechtsberatung. Mit den rechtlichen Fragen gehen Sie bitte zu Ihrem Steuerberater.

Was sich am 1. Januar tatsächlich ändert

Nach § 14 UStG (opens in new tab) muss eine Rechnung zwischen zwei im Inland ansässigen Unternehmern eine elektronische Rechnung sein: ausgestellt in einem strukturierten Format, das der europäischen Norm EN 16931 entspricht, oder in einem zwischen den Beteiligten vereinbarten Format, aus dem sich die Angaben richtig und vollständig in ein normkonformes Format extrahieren lassen. Ein PDF ist das nicht. Es ist eine sonstige Rechnung.

Formal gilt die Pflicht seit dem 1. Januar 2025. Dass PDFs bislang zulässig geblieben sind, liegt an der Übergangsregelung in § 27 Abs. 38 UStG (opens in new tab). Sie besteht aus drei Teilen:

Bis zum 31. Dezember 2026 darf jeder weiterhin auf Papier abrechnen oder, wenn der Empfänger zustimmt, in einem anderen elektronischen Format.
Bis zum 31. Dezember 2027 gilt dieselbe Erleichterung nur noch, wenn der Gesamtumsatz des Rechnungsausstellers (im Sinne des § 19 Abs. 2 UStG) im vorangegangenen Kalenderjahr nicht mehr als 800.000 Euro betragen hat.
Bis zum 31. Dezember 2027 dürfen EDI-Verfahren, die die Anforderungen an eine E-Rechnung noch nicht erfüllen, mit Zustimmung des Empfängers weiterlaufen.

Ab 2028 bleibt davon nichts übrig. Ein Detail geht in den Schlagzeilen unter: Die Grenze bezieht sich auf den Gesamtumsatz, und für 2027 zählt das Jahr 2026, das noch nicht zu Ende ist. Wer in der Nähe von 800.000 Euro liegt, weiß erst nach dem Abschluss der Bücher, auf welcher Seite er steht.

Die Ausnahmen sind eng. Laut den FAQ des BMF (opens in new tab) (Stand März 2026) ist keine E-Rechnung erforderlich für Umsätze an Endverbraucher (B2C), für viele steuerfreie Umsätze, für Kleinbetragsrechnungen bis 250 Euro brutto, für Fahrausweise, die als Rechnungen gelten, für Leistungen von Kleinunternehmern und für Leistungen an juristische Personen, die nicht Unternehmer sind. Für den Empfang gibt es keine Ausnahme: Jedes Unternehmen, Kleinunternehmer eingeschlossen, muss seit dem 1. Januar 2025 E-Rechnungen empfangen können.

Wie weit ist der Markt? Die aktuellste Zahl, die wir gefunden haben, stammt aus einer YouGov-Umfrage unter 502 Unternehmen im Auftrag des Rechnungssoftware-Anbieters easybill, über die im Juni 2026 berichtet wurde: 33 % hatten noch nie eine E-Rechnung versendet, 29 % hatten mit der Umstellung noch nicht begonnen, und 36 % nannten die technische Umsetzung als größtes Hindernis (Händlerbund, Juni 2026 (opens in new tab)). Die Umfrage ist von einem Anbieter beauftragt und entsprechend mit Vorsicht zu lesen, sie deckt sich aber mit dem, was die DATEV berichtet.

Das XML ist das leichte Zehntel

Aus einem Rechnungsdatensatz syntaktisch korrektes UBL oder CII zu erzeugen, ist ein gelöstes Problem. Dafür gibt es ausgereifte Open-Source-Bibliotheken, und die meisten ERP-Systeme und Rechnungsprogramme liefern inzwischen einen Export mit. EN 16931 ist aber ein semantisches Datenmodell mit Geschäftsregeln, und diese Regeln legen den Zustand Ihrer Stammdaten offen.

An den Stammdaten bleiben die Projekte hängen

Eine PDF-Rechnung verzeiht schlampige Daten, weil ein Mensch sie liest. Eine strukturierte Rechnung verzeiht nichts. Diese Muster begegnen uns in solchen Integrationen:

Käuferkennungen. Kundendatensätze ohne Umsatzsteuer-Identifikationsnummer (USt-IdNr.), mit einer veralteten oder mit einer, die jemand in ein Freitext-Notizfeld getippt hat. Bei öffentlichen Auftraggebern fehlt die Leitweg-ID, die die Rechnung an die richtige Behörde leitet, oder sie hängt an der falschen Organisationseinheit. XRechnung verlangt, dass die Käuferreferenz (BT-10) in jeder Rechnung gefüllt ist, öffentliche Hand oder nicht.
Steuerkategorien. Intern kennen viele Systeme „19 %“, „7 %“ und „0 %“. EN 16931 will wissen, warum es null ist: steuerbefreit, Reverse Charge, innergemeinschaftliche Lieferung, Ausfuhr oder nicht steuerbar. Jeder Fall hat seinen eigenen Kategoriecode, und befreite Kategorien brauchen einen Befreiungsgrund. Ein einziger Steuerschlüssel „0 %“, der bisher vier verschiedene Rechtslagen abgedeckt hat, lässt sich nicht automatisch zuordnen.
Mengeneinheiten. Die Norm erwartet Codes nach UN/ECE-Empfehlung 20. In Ihrem Artikelstamm stehen „Stk“, „Stck.“, „St“, „pauschal“ und „siehe Angebot“.
Arithmetik. Nettobeträge der Positionen, Nachlässe, Steueraufschlüsselung und Summen müssen nach festgelegten Rundungsregeln aufgehen. Systeme, die an einer Stelle je Position und an einer anderen je Beleg runden, erzeugen Rechnungen mit einem Cent Abweichung. Ein Mensch übersieht das, ein Validator lehnt die Rechnung ab.

Ein Export-Button behebt nichts davon. Nötig ist eine Datenbereinigung, für die jemand in der Buchhaltung die Verantwortung trägt, dazu Regeln im System, die verhindern, dass die Unordnung nachwächst.

Validieren gehört vor den Versand, nicht hinter die Ablehnung

Das zweite BMF-Schreiben vom 15. Oktober 2025 hat eine Unterscheidung eingeführt, die jeder Entwickler in diesen Projekten kennen sollte. Nach den Zusammenfassungen von Deloitte (opens in new tab) und der IHK Köln (opens in new tab) gibt es drei Fehlerklassen:

Ein Formatfehler liegt vor, wenn die Datei die Syntax der Norm nicht einhält oder sich nicht zuverlässig extrahieren lässt. Eine solche Datei ist überhaupt keine E-Rechnung. Sie gilt als sonstige Rechnung in einem anderen elektronischen Format.
Ein Geschäftsregelfehler liegt vor, wenn die Datei wohlgeformt ist, aber gegen die logischen Regeln verstößt: Ein Pflichtfeld fehlt, oder Beträge und Steuersätze widersprechen sich.
Ein Inhaltsfehler liegt vor, wenn die gesetzlich vorgeschriebenen Rechnungsangaben falsch sind, ganz gleich, was der Validator sagt.

Für einen Aussteller, der 2027 über der Umsatzgrenze liegt, ist eine Datei mit Formatfehler keine ordnungsgemäße Rechnung, und ein sorgfältiger Empfänger weist sie zurück, statt seinen Vorsteuerabzug zu riskieren. Sie erfahren davon, wenn die Zahlung ausbleibt.

Laut den FAQ des BMF ist die Validierung keine formale Voraussetzung für die steuerliche Anerkennung, sie wird aber bei Erstellung und Versand empfohlen. Wir würden weiter gehen und sie zu einem Gate in der Rechnungs-Pipeline machen, so wie ein fehlschlagender Test ein Deployment blockiert. Die Referenzwerkzeuge sind öffentlich: Die KoSIT veröffentlicht ihren Validator (opens in new tab) unter Apache 2.0, er läuft als CLI, als Java-Bibliothek oder als HTTP-Daemon, und das Regelwerk für XRechnung wird als separate Konfiguration ausgeliefert. Binden Sie ihn so ein, dass eine fehlerhafte Rechnung nicht versendet werden kann und dass der Fehler bei der Person ankommt, die den Kundendatensatz korrigieren kann.

XRechnung oder ZUGFeRD: Entscheiden Sie je Empfänger, nicht je Unternehmen

Beide Formate sind zulässig. Die FAQ des BMF nennen XRechnung und ZUGFeRD ab Version 2.0.1 als konform, mit Ausnahme der Profile MINIMUM und BASIC-WL. Wenn Ihr heutiges Programm eines dieser beiden Profile ausgibt und es „ZUGFeRD“ nennt, haben Sie keine E-Rechnung.

Unser Standard für B2B ist ZUGFeRD im Profil EN 16931: Die Sachbearbeitung beim Empfänger kann weiterhin ein PDF öffnen, und die Software dort bekommt das XML. XRechnung ist reines XML ohne Bildteil. Öffentliche Auftraggeber erwarten es, und manche Großkunden verlangen es.

Hybride Dateien bringen einen Zielkonflikt mit, den die meisten Teams übersehen. Die FAQ des BMF halten fest, dass sich der frühere Vorrang umgekehrt hat: In einer hybriden Rechnung ist jetzt der strukturierte Teil führend, und wenn PDF und XML voneinander abweichen, gilt das XML. Kommt das PDF aus einer Word-artigen Vorlage und das XML aus einem getrennten Exportpfad, haben Sie zwei Quellen der Wahrheit, und verbindlich ist die, auf die niemand schaut. Erzeugen Sie das PDF aus demselben Datenobjekt, aus dem auch das XML entsteht, oder lassen Sie das Hybridformat sein.

Hinzu kommt: Die Spezifikationen bewegen sich. Die KoSIT (opens in new tab) gibt an, dass XRechnung 3.0 mindestens bis zum 31. Juli 2027 gültig bleibt und die finale Version 4.0 für das Frühjahr 2027 erwartet wird. Das FeRD (opens in new tab) hat im August 2026 ZUGFeRD 2.5.2 veröffentlicht. Was auch immer Sie bauen oder kaufen, braucht jemanden, der für Formatupdates verantwortlich ist.

Was danach kommt: Eingang, Archiv, Korrekturen, Übermittlung

Das Ausstellen bekommt wegen der Frist die Aufmerksamkeit. Der Empfang ist seit fast zwei Jahren Pflicht und oft in schlechterem Zustand.

Rechnungseingang. Das gesetzliche Minimum für den Empfang ist ein E-Mail-Postfach, die FAQ des BMF sagen das ausdrücklich. Aus diesem Minimum ist ein verbreitetes Anti-Pattern entstanden: Die ZUGFeRD-Datei kommt an, jemand öffnet das PDF, gibt es frei und tippt die Beträge in die Buchhaltung. Das XML, also die eigentliche Rechnung, liest niemand. Ein minimaler korrekter Eingangsprozess extrahiert das XML, validiert es, erzeugt die Ansicht aus dem XML und legt dem Freigebenden genau diese Ansicht vor.

Archivierung. Rechnungen sind acht Jahre aufzubewahren (§ 14b UStG (opens in new tab)), und bei einer E-Rechnung muss mindestens der strukturierte Teil unverändert in seiner ursprünglichen Form erhalten bleiben. Wer die Rechnung ausdruckt oder nur ein gerendertes PDF im DMS ablegt, erfüllt das nicht. Das BMF stellt klar, dass die Aufbewahrung von E-Rechnungen außerhalb eines GoBD-konformen Systems für sich genommen kein Verstoß gegen § 14b ist. Die GoBD gelten aber weiterhin für Ihre Buchführung insgesamt. Die technische Anforderung lautet: die Originalbytes, unveränderbar, mit Hash, verknüpft mit dem Buchungssatz, acht Jahre lang abrufbar, für Ausgangs- wie für Eingangsrechnungen.

Korrekturen. Wo eine E-Rechnung Pflicht ist, muss auch die Berichtigung eine E-Rechnung sein: mit dem Rechnungstyp für eine Rechnungskorrektur und mit einem spezifischen und eindeutigen Bezug auf die ursprüngliche Rechnung (FAQ des BMF unter Verweis auf § 31 Abs. 5 UStDV). Viele Rechnungssysteme lösen Korrekturen heute, indem sie das PDF neu erzeugen oder ein Freitext-Storno schreiben. Beides übersteht den Wechsel zu strukturierten Daten nicht. Sie brauchen echte Belegarten für Rechnungskorrektur und kaufmännische Gutschrift, eine gespeicherte Referenz auf die vorausgegangene Rechnung und die Unveränderbarkeit von allem, was bereits versendet wurde.

Übermittlung. E-Mail ist erlaubt. Eine Strategie ist sie nicht. Sie liefert keine Zustellbestätigung, keinen Status, keine strukturierte Ablehnung, dafür aber die reale Chance, dass ein Mail-Gateway auf der Gegenseite einen .xml-Anhang in Quarantäne schiebt. Das Gesetz überlässt den Übermittlungsweg den Beteiligten. Großkunden werden ein Portal oder Peppol vorgeben, öffentliche Auftraggeber tun das bereits. Behandeln Sie die Übermittlung als Adapter hinter einer Schnittstelle mit mindestens drei Zuständen je Rechnung: versendet, angenommen, abgelehnt mit Begründung.

Was in 80 Tage passt und was nicht

Angenommen, Sie liegen über der Umsatzgrenze und fangen jetzt an: Wir würden den Umfang hart beschneiden.

Jetzt erledigen:

Stammdaten Ihrer wichtigsten Kunden prüfen. Prüfen Sie USt-IdNr., Käuferreferenzen, Adressen und Mengeneinheiten bei den Kunden, auf die der Großteil Ihres B2B-Rechnungsvolumens entfällt. Bereinigen Sie die Daten und ergänzen Sie dann eine Eingabevalidierung, damit neue Datensätze nicht unvollständig gespeichert werden können.
Steuerschlüssel entwirren. Ordnen Sie gemeinsam mit Ihrem Steuerberater jeden internen Steuerschlüssel einer Kategorie nach EN 16931 zu. Das ist die Aufgabe mit der längsten Durchlaufzeit, weil sie je Fall eine menschliche Entscheidung braucht.
Ein Format sauber erzeugen. ZUGFeRD im Profil EN 16931 für B2B, mit einem PDF, das aus denselben Daten gerendert wird. XRechnung kommt nur für Kunden dazu, die es verlangen.
Den Validator in die Pipeline setzen, als hartes Gate und mit einer lesbaren Fehlermeldung für das Backoffice.
Das Original-XML und den Prüfbericht unveränderbar archivieren, für Ausgang und Eingang.
Rechnungskorrekturen und kaufmännische Gutschriften als vollwertige Belegarten umsetzen.
Im Dezember parallel fahren. Versenden Sie das PDF, das Sie heute versenden, erzeugen und validieren Sie parallel die E-Rechnung und behandeln Sie jeden Validierungsfehler als Defekt, der vor dem Januar behoben wird. Bitten Sie zwei oder drei wohlgesonnene Kunden, Ihre Testdateien einzulesen.

Bewusst verschieben:

Die vollständige Automatisierung des Rechnungseingangs: Abgleich auf Positionsebene gegen Bestellungen, automatische Verbuchung, Freigabe-Workflows. Bringen Sie zuerst Extraktion, Validierung, korrekte Visualisierung und Archivierung in Ordnung.
Peppol und einen Adapter für jedes Kundenportal. Beginnen Sie mit E-Mail und dem, was Ihre größten Kunden vorschreiben. Die Schnittstelle bauen Sie jetzt, die Adapter später.
Grenzüberschreitende Rechnungen. Die Pflicht betrifft Umsätze zwischen im Inland ansässigen Unternehmern. Das am 11. März 2025 verabschiedete EU-Paket „VAT in the Digital Age“ bringt ab dem 1. Juli 2030 digitale Meldepflichten für grenzüberschreitende B2B-Umsätze (Europäische Kommission (opens in new tab)). Das ist ein Grund, Ihre Rechnungsdaten an der Semantik von EN 16931 auszurichten statt an einer einzelnen deutschen Ausprägung. Es ist kein Grund, in diesem Quartal irgendetwas dafür zu bauen.

Was wir nicht verschieben würden, ist die Arbeit an den Stammdaten. Die meisten anderen Punkte lassen sich einkaufen oder schnell nachrüsten. Dieser nicht.

Build versus Buy, ehrlich betrachtet

Wir bauen Individualsoftware, also lesen Sie das Folgende mit der entsprechenden Vorsicht. Die meisten Unternehmen sollten das hier nicht selbst bauen.

Der Weg über das ERP oder die DATEV reicht aus, wenn Ihre Rechnungen in einem gängigen ERP-System oder Buchhaltungsprogramm entstehen, dessen Hersteller ein EN-16931-Modul ausgeliefert hat, wenn Ihre Steuerfälle Standard sind, wenn Sie nur ein rechnungsstellendes System haben und wenn Ihre Kunden E-Mail akzeptieren. Schalten Sie das Modul ein, stecken Sie die verbleibende Zeit in Stammdaten und das Mapping der Steuerschlüssel, und fahren Sie im Dezember parallel. In dieser Lage einen eigenen XML-Generator zu schreiben, ist Eitelkeit.

Eine individuelle Integrationsschicht ist ihr Geld wert, wenn:

Rechnungen außerhalb des ERP entstehen: in einer Branchenlösung, einer Buchungs- oder Bestellplattform, einem Autohaussystem oder in selbst entwickelter Software, für die Ihnen kein Hersteller ein Modul liefern wird.
Sie mehrere rechnungsstellende Systeme haben und ein Validierungs-Gate, ein Archiv und einen Audit-Trail wollen statt drei halb konfigurierter.
Das Add-on des Herstellers zwar eine Datei erzeugt, Validierung, Archivierung, Korrekturen oder Übermittlung aber Ihnen überlässt. Das ist häufig der Fall.
Ihre Kunden Anforderungen stellen, die das Add-on nicht abdeckt: bestimmte Käuferreferenzen, Bestellreferenzen je Position, einen Portal-Upload, Peppol.
Die einzige angebotene „Standardlösung“ darin besteht, das System abzulösen, das die Rechnungen erzeugt, und eine Migration unter Termindruck ein größeres Risiko ist als die Pflicht selbst.

Die richtige Lösung ist klein: ein kanonisches Rechnungsmodell auf Basis von EN 16931, Mapper aus jedem Quellsystem, der KoSIT-Validator als Gate, ein Format-Renderer, ein unveränderbares Archiv und Adapter für die Übermittlung. Kein Rewrite des Quellsystems. Nach diesem Muster arbeiten wir auch in unseren eigenen E-Rechnungs-Integrationen: XRechnung und ZUGFeRD in die Software bringen, in der die Rechnungen ohnehin entstehen, statt diese Software auszutauschen.

Die Variante, von der wir jedem abraten würden, taucht meist spät auf: ein eigenständiges Web-Tool, in dem jemand Rechnungen aus dem eigentlichen System abtippt, um eine konforme Datei zu bekommen. Damit halten Sie die Frist und haben danach ein zweites führendes System und ein dauerhaftes Abstimmungsproblem.

Was wir nicht behaupten

Wir behaupten nicht, dass 80 Tage aussichtslos sind. Für ein Unternehmen mit sauberen Stammdaten und einem aktuellen ERP ist das ein Konfigurationsprojekt. Die strukturierte Rechnung ist auch kein bürokratischer Ballast: Eine validierte, maschinenlesbare Rechnung, die sich ohne Abtippen verbuchen lässt, ist ein besseres Artefakt als ein PDF.

Wir behaupten, dass die Frist prüft, ob Ihre Kundendatensätze, Ihre Steuerschlüssel und Ihr Beleglebenszyklus in einem Zustand sind, den eine Maschine kontrollieren kann. Ein Validator ist weit weniger nachsichtig als die Sachbearbeitung in der Kreditorenbuchhaltung, die Ihre Rechnungen seit Jahren stillschweigend korrigiert. Fangen Sie bei den Daten an.

Weiterführende Literatur

BMF, Fragen und Antworten zur Einführung der obligatorischen E-Rechnung (Stand März 2026) (opens in new tab): Anwendungsbereich, Ausnahmen, Formate, Validierung und Archivierung aus erster Hand der Finanzverwaltung.
§ 14 UStG (opens in new tab) und § 27 Abs. 38 UStG (opens in new tab): die Definition und die Übergangsregelungen im Wortlaut.
KoSIT, XRechnung (opens in new tab): die aktuelle Spezifikation, Gültigkeitszeiträume und der Releaseplan.
KoSIT-Validator auf GitHub (opens in new tab): die Open-Source-Prüfsoftware.
FeRD, ZUGFeRD (opens in new tab): das hybride Format und seine aktuelle Version.
Deloitte Tax-News zum BMF-Schreiben vom 15. Oktober 2025 (opens in new tab): die Fehlerklassen und ihre Folgen.