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 entscheidende ZUGFeRD-Punkt wird oft unterschätzt: Das „schöne“ PDF ist nur die Sicht für Menschen – maßgeblich für die E-Rechnung ist der strukturierte XML-Teil. Das BMF stellt klar, dass umsatzsteuerliche Pflichtangaben im strukturierten Teil enthalten sein müssen. Heißt für Kleinunternehmer: Auch wenn du keine Umsatzsteuer ausweist, darf deine Rechnung nicht „irgendwie abgespeckt“ sein. Ein Klassiker ist: Im PDF steht korrekt „§ 19“, aber im XML fehlen Pflichtfelder oder es stehen noch 19 % drin, weil die Software ein Standard-Steuerprofil gezogen hat. Ergebnis: Der Empfänger kann nicht automatisiert buchen – und du hast unnötigen Aufwand.

Ein häufiger Irrtum lautet: „Als Kleinunternehmer muss ich keinen Steuersatz angeben, also kann ich Umsatzsteuer komplett ignorieren.“ Richtig ist: Du stellst ohne Umsatzsteuerausweis in Rechnung, aber der Grund muss erkennbar sein – der Kleinunternehmer-Hinweis gehört sauber auf die Rechnung. Seit 01.01.2025 werden die Anforderungen für Kleinunternehmer-Rechnungen zudem praktisch über die Sonderregel § 34a UStDV greifbarer, weshalb sich ein eigenes Template lohnt (statt eine „normale USt-Rechnung“ nur auf 0 zu setzen). Für deine Vorlagen bedeutet das: Im PDF keine USt-Beträge und keine Prozent-Steuersätze anzeigen, aber den §-19-Hinweis klar platzieren (z. B. im Fußbereich oder unter der Summenzeile).

Damit es in ZUGFeRD wirklich „wasserdicht“ ist, musst du den Hinweis zweigleisig denken: sichtbar im PDF und konsistent im XML. Im PDF haben sich kurze, eindeutige Formulierungen bewährt, z.B.:
– „Gemäß § 19 UStG wird keine Umsatzsteuer berechnet.“
– „Rechnungsstellung ohne Ausweis der Umsatzsteuer gemäß § 19 UStG.“
Optional (gerade bei B2B hilfreich, um Rückfragen zu vermeiden): „Ein Vorsteuerabzug ist aus dieser Rechnung nicht möglich.“
Im XML wiederum darfst du die Umsatzsteuerlogik nicht „leer lassen“ oder widersprüchlich befüllen: Typische Implementierungen arbeiten mit 0-Werten (Steuerbetrag/Steuersatz) plus Befreiungs-/Begründungstext (Exemption Reason). Entscheidend ist weniger die Wortwahl, sondern dass PDF-Aussage und XML-Daten dasselbe sagen – und dein Export eine EN-16931-Validierung besteht.

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/