BR-CL-01: Einen zulässigen Dokumenttypcode verwenden

Die kurze Antwort

BR-CL-01 schlägt fehl, wenn der Dokumenttypcode nicht in der Teilmenge von UNTDID 1001 liegt, die EN 16931 für diese Dokumentart zulässt. Senden Sie den Code, der beschreibt, was das Dokument ist: 380 für eine Handelsrechnung in cbc:InvoiceTypeCode, 381 für eine Gutschrift in cbc:CreditNoteTypeCode oder einen anderen gelisteten Code, wo er tatsächlich zutrifft.

Es gibt zwei Listen, eine je Element. Ein Code aus der Liste für Gutschriften in einer Invoice, oder umgekehrt, schlägt fehl, obwohl der Code selbst ein echter Wert aus UNTDID 1001 ist.

Was die Regel prüft

Die Regel läuft auf cbc:InvoiceTypeCode und auf cbc:CreditNoteTypeCode und prüft jedes gegen seine eigene Liste: Rechnungstypcodes für das erste, Gutschriftstypcodes für das zweite. 381 in einer Invoice schlägt fehl, ebenso 380 in einer CreditNote.

Leerraum um den Wert wird ignoriert; ein mit Leerzeichen aufgefülltes 380 besteht. Ansonsten ist der Vergleich exakt und gilt einem einzigen Code, daher schlagen 0380 und 380 380 fehl.

Ein leeres Element schlägt bei dieser Regel fehl und wird außerdem von BR-04, von der Peppol-Regel für den Typcode und von PEPPOL-EN16931-R008 gemeldet. Ein Dokument ganz ohne Typcode-Element erreicht diese Regel nicht: UBL macht das Element optional, daher besteht der XSD-Prüfschritt, und BR-04 meldet den fehlenden Code.

Peppol schränkt die Auswahl weiter ein. PEPPOL-EN16931-P0100 für Rechnungen und PEPPOL-EN16931-P0101 für Gutschriften akzeptieren nur einen Teil der Liste von EN 16931, sodass ein Code BR-CL-01 bestehen und trotzdem im Peppol-Prüfschritt scheitern kann: 130 und 202 tun das in einer Invoice, 261 in einer CreditNote. Umgekehrt scheitern 999, 0380 und eine in eine Invoice gesetzte 381 in beiden Prüfschritten.

Wie es in einer Integration dazu kommt

Mögliche Ursachen, abgeleitet aus der Form der Regel und nicht aus gemessener Nutzung:

• Ein interner Dokumenttyp, etwa INV, 1 oder ein Buchungscode, wird ohne Übersetzung in das Element geschrieben.
• Das Quellsystem bildet Gutschriften als Rechnungen mit anderem Typ ab, und das Mapping setzt 381 in ein Wurzelelement Invoice.
• Der Code wurde aus der vollständigen Liste UNTDID 1001 genommen, die auch Bestellungen, Lieferavise und andere Dokumente umfasst, die keine Rechnungen sind, zum Beispiel 220.
• Der Wert wird als Zahl mit Auffüllung formatiert, was 0380 ergibt.
• Ein Standardwert wurde nie gesetzt, und der Builder erzeugt ein leeres Element.

So korrigieren Sie das Dokument

1. Legen Sie zuerst fachlich fest, was das Dokument ist: Rechnung, Gutschrift, korrigierte Rechnung, Vorauszahlungsrechnung und so weiter. Der Code folgt daraus; er ist keine freie Wahl.
2. Übersetzen Sie den internen Typ über eine explizite Tabelle in einen Code, und beschränken Sie die Tabelle auf Codes, die sowohl BR-CL-01 als auch die Peppol-Regel für das gesendete Wurzelelement bestehen.
3. Ist das Dokument eine Gutschrift, erstellen Sie eine CreditNote mit cbc:CreditNoteTypeCode. Das ist ein anderes Wurzelelement mit eigenen Namen für Positionen und Mengen, kein innerhalb einer Invoice ausgetauschter Code. Kennzeichnen Sie eine Gutschrift nicht als 380 um, nur um den Fehler zu beseitigen.
4. Geben Sie den Code als einfachen String ohne Auffüllung und ohne führende Nullen aus.

Korrigierte Rechnung prüfen

Vorher und nachher

Dies sind Ausschnitte, keine vollständigen Dokumente. Die vollständigen synthetischen Dokumente, aus denen sie stammen, sind unten verlinkt.

Ausschnitt der fehlerhaften Rechnung: 999 ist kein Rechnungstypcode aus UNTDID 1001

<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<cbc:DueDate>2026-10-08</cbc:DueDate>
<cbc:InvoiceTypeCode>999</cbc:InvoiceTypeCode>
<cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>

Ausschnitt der korrigierten Rechnung: 380, Handelsrechnung

<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<cbc:DueDate>2026-10-08</cbc:DueDate>
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>

Nur cbc:InvoiceTypeCode unterscheidet sich: 999 in der fehlerhaften Datei, 380 in der korrigierten. Das fehlerhafte Dokument meldet außerdem PEPPOL-EN16931-P0100, die Peppol-Einschränkung für Rechnungstypcodes: Peppol erlaubt weniger Codes als EN 16931, und 999 steht auf keiner der beiden Listen. Jeder Prüfschritt meldet einen Befund zum selben Element, und ein Code, den Peppol akzeptiert, behebt beide.

Wo die Regel gilt

• Gilt für UBL Invoice über cbc:InvoiceTypeCode und für CreditNote über cbc:CreditNoteTypeCode, mit einer eigenen Liste für jedes. Eine CreditNote mit 999 oder 380 meldet BR-CL-01 zusammen mit PEPPOL-EN16931-P0101.
• Einige Codes unterliegen über die beiden Listen hinaus weiteren Peppol-Bedingungen. 384 auf der britischen Testrechnung besteht BR-CL-01 und PEPPOL-EN16931-P0100 und meldet PEPPOL-EN16931-P0112.
• Die Listen sind die in den Artefakten EN 16931 1.3.16 und Peppol BIS Billing 3.0.21 festgelegten. Prüfen Sie die Peppol-Codeliste für das Release, auf das Sie abzielen, statt sich auf die weiter gefasste Liste von EN 16931 zu verlassen.

Verwandte Regeln

• BR-CL-04 ist die Codelistenprüfung für die Dokumentwährung, das nächste Kopfelement
• BR-CL-23 prüft Einheitencodes von Mengen gegen ihre Codeliste
• BR-02 verlangt die Rechnungsnummer, ein weiteres Pflichtfeld im Kopf
• Alle Regeln der Referenz ansehen
• Hintergrund (auf Englisch): Understanding EN 16931 validation errors

Umfang und Quelle

Geschrieben für Peppol BIS Billing 3.0.21 (May 2026), EN 16931 1.3.16, angewendet auf Invoice- und CreditNote-Dokumente in UBL 2.1. Andere Profile, Syntaxen und Releases können diese Kennung anders definieren. Version des Hinweiskatalogs 2026-09-24.1: Quelle geprüft am 2026-09-24, Erklärung zuletzt aktualisiert am 2026-09-20.

Die offizielle Definition von BR-CL-01 (auf Englisch) enthält den normativen Wortlaut und den Test. Diese Seite ist unsere Erklärung dazu, keine Kopie.

Die Erklärung ändert das Urteil der Engine nicht. Dass Sie diesen Befund beheben, heißt nicht, dass das Dokument jeden Prüfschritt besteht. Die Validierung bescheinigt keine rechtliche oder steuerliche Konformität und überträgt kein Dokument über Peppol.