Für Nutzer von RechnungFertig ist dabei vor allem wichtig:
RechnungFertig orientiert sich primär am Profil EN16931 der ZUGFeRD-Spezifikation. Dieses Profil bildet den gesetzlich relevanten Kern für elektronische Rechnungen ab. Viele der jetzt genannten Änderungen betreffen dagegen vor allem das umfangreichere Profil EXTENDED und sind deshalb für typische RechnungFertig-Anwendungsfälle meist nicht relevant.

Was sich mit ZUGFeRD 2.5 ändert

Die neue Version aktualisiert vor allem:

• Validierungsartefakte
• Codelisten
• Schematron- und XSD-Dateien
• die technische Basis auf UN/CEFACT CII D22B
• verschiedene Regeln und Elemente im Profil EXTENDED

Außerdem wird ausdrücklich darauf hingewiesen, dass leere XML-Elemente vermieden werden müssen. Wenn optionale Felder keinen Inhalt haben, sollen sie nicht leer in die XML-Datei geschrieben werden, sondern vollständig entfallen. Sonst kann bei der Prüfung die Meldung erscheinen:

„Document MUST not contain empty elements“

Das ist eine technische Validierungsregel und betrifft vor allem die korrekte Erzeugung der XML-Daten im Hintergrund.

Warum viele Änderungen für RechnungFertig-Nutzer kaum spürbar sind

Ein großer Teil der Neuerungen betrifft das Profil EXTENDED. Dort wurden unter anderem neue Angaben für Steuerbefreiungsgründe, Zahlungsinformationen, Zahlungen im Auftrag Dritter und bestimmte Referenz-Codelisten ergänzt.

Diese Erweiterungen sind vor allem für komplexere Geschäftsvorfälle, internationale Anforderungen und die Interoperabilität mit der französischen B2B-E-Rechnungspflicht gedacht.

Für typische RechnungFertig-Nutzer, die einfache, gesetzeskonforme Rechnungen schreiben möchten, ist das meist nicht entscheidend. RechnungFertig konzentriert sich auf den praktischen Kern: Rechnungen korrekt erstellen, E-Rechnungspflichten erfüllen und dabei einfach bedienbar bleiben.

Was bleibt wichtig

Für Nutzer zählt vor allem:

ZUGFeRD 2.5 ist rückwärtskompatibel.
Die neue Version ist technisch weiterentwickelt, bricht aber nicht grundsätzlich mit bisherigen Versionen.

Das Profil EN16931 bleibt der zentrale Orientierungspunkt.
Für die meisten gesetzeskonformen E-Rechnungen ist nicht das maximal umfangreiche EXTENDED-Profil entscheidend, sondern die saubere Umsetzung der EN16931-Anforderungen.

Formate wie XRechnung und ZUGFeRD bauen auf dieser Norm auf. Deshalb ist die neue Fassung EN 16931-1:2026 auch für alle interessant, die sich mit der E-Rechnungspflicht beschäftigen – vom großen Unternehmen bis zum kleinen Einzelunternehmer.

Die gute Nachricht vorweg:
Für viele kleine Selbstständige, Freelancer und Einzelunternehmer dürfte sich durch die neue Norm im Alltag erst einmal wenig ändern. Die neue Fassung bringt vor allem mehr Klarheit und technische Erweiterungen für komplexere Geschäftsvorfälle. Wer nur wenige einfache Rechnungen im Monat schreibt, wird von dieser zusätzlichen Komplexität meist kaum direkt betroffen sein.

Was ist die EN 16931 überhaupt?

Die EN 16931 beschreibt das europäische Datenmodell für elektronische Rechnungen. Vereinfacht gesagt: Sie definiert, welche Pflichtangaben und Datenstrukturen eine elektronische Rechnung enthalten muss, damit sie europaweit verstanden und verarbeitet werden kann.

Dazu gehören zum Beispiel:

