Auf dieser Seite
Die kurze Antwort
BR-11 schlägt fehl, wenn die cac:PostalAddress des Käufers kein cac:Country/cbc:IdentificationCode hat oder eines ohne sichtbaren Text. Fügen Sie den zweistelligen Code nach ISO 3166-1 für das Land der Käuferanschrift, etwa GB, als cac:Country/cbc:IdentificationCode am Ende dieser Anschrift ein.
Ein Ländername zählt nicht. cac:Country/cbc:Name liegt außerhalb des Rechnungsmodells: Im Versuch ließ es BR-11 weiter fehlschlagen und fügte die Warnung UBL-CR-229 hinzu.
Was die Regel prüft
Die Regel läuft einmal für jede cac:PostalAddress des Käufers, und der Befund wird an dieser Anschrift verortet. Sie nimmt den Text von cac:Country/cbc:IdentificationCode, entfernt umgebenden Leerraum und schlägt fehl, wenn nichts übrig bleibt.
Fehlend und leer werden gleich behandelt. Im Versuch meldeten ein fehlendes cac:Country, ein leeres <cac:Country/>, ein leerer Code und ein Code aus zwei Leerzeichen alle BR-11. Jede leere Variante brachte außerdem PEPPOL-EN16931-R008 mit sich, und der leere oder nur aus Leerraum bestehende Code zusätzlich BR-CL-14, da ein leerer Wert nicht auf der Länderliste steht.
Ob der Wert ein echter Ländercode ist, bleibt einer anderen Regel überlassen: UK hat Text, besteht also BR-11 und wird dann von BR-CL-14 abgelehnt.
Die Regel braucht eine Anschrift, in der sie laufen kann. Hat die Partei des Käufers keine cac:PostalAddress, meldet das BR-10, und BR-11 bleibt stumm.
| Begriff | Bedeutung | UBL-Element |
|---|---|---|
| BT-55 | Ländercode des Käufers | cac:AccountingCustomerParty/cac:Party/cac:PostalAddress/cac:Country/cbc:IdentificationCode |
| BG-8 | Postanschrift des Käufers | cac:AccountingCustomerParty/cac:Party/cac:PostalAddress |
Wie es in einer Integration dazu kommt
Mögliche Ursachen, abgeleitet aus der Form der Regel und nicht aus gemessener Nutzung:
- Der Kundendatensatz speichert das Land als Namen, etwa
United Kingdom, und das Mapping schreibt ihn incac:Country/cbc:Nameoder lässt ihn weg, weil er kein Code ist. - Bei inländischen Kunden ist kein Land eingetragen, weil das System vom Heimatland ausgeht, und der Export schreibt für sie nichts.
- Eine Zuordnung von Ländernamen zu Codes liefert für eine unerwartete Schreibweise nichts, und der Serialisierer schreibt ein leeres Element oder gar keines.
- Die Anschrift wird aus Feldern für Straße, Ort und Postleitzahl aufgebaut, und das Land wurde nie in das Mapping aufgenommen.
So korrigieren Sie das Dokument
- Halten Sie für jede Kundenanschrift einen Ländercode vor und wandeln Sie Namen in Alpha-2-Codes nach ISO 3166-1 um, wo die Quelle Namen speichert.
- Schreiben Sie ihn als
cac:Country/cbc:IdentificationCodein diecac:PostalAddressdes Käufers, nach den Elementen für Straße, Ort, Postleitzahl und Region. - Füllen Sie ein fehlendes Land des Käufers nicht standardmäßig mit dem Land des Verkäufers. Schließen Sie die Lücke im Kundendatensatz, wo die tatsächliche Anschrift bekannt ist.
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 Anschrift des Käufers endet mit der Postleitzahl, ohne Land
<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:PostalAddress>
<!-- legal entity omitted from this fragment -->
</cac:Party>
</cac:AccountingCustomerParty>Ausschnitt der korrigierten Rechnung: Die Anschrift des Käufers schließt mit dem Ländercode GB
<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>
<!-- legal entity omitted from this fragment -->
</cac:Party>
</cac:AccountingCustomerParty>Die korrigierte Rechnung ergänzt cac:Country mit cbc:IdentificationCode GB als letztes Kindelement der Anschrift des Käufers; Straße, Ort und Postleitzahl sind unverändert. BR-11 ist der einzige Befund im fehlerhaften Dokument. Die Anschrift des Verkäufers hat weiterhin ihr Land, daher hat BR-09, die entsprechende Regel für den Verkäufer, nichts zu melden.
Was der Validator gemeldet hat
- Die fehlerhafte Rechnung meldet BR-11. 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
- Die Käuferanschrift einer
CreditNotewird auf dieselbe Weise geprüft. Im Versuch meldete die GutschriftfassungBR-11an dercac:PostalAddressdes Käufers. - Der Verkäufer hat eine eigene Regel für dasselbe Feld,
BR-09, und ebenso der Steuervertreter,BR-20. Für die Lieferanschrift giltBR-57, das schwächer ist: Es prüft nur, ob das Code-Element existiert, sodass ein leerer Code in der Lieferanschrift es besteht. BR-11gehört zum Prüfschritt EN 16931. Peppol fügt nur dann einen eigenen Befund hinzu, wenn ein leerescac:Countryoder Code-Element zurückbleibt; fehlt das Land ganz, wie im aufgezeichneten Beispiel, besteht der Peppol-Prüfschritt.
Verwandte Regeln
- BR-10 meldet eine Partei des Käufers ganz ohne Postanschrift, in der diese Regel nicht laufen kann
- BR-CL-14 prüft, ob der Ländercode auf der Liste nach ISO 3166-1 steht
- BR-57 verlangt ein Ländercode-Element in der Lieferanschrift, ohne zu prüfen, ob es einen Wert hat
- PEPPOL-EN16931-R008 wird zusätzlich gemeldet, wenn das Länderelement vorhanden, aber leer 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-11 (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.

