# KoSIT-Validator-Fehlercodes: BR-DE-, BR-CO- und PEPPOL-Regeln erklärt

- Date: 2026-04-29
- Modified: 2026-10-20
- Geprüft: 20. Oktober 2026
- Reading time: 8 Min. Lesezeit

KoSIT-Fehlercodes mit Ursache und Korrektur: PEPPOL-EN16931-R008, BR-DE-19, BR-CO-09, BR-CO-13, BR-S-08, BR-DE-15 und mehr. Geprüft mit XRechnung 3.0.2.

> Geprüft anhand von KoSIT-Validator-Konfiguration, Peppol-BIS-Validierungsregeln.

Ein KoSIT-Bericht nennt jede fehlgeschlagene Regel mit ID, kurzer Meldung und XML-Position. Diese Seite erklärt die Regeln, die in Berichten unseres kostenlosen [XRechnung-Validators](/de/xrechnung-validator) am häufigsten vorkommen, mit typischer Ursache und Korrektur. Jede Regel-ID führt zu einer Seite mit XML-Beispielen.

Beginnen Sie mit dem ersten Fehler im Bericht. Korrigieren Sie das genannte Feld in den Quelldaten, erzeugen Sie die Datei neu und prüfen Sie sie mit derselben Validator-Konfiguration.

## Was ist KoSIT?

KoSIT, die Koordinierungsstelle für IT-Standards, ist die öffentliche Stelle in Deutschland, die den Standard XRechnung herausgibt. Sie veröffentlicht auch den quelloffenen Validator und die XRechnung-Konfiguration, die eine Datei gegen das XML-Schema, die Regeln der EN 16931 und die deutschen BR-DE-Regeln prüfen.

## Die häufigsten KoSIT-Fehler

Die Tabelle ist danach geordnet, wie oft eine Regel bei fehlgeschlagenen Prüfungen in unseren kostenlosen Validatoren vorkommt. Der Schweregrad ist die Stufe in der Validator-Konfiguration, die der nächste Abschnitt nennt.