• Angaben zu Rechnungsaussteller und Rechnungsempfänger
• Rechnungsnummer und Rechnungsdatum
• Leistungsbeschreibung
• Beträge, Steuersätze und Steuerbeträge
• Zahlungsinformationen
• Referenzen wie Bestellnummern oder Lieferangaben

Damit bildet die Norm die fachliche Grundlage für E-Rechnungsformate wie XRechnung und ZUGFeRD. Diese Formate sorgen dafür, dass Rechnungen nicht nur als PDF lesbar sind, sondern auch strukturierte Daten enthalten, die von Software automatisch verarbeitet werden können.

Was ist neu an der EN 16931-1:2026?

Die neue Version der Norm wurde erstmals seit 2017 umfassend überarbeitet. Ziel war es, die Norm näher an die Praxis heutiger Geschäftsprozesse anzupassen und sie gleichzeitig auf kommende europäische Anforderungen vorzubereiten.

Ein Schwerpunkt liegt auf der besseren Abbildung komplexerer B2B-Geschäftsvorfälle. Die neue Norm kann zum Beispiel differenzierter mit mehreren Bestellungen, mehreren Lieferungen oder verschiedenen Referenzen innerhalb einer Rechnung umgehen. Auch Zahlungsbedingungen, Rollen der beteiligten Parteien und Identifikatoren wurden präziser beschrieben.

Für größere Unternehmen, Lieferketten, öffentliche Auftraggeber oder Branchen mit komplexen Rechnungsprozessen ist das wichtig. Dort kommt es häufig vor, dass eine Rechnung mehrere Vorgänge zusammenfasst oder viele Referenzen enthalten muss.

Weniger Interpretationsspielraum, bessere Verarbeitung

Ein weiteres Ziel der neuen Norm ist mehr Eindeutigkeit. Viele Begriffe und sogenannte Business Terms wurden überarbeitet, genauer definiert oder technischer sauberer beschrieben.

Das ist vor allem für Softwareanbieter und größere Organisationen relevant. Je klarer die Regeln sind, desto geringer ist das Risiko, dass verschiedene Systeme dieselbe Rechnung unterschiedlich interpretieren.

Für die Praxis bedeutet das: E-Rechnungen sollen zuverlässiger verarbeitet werden können. Fehler durch unterschiedliche Auslegungen sollen seltener auftreten. Gerade bei automatisierten Prozessen ist das ein wichtiger Schritt.

Vorbereitung auf ViDA und digitale Umsatzsteuer-Meldungen

Die neue EN 16931-1:2026 bereitet außerdem auf kommende europäische Vorgaben wie ViDA vor. ViDA steht für „VAT in the Digital Age“ und beschreibt europäische Pläne zur Digitalisierung der Umsatzsteuerprozesse.

Langfristig sollen elektronische Rechnungen nicht nur zwischen Unternehmen ausgetauscht werden, sondern auch eine Grundlage für digitale, transaktionsbasierte Steuer- und Umsatzsteuer-Meldungen bilden.

Die neue Norm enthält deshalb zusätzliche Datenpunkte und Strukturen, die künftig für solche Meldepflichten wichtig werden könnten. Die E-Rechnung wird damit zunehmend zu einem zentralen Baustein digitaler Steuerprozesse.

Fazit

Die neue EN 16931-1:2026 ist ein wichtiger Schritt für die europäische E-Rechnung. Sie macht das Datenmodell robuster, klarer und besser vorbereitet auf kommende digitale Meldepflichten. Für große Unternehmen und Softwarehersteller ist das eine relevante technische Weiterentwicklung.

Was bedeutet das für Einzelunternehmer und kleine Selbstständige? Für die meisten Nutzer von RechnungFertig sind die unmittelbaren Auswirkungen eher gering.

Rechnungstypen

Ein Kernpunkt sind Rechnungen mit verschiedenen Rechnungstypen (Business Term 3). Damit lassen sich unterschiedliche Geschäftsfälle klarer abbilden, ohne Workarounds oder manuelle Umbenennungen im Dokument. Durch ein Popup, das über das Fragezeichensymbol aufrufbar ist, gibt es zudem weitere Erklärungen dazu, wie insbesondere Gutschriften bzw. negative Rechnungen je nach Kontext erstellt werden sollten.

