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 einer Gesamtbewertung (bestanden oder nicht bestanden) und den verletzten Geschäftsregeln samt Regel-ID und Schweregrad. Prüfe vor dem Versand — mit dem offenen KoSIT-Validator oder direkt bei der Erzeugung.

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)?

So liest du den Prüfbericht

Das Ergebnis ist ein Validierungsbericht. Lies ihn in dieser Reihenfolge:

  1. Gesamtbewertung — bestanden oder nicht bestanden. Die Fortlauf-API gibt sie als pass oder fail zurück.
  2. Verletzte Regeln — je Eintrag mit Regel-ID, Schweregrad (Fehler oder Warnung) und Fundstelle im XML. Regeln der EN 16931 tragen IDs der Form BR-…, die nationalen XRechnung-Regeln BR-DE-…; über die ID findest du die Regel in der jeweiligen Spezifikation.
  3. Warnungen — sie allein lassen eine Rechnung nicht durchfallen.

Die häufigsten Fehler ordnet der nächste Abschnitt.

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. Jede Rechnung wird vor der Ausstellung geprüft; besteht sie nicht, wird sie nicht ausgestellt. Der KoSIT-Validierungsbericht ist dabei kein Zusatz, sondern fällt bei jedem Ausstellungsversuch an: er wird erzeugt, aufbewahrt und ist per API abrufbar — die Operation steht in der offenen API-Referenz. Eine Datei aus einem anderen System prüfst du über POST /validate, ohne dass etwas angelegt wird — siehe XRechnung aus SAP prüfen.

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.