| Regel | Schweregrad | Bedeutung | Typische Ursache | Korrektur |
| --- | --- | --- | --- | --- |
| [`PEPPOL-EN16931-R008`](/de/resources/kosit-validator-errors/peppol-en16931-r008-document-must-not-contain-empty-elements) | Fehler | Das XML enthält ein Element ohne Text und ohne Unterelemente. | Eine Exportvorlage schreibt jedes Feld, auch ohne Wert in der Quelle, zum Beispiel `<cbc:Note/>`. | Entfernen Sie das Element und die übergeordnete Gruppe, wenn sie danach leer ist. Füllen Sie es nicht mit „-“ oder „n/a“. |
| [`BR-DE-19`](/de/resources/kosit-validator-errors/br-de-19-sepa-payment-account-must-be-valid-iban) | Warnung | Bei Code 58 (SEPA-Überweisung) in BT-81 soll die Kontokennung BT-84 eine gültige IBAN sein. | Ein Tippfehler in der IBAN, eine Beschriftung wie „IBAN:“ im Feld oder eine nationale Kontonummer. | Korrigieren Sie die IBAN in den Stammdaten. Die Prüfziffern müssen die Modulo-97-Prüfung bestehen; Leerzeichen werden ignoriert. |
| [`BR-CO-09`](/de/resources/kosit-validator-errors/br-co-9-vat-identifier-must-have-iso-country-prefix) | Fehler | Die USt-IdNrn. in BT-31, BT-48 und BT-63 müssen mit einem ISO-3166-1-Ländercode beginnen (Griechenland: EL). | Die Nummer wurde ohne Präfix exportiert, oder die Steuernummer steht im Feld der USt-IdNr. | Schreiben Sie die USt-IdNr. mit Präfix, zum Beispiel DE123456789. Die Steuernummer gehört in BT-32. |
| [`BR-CO-13`](/de/resources/kosit-validator-errors/br-co-13-invoice-total-without-vat-must-match-totals-chain) | Fehler | Der Gesamtbetrag ohne Umsatzsteuer (BT-109) muss den Positionsnettobeträgen abzüglich der Nachlässe (BT-107) zuzüglich der Zuschläge (BT-108) auf Dokumentebene entsprechen. | Ein Rabatt oder Zuschlag steckt in der gedruckten Summe, fehlt im XML aber als Nachlass oder Zuschlag auf Dokumentebene. | Berechnen Sie die Summen aus den exportierten Positionen, Nachlässen und Zuschlägen neu, statt die gedruckte Summe zu übernehmen. |
| [`BR-S-08`](/de/resources/kosit-validator-errors/br-s-08-standard-rated-taxable-amount-must-match-lines-charges-allowances) | Fehler | Für jeden Steuersatz der Kategorie S muss die Bemessungsgrundlage (BT-116) den Positionsnettobeträgen zuzüglich Zuschlägen abzüglich Nachlässen zu diesem Satz entsprechen. | Ein Nachlass oder Zuschlag auf Dokumentebene hat den falschen Steuersatz, oder ein Rabatt über mehrere Sätze wurde mit nur einem Satz exportiert. | Gruppieren Sie Positionen, Nachlässe und Zuschläge nach Steuersatz und bilden Sie jede Steueraufschlüsselung (BG-23) daraus neu. |
| [`BR-CO-11`](/de/resources/kosit-validator-errors/br-co-11-sum-of-document-allowances-must-match) | Fehler | Die Summe der Nachlässe auf Dokumentebene (BT-107) muss der Summe aller Nachlassbeträge (BT-92) entsprechen. | Ein Rabatt ist in BT-107 abgezogen, aber nicht als eigener Nachlass (BG-20) exportiert. | Exportieren Sie jeden Rabatt als BG-20 und berechnen Sie BT-107 aus diesen Beträgen. |
| [`BR-DE-27`](/de/resources/kosit-validator-errors/br-de-27-seller-contact-telephone-syntax) | Warnung | Die Telefonnummer des Verkäuferkontakts (BT-42) soll mindestens drei Ziffern enthalten. | Ein Platzhalter wie „--“ oder „N/A“ oder ein Name im Telefonfeld. | Tragen Sie die echte Geschäftsnummer in die Verkäuferstammdaten ein, zum Beispiel +49 30 1234567. |
| [`BR-DE-15`](/de/resources/kosit-validator-errors/br-de-15-buyer-reference-required) | Fehler | Die Käuferreferenz in BT-10 muss vorhanden sein. KoSIT prüft nur, ob sie da ist, nicht das Format der Leitweg-ID. | Die Bestellung nannte keine Referenz, oder der Export lässt BT-10 bei Geschäftskunden leer. | Fragen Sie den Käufer, welche Referenz er erwartet; öffentliche Auftraggeber nennen meist eine Leitweg-ID. Erfinden Sie keine. |
| [`PEPPOL-EN16931-R010`](/de/resources/kosit-validator-errors/peppol-en16931-r010-buyer-electronic-address-required) | Fehler | Die elektronische Adresse des Käufers (BT-49) muss vorhanden sein. | Der Kundenstamm enthält keine E-Rechnungsadresse des Käufers. | Fragen Sie den Käufer nach Adresse und Schema, zum Beispiel Schema 0204 für eine Leitweg-ID oder EM für eine E-Mail-Adresse. |
| [`BR-DE-21`](/de/resources/kosit-validator-errors/br-de-21-specification-identifier-syntax) | Warnung | Die Spezifikationskennung (BT-24) soll die Kennung von XRechnung sein. | Die Datei deklariert ZUGFeRD, Peppol BIS, reine EN 16931 oder eine ältere XRechnung-Version. | Setzen Sie BT-24 auf die Kennung von XRechnung 3.0, oder prüfen Sie die Datei mit einem Validator für das deklarierte Profil. |
| [`CII-SR-465`](/de/resources/kosit-validator-errors/cii-sr-465-seller-contact-person-or-department-name) / [`CII-SR-466`](/de/resources/kosit-validator-errors/cii-sr-466-buyer-contact-person-or-department-name) | Fehler (XRechnung-CII) | In CII ist eine Kontaktstelle (BT-41 Verkäufer, BT-56 Käufer) ein Personen- oder ein Abteilungsname, nicht beides. | Der Export schreibt `ram:PersonName` und `ram:DepartmentName` nebeneinander. Die aktuelle KoSIT-Konfiguration stuft die CEN-Warnung zum Fehler hoch. | Behalten Sie eines der beiden Elemente. UBL ist nicht betroffen. |
| [`BR-FX-EN-04`](/de/resources/kosit-validator-errors/br-fx-en-04-delivery-date-or-service-period) | Warnung (Factur-X) | Factur-X / ZUGFeRD: Eine Rechnung zwischen deutschen Parteien braucht ein Lieferdatum (BT-72), einen Abrechnungszeitraum (BG-14) oder einen Zeitraum an jeder Position (BG-26). | Die Quelle nennt kein Liefer- oder Leistungsdatum, oder nur einen Zeitraum ohne Lieferland (BT-80). | Ergänzen Sie Datum oder Zeitraum aus den Quelldokumenten; bei nur einem Zeitraum auch BT-80. Diese Regel prüft der ZUGFeRD-Validator, nicht KoSIT. |
| [`PEPPOL-EN16931-R020`](/de/resources/kosit-validator-errors/peppol-en16931-r020-seller-electronic-address-required) | Fehler | Die elektronische Adresse des Verkäufers (BT-34) muss vorhanden sein. | Die Verkäuferstammdaten enthalten keine E-Rechnungsadresse. Die Regel trägt einen Peppol-Namen, KoSIT wendet sie aber auf jede XRechnung an. | Tragen Sie die elektronische Adresse des Verkäufers mit Schema ein (BR-62), zum Beispiel eine E-Mail-Adresse mit Schema EM. |
| [`BR-CO-10`](/de/resources/kosit-validator-errors/br-co-10-sum-of-line-net-amounts-must-equal-line-total) | Fehler | Die Summe der Positionsnettobeträge (BT-106) muss der Summe aller Nettobeträge der Positionen (BT-131) entsprechen. | Eine Position, etwa der Versand, steht auf dem PDF, fehlt aber im Export, oder Positionen wurden nach der Summenbildung gerundet. | Berechnen Sie BT-106 aus den exportierten Positionen, mit derselben Rundung wie die Positionen. |
| [`BR-CO-15`](/de/resources/kosit-validator-errors/br-co-15-invoice-total-with-vat-must-match) | Fehler | Der Gesamtbetrag mit Umsatzsteuer (BT-112) muss BT-109 zuzüglich des Umsatzsteuergesamtbetrags (BT-110) entsprechen. | Der Bruttobetrag wurde vom PDF übernommen, Netto oder Steuer aber neu berechnet, sodass ein Rundungscent abweicht. | Berechnen Sie BT-112 als BT-109 + BT-110 aus den exportierten Werten. |
| [`BR-DE-1`](/de/resources/kosit-validator-errors/br-de-1-payment-instructions-required) | Fehler | Die Rechnung muss Zahlungsanweisungen (BG-16) enthalten. | Die Bankverbindung steht auf dem PDF, etwa in der Fußzeile, wird aber nicht exportiert. | Ergänzen Sie BG-16 mit dem Zahlungsartcode (BT-81) und den zugehörigen Konto- oder Mandatsdaten. |
| [`BR-DE-2`](/de/resources/kosit-validator-errors/br-de-2-seller-contact-required) | Fehler | Die Gruppe Verkäuferkontakt (BG-6) muss vorhanden sein; BR-DE-5, BR-DE-6 und BR-DE-7 verlangen dann BT-41, BT-42 und BT-43. | Der Export schreibt die Firmenanschrift, aber keinen Kontaktnamen, keine Telefonnummer und keine E-Mail-Adresse. | Hinterlegen Sie in den Verkäuferstammdaten einen betreuten Kontaktnamen, eine Telefonnummer und eine E-Mail-Adresse. |

