Die KoSIT-Validierung prüft eine E-Rechnung gegen die offiziellen Prüfregeln der Koordinierungsstelle für IT-Standards (KoSIT) — die Umsetzung der EN 16931 und des jeweiligen Profils (XRechnung, ZUGFeRD). Das Ergebnis ist ein Bericht mit den Verdikten passed, warning oder failed und den verletzten Geschäftsregeln.

Wer E-Rechnungen erzeugt, stößt früher oder später auf den Begriff KoSIT-Validierung. Dieser Beitrag erklärt, was dahintersteckt, welche Klassen von Fehlern der Validator meldet und wie du sie strukturell vermeidest, statt sie hinterher zu reparieren.

Wer oder was ist KoSIT?

Die Koordinierungsstelle für IT-Standards (KoSIT) pflegt im Auftrag des IT-Planungsrats den Standard XRechnung und stellt einen offenen Validator bereit. Dieser Validator ist die Referenz dafür, ob ein Beleg die EN 16931 und das jeweilige nationale Profil technisch erfüllt. Er prüft in zwei Ebenen:

  • Schema-Prüfung — ist das XML strukturell korrekt aufgebaut (UBL bzw. CII)?
  • Schematron-/Geschäftsregeln — sind die inhaltlichen Regeln der EN 16931 und des Profils eingehalten (z. B. Summenkonsistenz, gültige Codelisten, Pflichtfelder)?

Das Ergebnis ist ein Validierungsbericht mit einem Verdikt — typischerweise passed, warning oder failed — und einer Liste der verletzten Regeln mit Regel-ID und Fundstelle.

Typische Fehlerklassen

Die meisten Validierungsfehler fallen in wenige Kategorien:

  • Summen-Inkonsistenz — Positionssummen, Netto, Steuer und Brutto passen nicht exakt zusammen (oft ein Rundungsproblem aus Float-Arithmetik).
  • Falsche oder fehlende Codes — Einheiten (UN/ECE Rec 20), Steuerkategorien, Ländercodes, Rechnungstyp-Codes stimmen nicht mit den Codelisten überein.
  • Fehlende Pflichtangaben — je nach Profil etwa Käuferreferenz/Leitweg-ID, elektronische Adresse des Empfängers, Steuernummer/USt-IdNr.
  • Profil-/Versionskonflikte — der Beleg deklariert ein Profil, dessen Regeln er nicht vollständig erfüllt.

Der beste Zeitpunkt zu validieren: vor dem Versand

Ein Empfänger, dessen Eingangssystem streng validiert, lehnt einen fehlerhaften Beleg ab — im schlechtesten Fall erst nach Tagen. Deshalb ist die Validierung vor dem Versand die übliche Absicherung, idealerweise als Trockenlauf, der noch keine Rechnungsnummer verbraucht und den Entwurf nicht verändert.

Fehler vermeiden statt reparieren

Der wirksamste Hebel liegt vor der Validierung: Wie entsteht der Beleg? Wird die Rechnung aus einem sauberen EN-16931-Datenmodell erzeugt — mit Berechnung in ganzzahligen Minor-Units, Beträgen als DECIMAL-Strings und geführten Codelisten — fallen die häufigsten Regelverstöße gar nicht erst an. Ein PDF-zu-XML-Konverter, der Felder aus einem Layout errät, produziert dagegen genau die Inkonsistenzen, die der Validator anschließend anmahnt.

Genau hier setzt die strukturierte Erzeugung an: Fortlauf baut XRechnung und ZUGFeRD/Factur-X aus einem konsistenten Datenmodell — siehe ZUGFeRD 2.x / Factur-X per API erzeugen und die Einordnung der E-Rechnung per API. Der KoSIT-Validierungsbericht ist dabei kein Zusatz, sondern fällt bei jeder Ausstellung an: er wird erzeugt, aufbewahrt und ist per API abrufbar — die Operation steht in der offenen API-Referenz. Den aktuellen Stand siehst du im Bereich für Entwickler.

Selbst ausprobieren? Der Zugang ist kostenlos und ohne Karte — Produkt-Einstieg für Entwickler →

Oder den eigenen Abrechnungsfluss konkret durchsprechen: 30 Min, technisch, mit dem Gründer →

Häufige Fragen

Was ist die KoSIT-Validierung?
Die Koordinierungsstelle für IT-Standards (KoSIT) pflegt die technischen Prüfregeln für XRechnung und stellt einen offenen Validator bereit. Er prüft eine Rechnung gegen die Schema- und Schematron-Regeln der EN 16931 und des nationalen Profils und meldet Verstöße pro Geschäftsregel.
Muss jede E-Rechnung KoSIT-validiert sein?
Die Validierung ist keine gesetzliche Pflicht pro Beleg, aber der De-facto-Standard, um EN-16931-Konformität nachzuweisen. Empfänger und Prüfsysteme lehnen fehlerhafte Belege ab, deshalb ist eine Validierung vor dem Versand die übliche Absicherung.
Wie vermeide ich Validierungsfehler?
Indem die Rechnung aus einem sauberen EN-16931-Datenmodell entsteht statt aus einem PDF-zu-XML-Konverter: korrekte Codelisten, konsistente Summen und Steueraufschlüsselung, vollständige Pflichtfelder wie Leitweg- oder Käuferreferenz, wo verlangt. Wird strukturiert erzeugt, fallen die meisten Regelverstöße gar nicht erst an.