BR-09: Der Postanschrift des Verkäufers einen Ländercode geben

Die kurze Antwort

BR-09 schlägt fehl, wenn die cac:PostalAddress des Verkäufers kein cac:Country/cbc:IdentificationCode hat oder nur ein leeres. Schreiben Sie den zweistelligen Code nach ISO 3166-1 alpha-2 für das Land, in dem die Anschrift des Verkäufers liegt, als letztes Kindelement in diese Anschrift: im aufgezeichneten Beispiel GB.

Ein Ländername ist kein Ersatz. Im Versuch ließ cac:Country/cbc:Name mit United Kingdom anstelle des Codes BR-09 weiter fehlschlagen und fügte die Warnung UBL-CR-166 hinzu, weil der Name außerhalb des Rechnungsmodells liegt.

Was die Regel prüft

Die Regel wird innerhalb jeder cac:PostalAddress des Verkäufers ausgewertet und meldet an dieser Anschrift. Sie entfernt Leerraum am Rand des Textes von cac:Country/cbc:IdentificationCode und schlägt fehl, wenn nichts übrig bleibt, ob nun die Gruppe cac:Country fehlt oder der Code darin leer ist.

Ein leerer oder nur aus Leerzeichen bestehender Code bringt zwei weitere Befunde mit. Im Versuch meldeten ein leeres cbc:IdentificationCode und eines mit einem einzelnen Leerzeichen jeweils BR-09, dazu BR-CL-14 für einen Wert, der nicht auf der Länderliste steht, und PEPPOL-EN16931-R008 für das Element ohne Inhalt.

Ob der Text ein echter Code ist, wird hier nicht geprüft. Im Versuch bestand gb in Kleinbuchstaben BR-09 und wurde von BR-CL-14 abgewiesen, das exakt mit der Liste nach ISO 3166-1 vergleicht, Großschreibung eingeschlossen.

Hat der Verkäufer überhaupt keine Anschrift, fehlt der Regel der Ort, an dem sie laufen könnte. Ein solches Dokument meldet stattdessen BR-08, und BR-09 bleibt still.

Wie es in einer Integration dazu kommt

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

• Die Firmeneinstellungen führen das Land des Verkäufers als Namen, und das Mapping schreibt ihn in cac:Country/cbc:Name oder lässt ihn weg, weil er kein Code ist.
• Das Heimatland wird angenommen statt gespeichert, sodass der Datensatz des Verkäufers kein Länderfeld hat und der Export kein cac:Country schreibt.
• Die Anschriften von Verkäufer und Käufer werden von getrenntem Code aufgebaut, und das Land wurde nur in das Mapping des Käufers aufgenommen.
• Eine Zuordnung von gespeichertem Ländernamen zu Code scheitert an einer unerwarteten Schreibweise und liefert eine leere Zeichenkette, die als leeres Element geschrieben wird.

So korrigieren Sie das Dokument

1. Nehmen Sie das Land aus den Stammdaten des Verkäufers: das Land der Anschrift, die in cac:AccountingSupplierParty/cac:Party/cac:PostalAddress übermittelt wird.
2. Wandeln Sie es in den Code nach ISO 3166-1 alpha-2 in Großbuchstaben um, zum Beispiel GB, DE oder NL.
3. Schreiben Sie ihn als cac:Country/cbc:IdentificationCode an das Ende der Anschrift, nach cbc:PostalZone und nach einem etwaigen cbc:CountrySubentity oder cac:AddressLine.
4. Übermitteln Sie kein cac:Country/cbc:Name. Der Code ist das einzige Länderelement, das das Modell verwendet, und der Name zieht eine Warnung nach sich.
5. Hat der Datensatz des Verkäufers kein Land, brechen Sie den Export ab und vervollständigen Sie den Datensatz, statt ein leeres Element zu schreiben.

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: Die Anschrift des Verkäufers endet bei der Postleitzahl

<cac:AccountingSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <cac:PostalAddress>
      <cbc:StreetName>1 Example Street</cbc:StreetName>
      <cbc:CityName>London</cbc:CityName>
      <cbc:PostalZone>SW1A 1AA</cbc:PostalZone>
    </cac:PostalAddress>
    <!-- tax scheme and legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>

Ausschnitt der korrigierten Rechnung: Die Anschrift des Verkäufers schließt mit dem Ländercode GB

<cac:AccountingSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <cac:PostalAddress>
      <cbc:StreetName>1 Example Street</cbc:StreetName>
      <cbc:CityName>London</cbc:CityName>
      <cbc:PostalZone>SW1A 1AA</cbc:PostalZone>
      <cac:Country>
        <cbc:IdentificationCode>GB</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <!-- tax scheme and legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>

Die korrigierte Rechnung schließt die Anschrift des Verkäufers mit cac:Country ab, das GB enthält; die fehlerhafte Rechnung endet nach der Postleitzahl und ist sonst identisch. BR-09 ist der einzige Befund des fehlerhaften Dokuments. Die Anschrift des Käufers behält ihr Land, daher bleibt BR-11 still, und ohne Code gibt es für BR-CL-14 nichts zu prüfen.

Wo die Regel gilt

• Gilt gleichermaßen für Invoice und CreditNote. Im Versuch meldete eine Gutschrift, deren Verkäuferanschrift kein Land hatte, nur BR-09, an der cac:PostalAddress des Verkäufers.
• Eine Regel aus EN 16931. Der Prüfschritt Peppol beanstandete im aufgezeichneten Beispiel nichts am fehlenden Land des Verkäufers.
• Die Anschrift des Käufers hat dieselbe Anforderung unter eigener Kennung. Im Versuch meldete das Entfernen beider Länder BR-09 und BR-11 nebeneinander, jede an ihrer eigenen Anschrift.
• Ein Steuervertreter des Verkäufers braucht, falls vorhanden, ebenfalls einen Ländercode in seiner eigenen Anschrift, was BR-20 prüft.

Verwandte Regeln

• BR-08 verlangt die Postanschrift des Verkäufers, in die dieser Code gehört
• BR-11 verlangt dasselbe von der Postanschrift des Käufers
• BR-CL-14 prüft den Code gegen die Länderliste nach ISO 3166-1, sobald er vorhanden ist
• BR-20 verlangt auch in der Anschrift des Steuervertreters einen Ländercode
• 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-28.1: Quelle geprüft am 2026-09-28, Erklärung zuletzt aktualisiert am 2026-09-28.

Die offizielle Definition von BR-09 (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.