Direkter Vergleich
| Punkt | XRechnung 3.0.2 | XRechnung 4.0 |
|---|---|---|
| Status | Produktiver aktueller Stand | 2026 angekündigte nächste Hauptversion |
| Normbasis | Bisherige EN-16931-Generation | EN 16931-1:2026 |
| Validator | KoSIT Validator 1.6.0 im Bundle 2026-01-31 | Finaler produktiver Prüfstand erst mit veröffentlichten Artefakten |
| Empfehlung | Heute produktiv validieren | Vorbereiten, aber Vorabstände nicht als final behandeln |
Quellen: KoSIT / XStandards Einkauf · KoSIT / XStandards Einkauf
Was Entwickler zuerst prüfen sollten
- Semantische Quellfelder statt XML-Pfade als führendes Mapping dokumentieren
- Versionskennung und Regelpaket konfigurierbar halten
- Eigenentwickelte Extensions identifizieren
- Testrechnungen nach Geschäftsfällen statt nur nach Syntax gruppieren
- Fehlercodes und Prüfberichte versionsbezogen speichern
Keine vorschnelle Feld-für-Feld-Liste
Eine seriöse Migrationsliste muss auf der finalen Spezifikation und den technischen Komponenten basieren. Solange diese noch in Arbeit sind, sollte eine Vergleichsseite klar zwischen bestätigten Architekturthemen und späteren Detailänderungen unterscheiden.
Quellen: KoSIT / XStandards Einkauf
Häufige Fragen
Muss ich meine XRechnung-3.0-Schnittstelle sofort umbauen?
Nein. 3.0.2 ist weiterhin der produktive Stand. Sinnvoll ist jetzt eine technische Bestandsaufnahme und eine versionierbare Testarchitektur.
Bleiben UBL und CII relevant?
Die konkrete finale Ausgestaltung ist anhand der veröffentlichten 4.0-Artefakte zu prüfen. Heute sollte das System beide vorhandenen Syntaxpfade sauber getrennt testen können.