XRechnung

XRechnungen können nun explizit erzeugt werden. Das ist vor allem relevant, wenn Sie für öffentliche Auftraggeber arbeiten (B2G), denn dort ist die strukturierte E-Rechnung mitlerweile Pflicht. Wenn also Ihre Kunden XRechnung verlangen, müssen Sie nicht mehr auf externe Umwege ausweichen, sondern können den Prozess direkt abbilden.

Weitere Neuerungen

Zu den weiteren Neuerungen gehört, dass Rechnungen nun im CSV-Format exportiert werden können. Der CSV-Export beinhaltet dabei wirklich alle Daten der Rechnung, so dass nachgelagerte Use Cases von EÜR bis Verkaufsartikelanalysen durchgeführt werden können. Außerdem gehört jetzt das Email-Feld auf Käuferseite dazu, was insbesondere bei XRechnungen wichtig ist. Last-but-not-least wurde das Dark-Theme vervollständigt, so dass Nutzer, die eher in den Abendstunden arbeiten, nun eine etwas augenschonendere Oberfläche am Abend aktivieren können.

Der wichtigste Anwendungsunterschied ist also das Einsatzszenario: B2G (Rechnung an Behörden/öffentliche Auftraggeber) ist der Bereich, in dem XRechnung in der Praxis verlangt wird – inklusive Pflichtangaben wie Leitweg-ID/Buyer Reference oder Bestellbezug, sonst wird die Rechnung schnell abgewiesen. Im B2B-Alltag (Agenturen, KMU, andere Selbständige) liessen sich XRechnungen theoretisch auch verwenden, aber ZUGFeRD ist hier eher die stressfreiere Lösung, weil sich Rechnungen intern leichter prüfen, weiterleiten und „auf Sicht“ freigeben lassen – und trotzdem bereits die strukturierten Daten für die Buchhaltung/ERP enthalten. Wichtig: Beide Formate können grundsätzlich EN 16931-konform sein, entscheidend ist also weniger „legal oder nicht“, sondern was Ihr Kunde akzeptiert und technisch verarbeitet.

Rechtlich hat sich der Druck seit 2025 klar erhöht (Stand 16.01.2026): Unternehmen müssen seit 01.01.2025 grundsätzlich E-Rechnungen empfangen können, während es fürs Ausstellen im B2B-Bereich Übergangsregeln gibt. Praktisch heißt das für Freiberufler: Sie sollten spätestens jetzt in der Lage sein, strukturierte E-Rechnungen zu erzeugen – auch wenn Sie in der Übergangszeit ggf. noch mit klassischen PDFs arbeiten dürfen (oft aber nur mit Zustimmung des Empfängers). Spätestens wenn Kunden aktiv E-Rechnungen anfordern oder ihre Buchhaltung auf automatisierte Prozesse umstellt, wird ein „nur-PDF“-Workflow auf Dauer schwierig.

Die klassische Gutschrift (Typ 381) ist die richtige Wahl, wenn Sie dem Empfänger einen Betrag gutschreiben möchten (z.B. Rückerstattung, Bonus, Preisnachlass nachträglich, Kulanz), ohne zwingend eine bestehende Rechnung „zu stornieren“. Wichtig dabei: Die Gutschriftwirkung entsteht ausschließlich über den Dokumenttyp 381 – nicht dadurch, dass Sie Beträge negativ ausweisen. In der typischen ZUGFeRD/EN-16931-Umsetzung werden Positionswerte (Netto/Steuer/Brutto) ganz normal positiv befüllt, so wie bei einer normalen Rechnung. Das ist ein häufiger Stolperstein, weil manche Anwender intuitiv alles „ins Minus drehen“ – was dann je nach Empfängerprozess zu Rückfragen oder Ablehnungen führen kann.

