Auf dieser Seite
Die kurze Antwort
BR-CL-25 schlägt fehl, wenn eine cbc:EndpointID eine schemeID hat, die nicht in der EAS-Codeliste steht, die mit den Validierungsartefakten ausgeliefert wird. Ersetzen Sie sie durch den EAS-Code des Schemas, unter dem die Kennung tatsächlich vergeben wurde, zum Beispiel 0088 für eine GLN.
Die Meldung sagt nicht, welche Partei betroffen ist. Prüfen Sie die schemeID an der cbc:EndpointID sowohl des Verkäufers als auch des Käufers.
Was die Regel prüft
Die Regel läuft auf jeder cbc:EndpointID im Dokument, die ein Attribut schemeID hat. Unter Peppol sind das die Adressen von Verkäufer und Käufer; eine cbc:EndpointID an einer anderen Partei würde ebenfalls geprüft. Ein Element ohne das Attribut wird hier übersprungen und von BR-62 oder BR-63 gemeldet.
Führender und nachgestellter Leerraum wird ignoriert, und der Rest muss genau ein Code aus der Liste sein. Der Abgleich unterscheidet Groß- und Kleinschreibung, daher schlägt em fehl, wo EM ein gelisteter Code ist. Ein leeres Attribut, schemeID="", schlägt fehl.
Geprüft wird nur der Code des Schemas. Ob die Kennung zum Schema passt, ist eine eigene Frage: Peppol prüft das Format des Werts für einige Schemata, und eine Kennung mit 0088 und falscher Prüfziffer meldet PEPPOL-COMMON-R040.
Peppol prüft dasselbe Attribut in PEPPOL-EN16931-CL008 gegen eine eigene Liste, und diese Prüfung ist die strengere der beiden. schemeID=" 0088 " besteht BR-CL-25 und schlägt an PEPPOL-EN16931-CL008 fehl; ebenso EM, das auf der Liste von EN 16931 steht und von der Peppol-Regel in diesem Release nicht akzeptiert wird.
| Begriff | Bedeutung | UBL-Element |
|---|---|---|
| BT-34 | Elektronische Adresse des Verkäufers: Attribut für die Kennung des Schemas | cac:AccountingSupplierParty/cac:Party/cbc:EndpointID/@schemeID |
| BT-49 | Elektronische Adresse des Käufers: Attribut für die Kennung des Schemas | cac:AccountingCustomerParty/cac:Party/cbc:EndpointID/@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 den Namen des Schemas, etwa
GLN, wo der vierstellige Code erwartet wird. - Der Code hat auf dem Weg durch eine numerische Spalte oder eine Tabellenkalkulation seine führenden Nullen verloren, sodass aus
0088der Wert88wurde. - Ein interner Kennungstyp aus dem Quellsystem wird unverändert durchgereicht.
- Die Schemaspalte ist leer, und der Serialisierer schreibt das Attribut trotzdem, was
schemeID=""ergibt. - Der Wert stammt aus einer anderen Codeliste. ICD-Codes nach ISO 6523, die für
cac:PartyIdentificationundcac:PartyLegalEntityverwendet werden, überschneiden sich nur teilweise mit EAS.
So korrigieren Sie das Dokument
- Ermitteln Sie, zu welcher Partei der Befund gehört, indem Sie die
schemeIDan jedercbc:EndpointIDlesen. - Bestimmen Sie das Schema der gespeicherten Kennung und schlagen Sie seinen EAS-Code nach. Hat die Kennung kein EAS-Schema, kann sie nicht als elektronische Adresse dienen; beschaffen Sie bei der betreffenden Partei eine Kennung, die eines hat.
- Speichern Sie den Code als Text, vier Zeichen mit allen führenden Nullen, und schreiben Sie ihn ohne Auffüllung in
schemeID. - Setzen Sie nicht einfach einen gelisteten Code ein, nur weil er besteht. Ein Code, der die Kennung nicht beschreibt, ergibt eine Adresse, die ins Leere oder zu jemand anderem führt.
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: XXXX ist kein EAS-Code
<cac:AccountingSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID="XXXX">7300010000001</cbc:EndpointID>
<!-- postal address, tax scheme and legal entity omitted from this fragment -->
</cac:Party>
</cac:AccountingSupplierParty>Ausschnitt der korrigierten Rechnung: 0088 ist der EAS-Code für eine GLN
<cac:AccountingSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
<!-- postal address, tax scheme and legal entity omitted from this fragment -->
</cac:Party>
</cac:AccountingSupplierParty>Nur die schemeID an der cbc:EndpointID des Verkäufers unterscheidet sich: XXXX in der fehlerhaften Datei, 0088 in der korrigierten. Das fehlerhafte Dokument meldet außerdem PEPPOL-EN16931-CL008, weil Peppol dasselbe Attribut gegen seine eigene Liste von Schemata für elektronische Adressen prüft und XXXX auf keiner der beiden steht. Die Korrektur des Codes behebt beide Befunde.
Was der Validator gemeldet hat
- Die fehlerhafte Rechnung meldet BR-CL-25 und PEPPOL-EN16931-CL008. 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
- Gilt für UBL
InvoiceundCreditNote. Eine Gutschrift mit einem unbekannten Schema an der Adresse des Käufers meldet dasselbe Befundpaar. - Maßgeblich ist die Liste, die in den Artefakten zu EN 16931 1.3.16 festgelegt ist. EAS wird von Zeit zu Zeit überarbeitet, sodass ein an der Quelle hinzugefügter oder zurückgezogener Code hier erst mit einem neuen Release der Artefakte wirksam wird.
- Ein gelistetes Schema und eine wohlgeformte Kennung beschreiben eine Adresse; sie zeigen nicht, dass unter ihr jemand registriert ist. Der Validator fragt das Peppol-Netzwerk nicht ab, daher muss die Erreichbarkeit gesondert bestätigt werden.
Verwandte Regeln
- BR-62 meldet eine EndpointID des Verkäufers ohne Attribut schemeID
- BR-63 meldet eine EndpointID des Käufers ohne Attribut schemeID
- PEPPOL-EN16931-R020 verlangt, dass die EndpointID des Verkäufers vorhanden ist
- PEPPOL-EN16931-R010 verlangt, dass die EndpointID des Käufers vorhanden ist
- 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-25 (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.

