XRechnung Bugfix Release Winter 2025/26: Neuer Validator, SeMoX und was sich ändert

Am 5. Februar 2026 hat die KoSIT das Bugfix-Release Winter 2025/26 für XRechnung veröffentlicht. Es enthält einen aktualisierten Validator, erstmals SeMoX-Modelle und eine technische Umstellung auf SchXslt. Klingt komplex — ist es auch. Aber was davon betrifft dich wirklich? Hier ist die Übersicht.

Das Wichtigste in Kürze

• Bugfix-Release veröffentlicht am 5. Februar 2026 (Bundledatum 31.01.2026)
• Validator 1.6.0 für aktuelle Java-Versionen + Validator 1.5.0 für Java 8
• SeMoX-Modelle erstmals im offiziellen Bundle enthalten
• Schematron-Implementierung umgestellt von ISO Schematron auf SchXslt
• Neue Peppol-Geschäftsregel PEPPOL-EN16931-R120 (CII, aktuell Warnung)
• Kompatibel mit XRechnung 3.0 / 3.0.2
• Keine Pflicht zur sofortigen Umsetzung — aber zeitnahes Update empfohlen
• Factora nutzt den aktuellen Validator — kein Handlungsbedarf für Nutzer

---

Was ist ein Bugfix-Release?

Die KoSIT (Koordinierungsstelle für IT-Standards) veröffentlicht regelmäßig Updates für den XRechnung-Standard. Dabei gibt es zwei Arten von Releases:

• Major Releases — Neue Versionen wie XRechnung 3.0 oder die kommende XRechnung 4.0. Diese bringen strukturelle Änderungen am Datenmodell und neue Funktionen.
• Bugfix Releases — Korrekturen und Verbesserungen innerhalb einer bestehenden Version. Das Datenmodell bleibt unverändert, aber technische Komponenten werden aktualisiert.

Das Bugfix-Release Winter 2025/26 gehört zur zweiten Kategorie. Es korrigiert keine inhaltlichen Fehler im Standard, sondern aktualisiert die technischen Werkzeuge, die zur Validierung und Verarbeitung von XRechnung-Dateien eingesetzt werden.

Warum ist das trotzdem wichtig? Weil der Validator das zentrale Werkzeug ist, mit dem geprüft wird, ob eine E-Rechnung den Standard erfüllt. Ein veralteter Validator kann zu falsch-positiven oder falsch-negativen Ergebnissen führen — und das kann bedeuten, dass eine Rechnung abgelehnt wird, obwohl sie korrekt ist, oder durchgeht, obwohl sie Fehler enthält.

Alle Änderungen im Detail

Validator 1.6.0 und 1.5.0

Das Bundle enthält erstmals zwei Validator-Versionen parallel:

Validator-Version	Java-Kompatibilität	Empfehlung
1.6.0	Java 11+ (aktuelle JVMs)	Für alle aktuellen Systeme
1.5.0	Java 8+	Für Legacy-Systeme mit Java 8

Warum zwei Versionen? Java 8 ist seit September 2023 End of Life (öffentliche Updates eingestellt). Die Weiterentwicklung des Validators auf Java-8-Basis ist technisch zunehmend aufwändig. Mit Version 1.6.0 setzt die KoSIT auf aktuelle Java-Versionen — und liefert für Legacy-Systeme Version 1.5.0 mit.

Was bedeutet das für dich?

• Wenn du eine E-Rechnungs-Software wie Factora nutzt: Gar nichts. Die Software kümmert sich um die Validierung.
• Wenn du den Validator selbst betreibst (z. B. als Entwickler oder IT-Abteilung): Prüfe deine Java-Version und wähle den passenden Validator.
• Wenn du noch Java 8 nutzt: Langfristig solltest du auf eine aktuelle Java-Version migrieren. Validator 1.5.0 ist ein Kompromiss, kein Dauerzustand.

SeMoX-Modelle erstmals im Bundle

SeMoX steht für Semantic Model Exchange — ein Format zur maschinenlesbaren Beschreibung semantischer Datenmodelle. Mit dem Bugfix-Release Winter 2025/26 sind SeMoX-Modelle erstmals im offiziellen XRechnung-Bundle enthalten.

