KoSIT-Validator online: XRechnung im Browser validieren ohne Installation
Vor dem Versand jeder XRechnung gehört eine KoSIT-Validierung, die offiziellen Schematron-Regeln, die der Bund anerkennt. Die Java-Variante ist umständlich, online geht es in Sekunden. Was die KoSIT genau prüft, welche Online-Validatoren funktionieren und wie du die häufigsten Ablehnungsgründe selbst behebst, steht hier.
Der KoSIT-Validator prüft, ob eine XML-Datei eine gültige XRechnung ist, in drei Schichten: XSD-Schema, EN16931-Schematron, deutsche CIUS-Verschärfungen. Der offizielle Validator ist eine Java-Anwendung; Browser-Tools wie der von Vera fahren dieselben Regelsätze serverseitig ohne lokale Installation. Validierung vor dem Versand fängt 95 % der Empfänger-Ablehnungen ab, ein 30-Sekunden-Schritt mit erheblicher Wirkung.
Was der KoSIT-Validator ist
KoSIT steht für Koordinierungsstelle für IT-Standards, die Stelle beim Senator für Finanzen in Bremen, die im Auftrag des IT-Planungsrats den XRechnung-Standard pflegt. Sie veröffentlicht zwei Dinge:
- Die XRechnung-Spezifikation: was eine gültige deutsche E-Rechnung enthalten muss. Aktuell Version 3.x.
- Den KoSIT-Validator: eine Java-Anwendung mit den dazugehörigen Schematron-Regelsätzen, die jede XML-Datei gegen diese Spezifikation prüft. Open Source, frei verfügbar.
Der Original-Validator wird als Kommandozeilen-Tool ausgeliefert. Für die meisten Endanwender ist das umständlich. Java muss installiert sein, Regelsätze müssen aktuell sein, Config-Files müssen korrekt zeigen. Browser-basierte Lösungen wie der Vera-Validator führen dieselben Schematron-Regelsätze serverseitig aus. Inhaltlich identisches Validierungs-Ergebnis, ohne Java-Installation.
Was er konkret prüft
Drei aufeinander aufbauende Schichten:
| Schicht | Was geprüft wird | Fehler-Beispiel |
|---|---|---|
| XSD-Schema | Ist das XML strukturell korrekt: richtige Elemente, korrekte Datentypen, gültige Verschachtelung. | <cbc:IssueDate>heute</cbc:IssueDate>, Datum kein gültiges ISO-Format. |
| EN16931-Schematron | Geschäftsregeln der europäischen Norm: Pflichtfelder, Rechen-Konsistenz, Codeliste-Konformität. | Brutto-Betrag der Rechnung weicht von Summe der Positionen ab, typischer Rundungs-Bug. |
| XRechnung-CIUS | Deutsche Verschärfungen: Leitweg-ID-Format und Prüfziffer, BT-10 Pflicht, USt-IdNr-Validierung. | Leitweg-ID 991-12345-XX, Prüfziffer-Validierung schlägt fehl. |
Die Schichten werden in der Reihenfolge XSD → EN16931 → XRechnung-CIUS abgearbeitet. Wenn die XSD-Validierung scheitert, bricht der Validator dort ab. Schematron-Regeln werden erst geprüft, wenn das XML strukturell sauber ist.
Online vs. lokale Installation
Wann welche Option sinnvoll ist:
| Browser-Validator (z. B. Vera) | Lokaler KoSIT-Validator (Java) | |
|---|---|---|
| Setup | Keine Installation | Java 11+, JAR-Datei, Config-Files, Regelsatz-Downloads |
| Aktualisierung der Regelsätze | Anbieter pflegt nach | Manuell, du musst Versionen tracken |
| Vertraulichkeit | Datei wird zum Server geschickt (Anbieter lesen) | Bleibt lokal |
| Batch-Verarbeitung | Begrenzt | Beliebige Skript-Integration |
| Geeignet für | Einzelne Rechnungen, Ad-hoc, Mittelstand | ERP-Integration, große Volumina, Daten-sensible Branchen |
Faustregel: bis 50 Rechnungen pro Monat reicht ein Browser-Validator vollständig. Bei höherem Volumen oder bei Branchen mit strikten Datenschutz-Anforderungen (Healthcare, Verteidigung, Energieversorger) macht die lokale Installation Sinn, die Validierung kann dann auch in den eigenen Build-Workflow integriert werden.
In 30 Sekunden: XRechnung validieren
Bei einem Browser-Tool wie Vera:
- XML-Datei auswählen oder per Drag & Drop in das Validator-Fenster ziehen.
- „Validieren" klicken. Verarbeitung läuft serverseitig, dauert in der Regel 1–3 Sekunden.
- Report lesen: grüner Haken = bestanden, rote Markierung = Schematron-Verstoß mit konkreter Regel-ID (z. B.
BR-CO-15) und betroffenem Feld. - Bei Fehler: Datei im XRechnung-Generator korrigieren und erneut validieren.
Beim lokalen Validator dieselbe Logik, nur über Kommandozeile:
Die fünf häufigsten Fehlertypen
1. Rechen-Inkonsistenz (Schematron BR-CO-10 / BR-CO-15)
Summe der Rechnungspositionen plus Steuer ergibt nicht das Brutto-Total. Häufigste Ursache: dein System rundet Einzelpositionen anders als die Norm vorsieht. EN16931 verlangt zwei Nachkommastellen für Beträge und mathematisch konsistente Aufrechnung. Wenn dein ERP intern mit vier Stellen rechnet und erst am Ende rundet, entsteht eine 1-Cent-Differenz.
2. Ungültige Leitweg-ID
Format weicht ab oder Prüfziffer falsch berechnet. Schematron-Regel BR-DE-1. Mehr zur Leitweg-ID und ihrer MOD-11-10-Prüfziffer.
3. Fehlende Käuferreferenz (BT-10)
In XRechnung Pflichtfeld. Bei B2G die Leitweg-ID, bei B2B jeder andere vereinbarte Identifikator. Wenn das Feld leer bleibt, scheitert die Validierung an Regel BR-DE-15.
4. Ungültiger Tax-Category-Code
EN16931 erlaubt nur die Codes S (Standard), Z (Zero), E (Exempt), AE (Reverse Charge), K (intra-EU), G (Export). Tools die "19%" oder "steuerfrei" als Code schreiben, scheitern hier.
5. Datumsformat falsch
EN16931 verlangt ISO 8601 (2026-05-28 bei UBL, 20260528 bei CII mit Format-Code 102). Deutsche Schreibweise 28.05.2026 ist im XML niemals zulässig.
Validierungs-Reports lesen
Ein Report enthält für jeden Verstoß: Schematron-Regel-ID, Fehler-Schweregrad, betroffenes XML-Element (XPath), und eine kurze Erklärung. Beispiel:
Die Regel-IDs sind standardisiert. BR-CO-* sind EN16931-Geschäftsregeln (CEN/OPS Codes), BR-DE-* die deutschen XRechnung-CIUS-Verschärfungen, BR-S-* die schematron-spezifischen Regeln. Bei wiederholtem Auftreten derselben Regel-ID lohnt sich ein Blick in die Schematron-Datei direkt. Dort steht der genaue Trigger-Ausdruck.
Häufige Fragen
Was ist der KoSIT-Validator?
Ein offizielles Prüf-Werkzeug der Koordinierungsstelle für IT-Standards (KoSIT, angesiedelt beim Senator für Finanzen Bremen). Er prüft, ob eine XML-Datei den Anforderungen der XRechnung-Spezifikation und der EN16931 entspricht. Der Original-Validator ist eine Java-Anwendung. Browser-Varianten wie Vera fahren dieselben Regelsätze ohne lokale Installation.
Was prüft der Validator konkret?
Drei Schichten: XSD-Schema-Validierung (ist das XML strukturell korrekt), EN16931-Schematron-Regeln (Geschäftsregeln der europäischen Norm), und XRechnung-CIUS-Regeln (deutsche Verschärfungen wie Leitweg-ID-Format, Pflicht-Käuferreferenz, USt-IdNr-Prüfung).
Brauche ich Java installiert, um den KoSIT-Validator zu nutzen?
Beim Original-Validator von KoSIT ja, er ist eine Java-Anwendung. Online-Varianten wie der Vera-Validator führen die identischen Schematron-Regelsätze serverseitig aus, ohne dass du etwas installieren musst. Inhaltlich ergibt sich dasselbe Validierungs-Ergebnis.
Welche Fehler werden am häufigsten gefunden?
Drei Top-Klassen: Rechen-Inkonsistenz (Summe der Positionen passt nicht zum Brutto-Betrag um 1 Cent, klassischer Rundungs-Bug), ungültige Leitweg-ID (Prüfziffer falsch oder Format weicht ab), und fehlende oder leere Pflichtfelder (Käuferreferenz BT-10, USt-Schlüssel-Codes, Datumsformat).
Reicht eine erfolgreiche Validierung als Garantie, dass die XRechnung akzeptiert wird?
Fast, aber nicht hundertprozentig. Validierung prüft technisch-formale Korrektheit. Inhaltliche Fragen (ist der Leistungsbeschreibungstext angemessen, sind Bestellnummern aktuell, ist der Empfänger noch zuständig) erkennt sie nicht. Eine erfolgreich validierte XRechnung wird in über 95 % der Fälle vom Empfänger angenommen.
XRechnung jetzt gegen die KoSIT-Engine prüfen
Leg deine XML oder dein Factur-X/ZUGFeRD-PDF im Vera-Validator ab. Geprüft wird gegen die offizielle KoSIT-Engine: XRechnung, Peppol BIS, Factur-X, CIUS-RO, CIUS-PT, HR-CIUS. Fehler im Klartext, in Sekunden.
Validator öffnenKostenlos · keine Java-Installation · kein Login · nichts wird gespeichert