Auf dieser Seite
Die kurze Antwort
BR-10 schlägt fehl, wenn es innerhalb von cac:AccountingCustomerParty/cac:Party keine cac:PostalAddress gibt. Fügen Sie dort die Postanschrift des Kunden ein, dem Sie die Rechnung stellen, einschließlich cac:Country/cbc:IdentificationCode.
Eine Lieferanschrift erfüllt die Regel nicht. Die Versandanschrift gehört unter cac:Delivery, und die Regel liest nur die Partei des Käufers.
Was die Regel prüft
Dies ist eine Vorhandenseinsprüfung für ein einziges Element: cac:PostalAddress als direktes Kindelement der cac:Party des Käufers. Den Inhalt der Anschrift liest die Regel nicht.
Eine Anschriftengruppe ohne Kindelemente besteht BR-10. Im Versuch wurde <cac:PostalAddress/> in der Partei des Käufers stattdessen von BR-11 gemeldet, wegen des fehlenden Ländercodes, und von PEPPOL-EN16931-R008, wegen des leeren Elements.
Die kleinste Anschrift des Käufers, die alle Prüfschritte besteht, enthält nur den Ländercode: Im Versuch ergab eine cac:PostalAddress des Käufers mit nur cac:Country/cbc:IdentificationCode keine Befunde.
Die Regel wird gegen das Dokument als Ganzes ausgewertet, daher ist der Ort des Befunds das Wurzelelement und nicht die Partei des Käufers.
| Begriff | Bedeutung | UBL-Element |
|---|---|---|
| BG-8 | Postanschrift des Käufers | cac:AccountingCustomerParty/cac:Party/cac:PostalAddress |
| BT-55 | Ländercode des Käufers | cac:AccountingCustomerParty/cac:Party/cac:PostalAddress/cac:Country/cbc:IdentificationCode |
Wie es in einer Integration dazu kommt
Mögliche Ursachen, abgeleitet aus der Form der Regel und nicht aus gemessener Nutzung:
- Kunden, die für die elektronische Rechnungsstellung eingerichtet wurden, wurden nur mit Name und elektronischer Adresse angelegt, und die Anschriftenfelder wurden nie ausgefüllt.
- Die einzige Anschrift im Auftrag ist die Lieferanschrift, und das Mapping schreibt sie in
cac:Deliveryund lässt die Partei des Käufers ohne Anschrift. - Der Builder überspringt den Anschriftenblock, sobald die Straße leer ist, auch wenn Ort und Land bekannt sind.
- Die Angaben zum Käufer stammen aus einer Kundenreferenz im Auftrag, die Kennungen enthält, aber keine Anschrift.
So korrigieren Sie das Dokument
- Lesen Sie die Postanschrift des Käufers aus dem Kundenstammsatz: der Partei, der die Rechnung gestellt wird, nicht dem Lieferort.
- Geben Sie sie als
cac:PostalAddressinnerhalb voncac:AccountingCustomerParty/cac:Partyaus, nach einem etwaigencac:PartyNameund vorcac:PartyTaxSchemeundcac:PartyLegalEntity. - Schließen Sie die Anschrift mit
cac:Country/cbc:IdentificationCodeab, das den zweistelligen Code nach ISO 3166-1 enthält; ohne ihn ist der nächste BefundBR-11. - Hat der Kundendatensatz keine Anschrift, vervollständigen Sie den Datensatz. Wer die Anschrift des Verkäufers oder die Lieferanschrift in die Partei des Käufers kopiert, macht eine unwahre Angabe über den Käufer.
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 Partei des Käufers hat eine elektronische Adresse und eine juristische Person, aber keine Postanschrift
<cac:AccountingCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Example Buyer Ltd</cbc:RegistrationName>
<cbc:CompanyID>87654321</cbc:CompanyID>
</cac:PartyLegalEntity>
</cac:Party>
</cac:AccountingCustomerParty>Ausschnitt der korrigierten Rechnung: Die Postanschrift des Käufers steht vor der juristischen Person
<cac:AccountingCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
<cac:PostalAddress>
<cbc:StreetName>2 Example Street</cbc:StreetName>
<cbc:CityName>London</cbc:CityName>
<cbc:PostalZone>SW1A 2AA</cbc:PostalZone>
<cac:Country>
<cbc:IdentificationCode>GB</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Example Buyer Ltd</cbc:RegistrationName>
<cbc:CompanyID>87654321</cbc:CompanyID>
</cac:PartyLegalEntity>
</cac:Party>
</cac:AccountingCustomerParty>Der einzige Unterschied ist die cac:PostalAddress des Käufers, mit Straße, Ort, Postleitzahl und Land GB, zwischen dem cbc:EndpointID des Käufers und cac:PartyLegalEntity. Das fehlerhafte Dokument meldet BR-10 und sonst nichts. BR-11 erscheint nicht, weil seine Prüfung innerhalb der Anschrift des Käufers läuft und das fehlerhafte Dokument keine hat.
Was der Validator gemeldet hat
- Die fehlerhafte Rechnung meldet BR-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 benötigen die Anschrift des Käufers an derselben Stelle. Im Versuch meldete eine Gutschrift, aus der sie entfernt wurde,
BR-10am WurzelelementCreditNote. - Dies ist ein Befund aus EN 16931. Die aufgezeichnete fehlerhafte Rechnung hat im Peppol-Prüfschritt keinen Befund, die Anforderung an die Anschrift des Käufers kommt also allein aus EN 16931.
- Ein Dokument, dem sowohl die Anschrift des Verkäufers als auch die des Käufers fehlt, meldet
BR-08undBR-10zusammen. - Eine Anschrift nach
cac:PartyLegalEntityverletzt die Elementreihenfolge von UBL und wird im XSD-Prüfschritt abgewiesen, sodass diese Regel nicht erreicht wird.
Verwandte Regeln
- BR-11 verlangt den Ländercode in der Anschrift des Käufers, sobald die Anschrift existiert
- BR-08 ist dieselbe Vorhandenseinsprüfung für die Postanschrift des Verkäufers
- BR-07 verlangt den rechtlichen Namen des Käufers in derselben Partei
- BR-CL-14 prüft, ob der Ländercode des Käufers ein gültiger Code nach ISO 3166-1 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-24.
Die offizielle Definition von BR-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.