Was beinhalten die SeMoX-Modelle?

• CIUS XRechnung — Das Core Invoice Usage Specification-Modell, also die deutsche Anpassung der EU-Norm
• Extension XRechnung — Die deutschen Erweiterungen über den EU-Standard hinaus
• CIUS XRechnung CVD — Das Code Value Domain-Modell mit den zulässigen Wertebereichen

Warum ist das wichtig?

SeMoX-Modelle ermöglichen es Softwareherstellern, die Struktur des XRechnung-Standards automatisch zu verarbeiten. Bisher mussten Entwickler die Spezifikation manuell interpretieren und in Code umsetzen. Mit SeMoX können:

• Dokumentationen automatisch generiert werden
• Validierungsregeln maschinell abgeleitet werden
• Mapping-Tabellen zwischen verschiedenen Systemen erstellt werden
• Interoperabilitätstests automatisiert werden

Für Anwender ändert sich nichts Sichtbares. Aber hinter den Kulissen wird die Qualität der E-Rechnungs-Software besser, weil Hersteller den Standard präziser implementieren können.

Schematron-Umstellung auf SchXslt

Die technisch tiefgreifendste Änderung im Bugfix-Release: Die Schematron-Implementierung wurde von ISO Schematron auf SchXslt umgestellt.

Was ist Schematron?

Schematron ist eine Validierungssprache für XML-Dokumente. Bei XRechnung wird Schematron verwendet, um die Geschäftsregeln zu prüfen — also nicht nur, ob die XML-Struktur korrekt ist, sondern ob die Inhalte sinnvoll sind.

Beispiele für Schematron-Regeln:

• „Wenn die Steuerbefreiung angegeben ist, muss der Steuerbefreiungsgrund vorhanden sein”
• „Die Summe der Positionsbeträge muss dem Gesamtbetrag entsprechen”
• „Die Bankverbindung muss eine gültige IBAN enthalten”

Was ändert sich durch SchXslt?

Eigenschaft	ISO Schematron	SchXslt
Performance	Standard	Verbessert
Wartbarkeit	Eingeschränkt	Besser strukturiert
Kompatibilität	Breit	Fokus auf aktuelle XSLT-Prozessoren
Community	Stagnierend	Aktiv weiterentwickelt
Validierungsergebnis	Identisch	Identisch

Das Entscheidende: Für korrekte Rechnungen ändert sich am Validierungsergebnis nichts. Die Regeln bleiben identisch — nur die Art, wie sie technisch ausgeführt werden, wird modernisiert. Das ist vergleichbar mit einem Motorwechsel bei einem Auto: Das Fahrerlebnis bleibt gleich, aber unter der Haube arbeitet ein effizienterer Motor.

Diese Umstellung bereitet auch den Weg für XRechnung 4.0, das konsequent auf SchXslt setzen wird.

Neue Peppol-Geschäftsregel PEPPOL-EN16931-R120

Eine neue Validierungsregel für das CII-Format (Cross Industry Invoice) wurde eingeführt:

• Regel: PEPPOL-EN16931-R120
• Format: CII (nicht UBL)
• Aktueller Schweregrad: ⚠️ Warning (Warnung)
• Geplanter Schweregrad: ❌ Fatal (Fehler)

Was bedeutet das?

Aktuell erzeugt ein Verstoß gegen diese Regel nur eine Warnung — die Rechnung wird trotzdem akzeptiert. In einer zukünftigen Version (noch nicht terminiert) wird die Regel auf Fatal hochgestuft. Dann führt ein Verstoß zur Ablehnung der Rechnung im Peppol-Netzwerk.

Unternehmen, die XRechnung im CII-Format über Peppol versenden, sollten die Warnung ernst nehmen und die betroffenen Rechnungsdaten korrigieren. Wer UBL nutzt, ist von dieser Regel nicht betroffen.

Mehr zum Thema Peppol-Kompatibilität: Peppol schaltet alte XRechnung-Versionen ab.