Eine Negativrechnung (Typ 380) wird oft dann genutzt, wenn Sie technisch eine „normale Rechnung“ senden wollen, deren Gesamtbetrag negativ ist – zum Beispiel bei Schlussrechnungen nach Vorauszahlungen/Abschlägen oder in Verrechnungslogiken. In diesem Kontext ist also eine Negativrechnung eine ganz normale Rechnung, aber eben mit einem negativen Endergebnis. Die gängige Modellierung ist hier: Netto-Beträge bleiben positiv, aber die Menge wird negativ angegeben, sodass sich der negative Gesamtbetrag rechnerisch ergibt. Das kann funktionieren, ist aber in der Praxis sensibler, weil nicht jedes Portal oder jeder Workflow negative Endbeträge in einer „normalen Rechnung“ gleich gut akzeptiert. Wenn Sie häufig an öffentliche Auftraggeber oder über streng validierende Kanäle schicken, ist diese Variante besonders sorgfältig zu testen.

Wenn Sie hingegen eine konkrete, bereits gestellte Rechnung stornieren oder korrigieren müssen, ist meist die Rechnungskorrektur (Typ 384) der sauberste Weg. Auch hier werden die Beträge in den Positionsfeldern typischerweise positiv geführt; die Korrekturwirkung wird häufig über negative Mengen (oder über die Differenzlogik, je nach Prozess) abgebildet. Der entscheidende Punkt bei 384 ist aber weniger „Vorzeichen-Tricks“, sondern die eindeutige Referenz auf das Original: Die zu korrigierende Rechnung muss im Dokument korrekt referenziert werden (Preceding Invoice Reference / BG-3), damit Empfänger-Systeme die Korrektur automatisiert zuordnen können und nicht „zwei unabhängige Dokumente“ sehen.

Als Merkhilfe für Ihren Arbeitsalltag: 381 verwenden, wenn Sie eine Gutschrift als solche ausstellen (Gutschriftwirkung über den Typcode, nicht über Minus-Beträge). 384 verwenden, wenn Sie eine bestimmte Rechnung stornieren/korrigieren (inkl. Referenz auf das Original). 380 negativ nur dann nutzen, wenn Ihr Prozess bewusst mit negativen Rechnungen arbeitet und Sie sicher sind, dass der Empfängerkanal das akzeptiert. Und noch ein Sprach-Fallstrick: Im deutschen Steuerkontext bedeutet „Gutschrift“ manchmal das Gutschriftsverfahren/Selbstfakturierung – das ist technisch ein eigener Typcode (häufig 389) und etwas anderes als eine „kaufmännische Gutschrift“ im Sinne von 381.

Weiterführende Links / Quellen

• ZUGFeRD-Spezifikation 2.4: „0_FACTUR-X 1.08 2025 12 04 DE.pdf“, 7.1.6 Umgang mit Gutschrift, S. 38f
• ZUGFeRD/Factur-X Spezifikation (GEFEG), Abschnitt zu Invoice type code (BT‑3) und Typcodes (380/381/384):
  https://portal3.gefeg.com/projectdata/invoice/deliverables/installed/publishingproject/zugferd%202.0.1%20-%20facturx%201.03/en%2016931%20%E2%80%93%20facturx%201.03%20%E2%80%93%20zugferd%202.0.1%20-%20comfort.scm/html/de/0213.htm
• FAQ E‑Rechnung Bund: Credits und Rechnungskorrekturen in EN 16931/XRechnung (Praxis- und Interpretationshinweise):
  https://e-rechnung-bund.de/en/faq/how-should-i-indicate-credits-and-invoice-corrections/

