Leitfaden
KoSIT-Fehlermeldungen lesen und beheben
Der Validator hat abgelehnt — und die Meldung klingt nach Norm, nicht nach Lösung. So lesen Sie den Report, und so beheben Sie die häufigsten Fehler.
Aktualisiert am
Was ist der KoSIT-Validator?
Die KoSIT (Koordinierungsstelle für IT-Standards) pflegt die offizielle Referenzimplementierung, die jede XRechnung gegen die Geschäftsregeln der EN 16931 und der deutschen XRechnung-Spezifikation prüft. normbill betreibt genau diesen Validator — gepinnt auf Version 1.6.2 mit dem XRechnung-3.0.2-Szenario — und führt ihn bei jedem Generate und Validate aus. Er hat das letzte Wort über Konformität.
Wie ist eine KoSIT-Fehlermeldung aufgebaut?
Jede Meldung (ein Schematron-Befund) hat vier Bestandteile:
- Regel-ID — z. B.
BR-DE-15; das Präfix nennt die Regel-Familie (Tabelle unten). - Schweregrad —
errormacht das Dokument nicht konform,warningnicht. - Offizieller Regeltext — englisch und normnah formuliert.
- XPath — die Stelle im XML, nicht in Ihren Ausgangsdaten. Genau diese Lücke schließt der normbill-422-Report: Er nennt stattdessen den Pfad in Ihrem Request-JSON.
| Präfix | Familie | Typische Ursache |
|---|---|---|
BR-DE-* | Deutsche XRechnung-Regeln (CIUS) | Pflichtangaben fehlen: Kontakt, Zahlung, Leitweg-ID |
BR-CO-* | Berechnungen & Bedingungen | Summen passen nicht zusammen, abhängige Felder fehlen |
BR-DEC-* | Dezimalstellen | Mehr als zwei Nachkommastellen in Beträgen |
BR-CL-* | Codelisten | Unzulässiger Code, z. B. type_code 381 in UBL |
BR-S-*, BR-AE-*, … | USt-Kategorien | Steuerkategorie passt nicht zu Sätzen oder Befreiungen |
UBL-SR-*, UBL-CR-* | UBL-Bindung | Struktur des UBL-XML |
XSD | XML-Schema | Das XML entspricht nicht dem Schema |
Alle Familien mit jeder einzelnen Regel — auf Deutsch erklärt — finden Sie in der Regel-Referenz.
Die acht häufigsten Fehler — Ursache und Lösung
| Regel | Was der Validator beanstandet | Lösung im normbill-JSON |
|---|---|---|
BR-DE-15 | Die Käuferreferenz (BT-10) fehlt — bei Behörden die Leitweg-ID. | invoice.buyer_reference setzen; Format im Leitweg-ID-Leitfaden prüfen. |
BR-DE-1 | Zahlungsangaben (BG-16) fehlen — die XRechnung schreibt sie vor. | invoice.payment ergänzen; für eine SEPA-Überweisung genügt die IBAN. |
BR-DE-2 | Kontaktangaben des Verkäufers (BG-6) fehlen. | Ansprechperson oder Abteilung in invoice.seller.contact setzen. |
BR-DE-16 | Weder USt-IdNr. (BT-31) noch Steuernummer (BT-32) vorhanden. | invoice.seller.vat_id (z. B. „DE123456789“) oder seller.tax_number setzen. |
BR-CO-25 | Ein Betrag ist fällig, aber weder Fälligkeitsdatum (BT-9) noch Zahlungsbedingungen (BT-20) sind angegeben. | invoice.due_date oder invoice.payment_terms setzen. |
BR-CO-10 | Die Summe der Positionsnettobeträge (BT-106) passt nicht zu den Rechnungspositionen. | invoice.totals weglassen (normbill rechnet exakt) oder den Betrag korrigieren. |
BR-CO-14 | Die angegebene USt-Summe passt nicht zur berechneten Steueraufschlüsselung. | invoice.totals weglassen oder die Beträge korrigieren. |
BR-CL-01 | type_code 381 (Gutschrift) ist in der UBL-Invoice-Syntax nicht zulässig. | type_code 384 mit negativen Mengen verwenden — oder ein CII-Format (ZUGFeRD, Factur-X), wo 381 gültig ist. |
Zur Leitweg-ID (dem häufigsten Fall) gibt es einen eigenen Leitfaden mit Live-Formatcheck.
Wie behebe ich Fehler am schnellsten?
- Vorhandenes XML prüfen: Der kostenlose Validator liefert denselben KoSIT-Report — mit verständlicher Erklärung und Lösung je Befund, ohne Konto.
- Beim Erzeugen über die API: Schlägt eine Regel fehl, kommt ein 422 mit dem Pfad in Ihrem Request (z. B.
invoice.buyer_reference), der Regel-ID und einem konkreten Korrekturvorschlag; jede Meldung verlinkt ihre Regel-Seite. - Nachschlagen: Jede Regel hat eine eigene Seite unter /docs/rules — mit deutscher Erklärung, dem zugehörigen JSON-Feld und den offiziellen Quellen.