Auf dieser Seite
Die kurze Antwort
BR-CL-10 schlägt fehl, wenn eine cac:PartyIdentification/cbc:ID eine schemeID hat, die kein Code aus der ICD-Liste nach ISO 6523 ist. Ersetzen Sie den Wert durch den vierstelligen ICD-Code des Schemas, das die Kennung vergeben hat: 0088 für eine GLN, nicht GLN.
Die Fundstelle des Befunds nennt die Partei. Im aufgezeichneten Beispiel ist es der Verkäufer, die Kennungen von Käufer und Zahlungsempfänger werden aber auf dieselbe Weise geprüft.
Was die Regel prüft
Die Regel läuft auf jeder cbc:ID innerhalb einer cac:PartyIdentification, die das Attribut schemeID trägt. Ohne das Attribut wird nichts geprüft: Im Versuch bestand die Verkäuferkennung ohne ihre schemeID alle Prüfschritte.
Der Wert muss nach dem Entfernen umgebender Leerzeichen genau einem gelisteten Code entsprechen, und Groß- und Kleinschreibung zählen. Die ICD-Codes in diesem Release reichen von 0002 bis 0248, wobei vier Nummern in diesem Bereich fehlen. 88 schlägt fehl, weil die führenden Nullen Teil des Codes sind.
Eine Ausnahme steht in der Regel selbst: SEPA wird bei den Kennungen von Verkäufer und Zahlungsempfänger akzeptiert, wo es die SEPA-Gläubiger-Identifikationsnummer für Lastschriften kennzeichnet. Im Versuch bestand SEPA beim Verkäufer, sepa beim Verkäufer schlug fehl, und SEPA beim Käufer schlug fehl.
Die Liste für elektronische Adressen ist eine andere Liste. Ihre Codes der Form 99xx sind keine ICD-Codes: Im Versuch schlug 9930 bei der Verkäuferkennung an dieser Regel fehl.
Die Kennung der rechtlichen Registrierung in cac:PartyLegalEntity/cbc:CompanyID wird von einer eigenen Regel, BR-CL-11, gegen dieselbe Liste geprüft. Im Versuch meldete schemeID="GLN" dort BR-CL-11, nicht diese Regel.
| Begriff | Bedeutung | UBL-Element |
|---|---|---|
| BT-29 | Kennung des Verkäufers: Attribut für die Kennung des Schemas | cac:AccountingSupplierParty/cac:Party/cac:PartyIdentification/cbc:ID/@schemeID |
| BT-46 | Kennung des Käufers: Attribut für die Kennung des Schemas | cac:AccountingCustomerParty/cac:Party/cac:PartyIdentification/cbc:ID/@schemeID |
| BT-60 | Kennung des Zahlungsempfängers: Attribut für die Kennung des Schemas | cac:PayeeParty/cac:PartyIdentification/cbc:ID/@schemeID |
Wie es in einer Integration dazu kommt
Mögliche Ursachen, abgeleitet aus der Form der Regel und nicht aus gemessener Nutzung:
- Das Mapping schreibt einen Schemanamen wie
GLNoderDUNSdorthin, wo der ICD-Code erwartet wird. - Der Code läuft durch ein numerisches Feld und verliert seine führenden Nullen.
- Das Schema der elektronischen Adresse wird für die Parteikennung wiederverwendet und bringt einen Code der Form
99xxmit, den nur die Liste der elektronischen Adressen enthält. - Eine SEPA-Gläubiger-Identifikationsnummer wird dem Käufer zugeordnet, wo die Regel das Schema
SEPAnicht akzeptiert. - Eine interne Kunden- oder Lieferantennummer wird mit einer
schemeIDgesendet, die das Quellsystem benennt.
So korrigieren Sie das Dokument
- Ermitteln Sie anhand der Fundstelle des Befunds, welche Parteikennung betroffen ist.
- Stellen Sie fest, welches Schema die Kennung vergeben hat, zum Beispiel GS1 für eine GLN oder ein nationales Handelsregister, und schlagen Sie dessen ICD-Code nach.
- Schreiben Sie diesen Code als Text mit seinen führenden Nullen in
schemeID:schemeID="0088". - Stammt die Kennung aus keinem registrierten Schema, etwa Ihre eigene Kontonummer für den Kunden, senden Sie sie ohne
schemeID. Das Attribut ist bei Parteikennungen optional, und ein Code, der die Kennung nicht beschreibt, führt den Empfänger in die Irre. - Verwenden Sie
SEPAnur für die SEPA-Gläubiger-Identifikationsnummer beim Verkäufer oder Zahlungsempfänger.
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: Die Verkäuferkennung ist mit dem Schemanamen GLN gekennzeichnet
<cac:AccountingSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
<cac:PartyIdentification>
<cbc:ID schemeID="GLN">7300010000001</cbc:ID>
</cac:PartyIdentification>
<!-- party name, address, tax scheme, legal entity and contact omitted from this fragment -->
</cac:Party>
</cac:AccountingSupplierParty>Ausschnitt der korrigierten Rechnung: Die Verkäuferkennung verwendet den ICD-Code 0088
<cac:AccountingSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
<cac:PartyIdentification>
<cbc:ID schemeID="0088">7300010000001</cbc:ID>
</cac:PartyIdentification>
<!-- party name, address, tax scheme, legal entity and contact omitted from this fragment -->
</cac:Party>
</cac:AccountingSupplierParty>Nur die schemeID der Verkäuferkennung unterscheidet sich: GLN in der fehlerhaften Rechnung, 0088 in der korrigierten, mit derselben GLN in beiden. Das fehlerhafte Dokument meldet BR-CL-10 und sonst nichts. Die Peppol-Regel zur Prüfziffer der GLN, PEPPOL-COMMON-R040, erkennt eine GLN nur an schemeID="0088"; daher übersprang sie die Kennung in der fehlerhaften Datei und fand die Prüfziffer in der korrigierten Datei korrekt.
Was der Validator gemeldet hat
- Die fehlerhafte Rechnung meldet BR-CL-10. Das korrigierte Dokument besteht jeden Prüfschritt ohne Befunde.Fehlerhaftes XML herunterladenKorrigiertes XML herunterladen
Aufgezeichnet mit phive 12.1.0 / phive-rules-peppol 4.5.6 / Saxon-HE 12.10, der Engine hinter dem kostenlosen Validator, mit synthetischen Daten. Ein aufgezeichnetes Ergebnis ist ein Regressionsnachweis für diese Dokumente, keine Zertifizierung.
Wo die Regel gilt
- Gutschriften werden auf dieselbe Weise geprüft. Im Versuch meldete
GLNbei der Verkäuferkennung einer Gutschrift alleinBR-CL-10. - Die elektronische Adresse in
cbc:EndpointIDwird stattdessen gegen die EAS-Liste geprüft, vonBR-CL-25undPEPPOL-EN16931-CL008. Eine GLN ist in beiden Listen0088. - Eine Codelisten-Regel aus EN 16931. Maßgeblich ist die Liste, die mit diesem Release der Artefakte festgelegt ist; ein Code, der später in ISO 6523 aufgenommen wird, wird erst akzeptiert, wenn ein neues Release ihn enthält.
- Artikelkennungen sind nicht erfasst. Das Schema einer Standardkennung eines Artikels hat eine eigene Regel,
BR-CL-21.
Verwandte Regeln
- BR-CL-25 prüft das Schema der elektronischen Adresse, das stattdessen die EAS-Liste verwendet
- PEPPOL-COMMON-R040 prüft die GLN selbst, sobald eine Kennung mit 0088 gekennzeichnet ist
- BR-CO-26 verlangt eine Verkäuferkennung und zählt eine mit dem Schema SEPA nicht mit
- BR-CL-21 prüft das Schema einer Standardkennung eines Artikels gegen dieselbe ICD-Liste
- 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-24.
Die offizielle Definition von BR-CL-10 (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.