Beim Versenden ist 2026 oft noch ein Übergangsjahr: Viele dürfen im B2B-Umfeld je nach Konstellation weiterhin „sonstige Rechnungen“ (PDF/Papier) nutzen – teils an Bedingungen geknüpft, etwa an die Zustimmung des Empfängers. Aber genau hier lauert der Praxis-Fallstrick: Große Kunden, Konzerne und öffentliche Auftraggeber stellen ihre Prozesse um und akzeptieren zunehmend nur noch strukturierte Rechnungen oder verarbeiten sie bevorzugt. Heißt für dich: Auch wenn du rechtlich vielleicht noch „dürftest“, kann es 2026 schon geschäftlich unklug sein, bei reinen PDF-Rechnungen zu bleiben – weil du sonst im schlimmsten Moment (wenn ein wichtiger Kunde umstellt) hektisch nachrüsten musst.

Technisch sind 2026 vor allem drei Begriffe wichtig: XRechnung, ZUGFeRD 2.x (z. B. 2.2) und „hybride PDFs“. XRechnung ist ein reines XML-Format (basierend auf EN 16931) und besonders im B2G-Bereich Standard, schwappt aber in B2B immer stärker rüber; deine Software sollte mindestens die gängigen aktuellen XRechnung-Versionen sauber unterstützen. ZUGFeRD ist für viele Kleine der pragmatische Einstieg: PDF/A-3 + eingebettete XML-Daten – Menschen können das PDF lesen, Systeme verarbeiten die XML. Wichtig ist dabei: Nicht jedes ZUGFeRD-Profil ist „voll EN-16931“; in der Praxis gelten bestimmte Profile (z. B. MINIMUM/BASIC-WL) als nicht ausreichend für eine „vollwertige“ E-Rechnung. Und: Bei hybriden Formaten zählt steuerlich und technisch zunehmend der strukturierte Teil – das PDF ist eher Anzeige, die XML ist die Wahrheit. Abweichungen zwischen PDF und XML können unnötige Risiken und Rückfragen auslösen.

Was solltest du jetzt (2026) konkret tun – und was kann warten? Jetzt solltest du (1) einen festen Eingangskanal definieren (z. B. rechnung@…), (2) sicherstellen, dass du XRechnung/ZUGFeRD anzeigen und idealerweise validieren kannst (Viewer/Validator oder direkt im Buchhaltungstool), und (3) die Archivierung GoBD-tauglich aufsetzen – inklusive der strukturierten Datei (XML), nicht nur „PDF abheften“. Planen solltest du 2026 außerdem die Umstellung deiner Ausgangsrechnungen auf mindestens ein E-Rechnungsformat (oft ZUGFeRD als Standard + XRechnung für Kunden/Portale, die es verlangen) und deine Stammdaten disziplinieren (Adresse, USt-ID, Leistungsdatum, Steuersätze etc.), weil Validatoren Fehler gnadenlos sichtbar machen. Im Blick behalten solltest Du – je nach Geschäftsmodell – das große EU-Thema ViDA: Die EU-weiten Digital-Reporting-Pflichten für grenzüberschreitende B2B-Umsätze kommen erst später (ab 2030).

Weiterführende Quellen

• BMF – FAQ zur E-Rechnung (Deutschland, Definition/Empfangspflicht/Kleinunternehmer): https://www.bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html
• Haufe – Überblick E-Rechnungspflicht und Übergangsregelungen: https://www.haufe.de/steuern/gesetzgebung-politik/elektronische-rechnung-wird-pflicht-erechnung-im-ueberblick_168_605558.html
• EU-Kommission (TAXUD) – ViDA-Paket, Zeitplan/DRR: https://taxation-customs.ec.europa.eu/news/adoption-vat-digital-age-package-2025-03-11_en
• IHK Köln – Hinweise zu BMF-Schreiben/E-Rechnung, Profile/Abweichungen Hybridformate: https://www.ihk.de/koeln/hauptnavigation/recht-steuern/steuern/bmf-schreiben-zur-e-rechnung-vom-15-10-2025-6774012
• IHK (Entwurf/Material zu BMF-Schreiben, Validierung/Umsetzungshinweise): https://www.ihk.de/meo/recht-und-steuern/steuerrecht/downloads/beitraege/entwurf-fuer-ein-2-bmf-schreiben-zur-e-rechnungspflicht-6612416