Weitere technische Änderungen

Neben den großen Neuerungen enthält das Bugfix-Release diverse kleinere Korrekturen:

• Aktualisierte Codelisten — Länder-, Währungs- und Steuercodelisten auf dem neuesten Stand
• Korrigierte Validierungsregeln — Einzelne Regeln, die falsch-positive Ergebnisse lieferten, wurden berichtigt
• Aktualisierte Dokumentation — Die technische Dokumentation im Bundle wurde überarbeitet
• Verbesserte Testfälle — Die Testsuite auf GitHub wurde erweitert

Was bedeuten die Änderungen für verschiedene Nutzergruppen?

Nutzergruppe	Auswirkung	Handlungsbedarf
Unternehmen mit E-Rechnungs-Software	Keine spürbare Änderung	Keiner — Software aktualisiert automatisch
Unternehmen ohne Software (manuelle Erstellung)	Validator-Update für korrektes Prüfungsergebnis	Neuen Validator herunterladen
Softwarehersteller	SeMoX-Modelle nutzen, SchXslt-Umstellung beachten	Bundle aktualisieren, Validierung testen
Entwickler / IT-Abteilungen	Java-Version für Validator prüfen	Validator 1.6.0 oder 1.5.0 wählen
Peppol Access Points	Neue Geschäftsregel R120 beachten	Warnung ernst nehmen, auf Fatal vorbereiten
Steuerberater	Keine Änderung im Datenformat	Keiner

Validierung: Warum sie so wichtig ist

Die Validierung ist das Herzstück des XRechnung-Standards. Ohne sie wäre XRechnung nur ein XML-Schema — mit Validierung wird es ein verlässlicher Standard, der Interoperabilität garantiert.

Was passiert bei der Validierung?

Der KoSIT-Validator prüft eine XRechnung in drei Stufen:

1. Schema-Validierung — Ist die XML-Struktur korrekt? Sind alle Pflichtfelder vorhanden?
2. Schematron-Validierung — Erfüllen die Inhalte die Geschäftsregeln? Stimmen die Summen? Sind die Codes gültig?
3. XRechnung-spezifische Prüfung — Erfüllt die Rechnung die deutschen Zusatzanforderungen (CIUS)?

Praxisbeispiele: Wenn die Validierung fehlt

Warum solltest du dich als Unternehmer für die Validierung interessieren? Weil fehlende oder falsche Validierung zu echten Problemen führt:

Beispiel 1: Abgelehnte Rechnung bei der Behörde Ein Handwerksbetrieb stellt eine Rechnung an eine Bundesbehörde über die OZG-RE-Plattform. Die Rechnung wurde mit einer veralteten Software erstellt und enthält eine ungültige Steuercode-Kombination. Ergebnis: Die Rechnung wird abgewiesen. Der Handwerker muss korrigieren und erneut senden — das kostet Zeit und verzögert die Zahlung.

Beispiel 2: Falsche Betragsberechnung bleibt unbemerkt Eine Rechnung enthält einen Rundungsfehler: Die Summe der Positionen weicht um 0,01 € vom Gesamtbetrag ab. Ohne Validierung fällt das nicht auf. Der Empfänger bucht den falschen Betrag, es entsteht eine Differenz in der Buchhaltung, die erst beim Jahresabschluss auffällt.

Beispiel 3: Fehlender Steuerbefreiungsgrund Ein Kleinunternehmer erstellt eine Rechnung ohne Umsatzsteuer, vergisst aber den Steuerbefreiungsgrund (§ 19 UStG). Die Validierung würde das sofort erkennen. Ohne Validierung könnte der Empfänger die Rechnung beanstanden — oder schlimmer, das Finanzamt.

Mehr dazu: E-Rechnung: 10 häufige Fehler und wie du sie vermeidest

Der KoSIT-Validator im Detail

Was ist der KoSIT-Validator?

Der KoSIT-Validator ist ein Open-Source-Tool, das von der Koordinierungsstelle für IT-Standards bereitgestellt wird. Er prüft XML-Dokumente gegen definierte Szenarien — bei XRechnung gegen den aktuellen Standard inklusive aller Geschäftsregeln.