KoSIT prüft nur, ob BT-10 vorhanden ist (BR-DE-15). Invoice-Converter.com warnt bei XRechnung im Prüfschritt, wenn eine Leitweg-ID in BT-10 eine falsche Prüfziffer hat; die Datei wird deshalb nicht blockiert. Alle weiteren Regeln finden Sie in der [Übersicht der KoSIT-Fehler](/de/resources/kosit-validator-errors).

## Aus welcher Validator-Version die Regeln stammen

Invoice-Converter.com prüft XRechnung mit dem KoSIT-Validator 1.6.3 und der XRechnung-Konfiguration v2026-08-31: XRechnung 3.0.2 mit den EN-16931-Validierungsartefakten 1.3.16. Eine andere Konfiguration kann andere Regeln oder andere Stufen melden. Vergleichen Sie Berichte daher nur aus derselben Konfiguration.

Bei XRechnung 3.0 muss BT-24 das Profil als `urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0` kennzeichnen. Eine verkürzte oder eine ZUGFeRD-Kennung wählt ein anderes Regelwerk.

Mit den EN-16931-Artefakten 1.3.16 ist BR-CO-25 entfallen. Ein Bericht, der die Regel noch zeigt, stammt aus einer älteren Konfiguration: Ein positiver Zahlbetrag braucht kein Fälligkeitsdatum (BT-9) und keine Zahlungsbedingungen (BT-20) mehr.

Die XRechnungskonfiguration prüft UBL- oder CII-XML. Sie prüft nicht den PDF/A-3-Container einer ZUGFeRD- oder Factur-X-Datei. Verwenden Sie dafür zusätzlich einen Validator für Hybridrechnungen.

## Warnungen sind keine Ablehnungen

Ein KoSIT-Bericht kennt hier zwei wichtige Stufen. Ein Fehler (im Schematron mit „fatal“ markiert) macht die Datei ungültig. Eine Warnung ist eine Empfehlung: Enthält der Bericht keinen Fehler, empfiehlt KoSIT trotzdem, die Datei anzunehmen.