Eigenschaften:

• Open Source — Frei verfügbar auf GitHub
• Java-basiert — Läuft auf jeder Plattform mit Java Runtime
• API-fähig — Kann in eigene Anwendungen integriert werden
• Konfigurations-getrieben — Verschiedene Szenarien (XRechnung, EN 16931, Peppol) konfigurierbar
• Batch-fähig — Kann mehrere Rechnungen in einem Durchlauf prüfen

Wie verwenden E-Rechnungs-Softwarelösungen den Validator?

Die meisten E-Rechnungs-Softwarelösungen — darunter Factora — integrieren den KoSIT-Validator direkt in ihren Erstellungsprozess:

1. Du erstellst eine Rechnung in der Software
2. Die Software erzeugt eine XRechnung-XML-Datei
3. Der Validator prüft die Datei automatisch — bevor du sie versendest
4. Bei Fehlern wirst du informiert und kannst korrigieren
5. Erst nach erfolgreicher Validierung wird die Rechnung freigegeben

So ist sichergestellt, dass jede Rechnung, die dein Unternehmen verlässt, den Standard erfüllt. Du musst dich nicht selbst um die Validierung kümmern.

Validator selbst nutzen

Falls du den Validator selbst betreiben möchtest (z. B. zum Prüfen eingehender Rechnungen):

1. Lade das XRechnung-Bundle von der KoSIT herunter
2. Stelle sicher, dass du Java 11+ (für Validator 1.6.0) oder Java 8+ (für 1.5.0) installiert hast
3. Führe den Validator mit deiner XRechnung-Datei aus
4. Prüfe den Validierungsbericht auf Fehler und Warnungen

Die vollständige Anleitung findest du in der Dokumentation auf GitHub.

Was bedeutet das für dein Unternehmen?

Wenn du eine E-Rechnungs-Software nutzt

Kurz: Nichts. Dein Softwareanbieter aktualisiert den Validator und die Validierungsregeln. Du erstellst Rechnungen wie gewohnt. Stelle lediglich sicher, dass deine Software-Version aktuell ist.

Wenn du den Validator selbst betreibst

1. Validator aktualisieren — Lade das neue Bundle herunter und ersetze die alte Version
2. Java-Version prüfen — Für Validator 1.6.0 brauchst du Java 11+
3. SchXslt-Kompatibilität testen — Wenn du eigene XSLT-Prozessoren nutzt, teste die Kompatibilität
4. R120-Warnung beachten — Wenn du CII über Peppol nutzt, prüfe deine Rechnungen auf die neue Regel

Wenn du Softwarehersteller bist

1. SeMoX-Modelle evaluieren — Die neuen Modelle können deine Implementierung verbessern
2. SchXslt integrieren — Stelle auf die neue Schematron-Implementierung um
3. Validator-Versionen anbieten — Unterstütze sowohl Java-8- als auch Java-11+-Kunden
4. Testsuite aktualisieren — Die aktualisierte Testsuite auf GitHub enthält neue Testfälle

Factora: Immer auf dem neuesten Stand

Factora verwendet den KoSIT-Validator in der aktuellen Version — automatisch, bei jeder Rechnung, ohne dass du etwas tun musst. Das Bugfix-Release Winter 2025/26 ist bereits integriert.

Was das für dich bedeutet:

• Jede Rechnung wird validiert — Fehlererkennung vor dem Versand
• Aktuelle Geschäftsregeln — Inklusive der neuen Peppol-Regel R120
• Kein manuelles Update — Factora aktualisiert den Validator automatisch
• Kein Java-Problem — Die Validierung läuft serverseitig, du brauchst kein Java

Und wenn XRechnung 4.0 kommt, wird auch der neue Validator nahtlos integriert.

→ Kostenlos starten — 5 Rechnungen pro Monat, keine Kreditkarte nötig.

---

Quelle: XRechnung Bugfix Release Winter 2025/26 — xeinkauf.de (veröffentlicht am 31.01.2026, Bundle-Release 05.02.2026)