In der Tabelle sind `BR-DE-19`, `BR-DE-27`, `BR-DE-21`, `BR-FX-EN-04` Warnungen. Korrigieren Sie sie, wenn die Daten dahinter falsch sind, etwa bei einer vertippten IBAN. Halten Sie eine sonst gültige Datei nicht allein wegen einer Warnung zurück, und verdecken Sie eine Warnung nicht mit einem Platzhalter.

## Sichere Reihenfolge für die Korrektur

Häufig folgt BR-DE-16: Verwendet die Rechnung die Umsatzsteuerkategorie S, Z, E, AE, K, G, L oder M, braucht sie die Umsatzsteuer-ID des Verkäufers (BT-31), seine Steuernummer (BT-32) oder einen Steuervertreter (BG-11 mit BT-63); bei K oder G akzeptieren BR-IC-02 und BR-G-02 nur BT-31 oder BT-63. Die weiteren BR-DE-Gruppen stehen im [Leitfaden zu den XRechnung-Pflichtfeldern](/de/blog/xrechnung-required-fields-guide).

Invoice-Converter.com erstellt und prüft E-Rechnungsdateien. Es versendet keine Rechnungen und ist kein Peppol-Access-Point.

- Bestätigen Sie die XRechnungsversion in BT-24 und die Validator-Konfiguration.
- Öffnen Sie den ersten Fehler im Bericht und notieren Sie Regel-ID und XML-Position.
- Korrigieren Sie den genannten BT oder die BG in den Quell- oder Stammdaten, nicht nur im erzeugten XML.
- Erzeugen Sie die Rechnung neu und prüfen Sie sie mit derselben Validator-Konfiguration.
- Prüfen Sie Warnungen getrennt. Eine Warnung ist nicht dasselbe wie eine abgelehnte Rechnung.

> **So wird eine E-Rechnung validiert**
>
> Ein Validator prüft eine E-Rechnung in Stufen. Zuerst muss die Datei wohlgeformtes XML sein und zum UBL- oder CII-Schema (XSD) passen. Dann laufen die Geschäftsregeln der EN 16931: BR-Kernregeln, BR-CO-Berechnungen, BR-CL-Codelisten, BR-DEC-Nachkommastellen und Regeln je Umsatzsteuerkategorie wie BR-S. Danach folgen die nationalen oder Netzwerk-Regeln, die BT-24 auswählt: BR-DE für XRechnung, PEPPOL-EN16931 für Peppol BIS Billing. Der Bericht nennt jede verletzte Regel: Ein Fehler bedeutet Ablehnung, nur Warnungen bedeuten weiterhin Annahme.

## FAQ

### Was ist der KoSIT-Validator?

Der KoSIT-Validator ist das quelloffene Prüfwerkzeug der Koordinierungsstelle für IT-Standards. Mit der XRechnung-Konfiguration prüft er eine XRechnung gegen das XML-Schema, die Regeln der EN 16931 und die deutschen BR-DE-Regeln und listet jede fehlgeschlagene Regel in einem Bericht auf.

### Was bedeutet „Document MUST not contain empty elements“?

Das ist die Regel PEPPOL-EN16931-R008: Das Dokument darf keine leeren Elemente enthalten. Die Datei enthält ein XML-Element ohne Text und ohne Unterelemente. Entfernen Sie das Element, statt es mit einem Platzhalter zu füllen.

### Ist eine KoSIT-Warnung eine Ablehnung?

Nein. Nur Fehler machen die Datei ungültig. Warnungen wie BR-DE-19, BR-DE-27 oder BR-DE-21 sind Empfehlungen; korrigieren Sie sie, wenn die Daten dahinter falsch sind.

### Warum scheitert meine CII-Datei jetzt an CII-SR-465?

Seit der KoSIT-Konfiguration vom 31. August 2026 sind CII-SR-465 und CII-SR-466 für XRechnung in CII-Syntax Fehler. Ein Kontakt mit Personen- und Abteilungsname scheitert; behalten Sie eine der beiden Angaben.

### Prüft KoSIT ZUGFeRD-PDF/A-3?

Nein. Die XRechnungskonfiguration prüft UBL- oder CII-XML. Eine ZUGFeRD- oder Factur-X-Datei braucht zusätzlich Prüfungen für den PDF/A-3-Container, das eingebettete XML, die Metadaten und die inhaltliche Übereinstimmung von PDF und XML.

## Offizielle Quellen

- [KoSIT-Validator-Konfiguration](https://github.com/itplr-kosit/validator-configuration-xrechnung)
- [Peppol-BIS-Validierungsregeln](https://docs.peppol.eu/poacc/billing/3.0/rules/)