BR-08: Die Postanschrift des Verkäufers angeben

Die kurze Antwort

BR-08 schlägt fehl, wenn cac:AccountingSupplierParty/cac:Party kein Kindelement cac:PostalAddress hat. Fügen Sie dort die Anschrift der verkaufenden Gesellschaft ein: mindestens cac:Country/cbc:IdentificationCode sowie Straße, Ort und Postleitzahl, soweit der Datensatz des Verkäufers sie enthält.

Der Befund verweist auf das Wurzelelement des Dokuments, nicht auf die Partei des Verkäufers, da die Prüfung einmal für das ganze Dokument erfolgt. Eine Anschrift an einer anderen Stelle als diesem einen Element, etwa eine Sitzanschrift unter cac:PartyLegalEntity, lässt die Regel weiterhin fehlschlagen.

Was die Regel prüft

Die Regel stellt eine einzige Frage: Gibt es eine cac:PostalAddress direkt innerhalb von cac:AccountingSupplierParty/cac:Party? Was die Anschrift enthält, wird hier nicht untersucht.

Ein leeres <cac:PostalAddress/> genügt, um sie zu erfüllen. Im Versuch wurde dieses leere Element stattdessen von BR-09 gemeldet, das einen Ländercode des Verkäufers in der Anschrift verlangt, und von PEPPOL-EN16931-R008, das leere Elemente ablehnt. Eine Anschrift, die nur den Ländercode enthielt, bestand jeden Prüfschritt.

Keine andere Anschrift ersetzt diese. Im Versuch ließ eine Anschrift in cac:PartyLegalEntity/cac:RegistrationAddress BR-08 weiter fehlschlagen und fügte die Warnung UBL-CR-185 hinzu, die dieses Element als außerhalb des Modells meldet. Die Anschriften von Käufer, Steuervertreter und Lieferort sind eigene Gruppen mit eigenen Regeln.

Wie es in einer Integration dazu kommt

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

• Die Anschrift des Verkäufers steht in Unternehmenseinstellungen, die der Export nicht liest, und die Partei des Verkäufers wird nur aus Name und Kennungen aufgebaut.
• Der Anschriftenblock wird nur geschrieben, wenn eine Straßenzeile vorhanden ist, sodass ein Verkäuferdatensatz mit Ort und Land, aber ohne Straße überhaupt keine cac:PostalAddress erzeugt.
• Das Mapping schreibt die Anschrift in cac:PartyLegalEntity/cac:RegistrationAddress, weil es der eingetragene Sitz ist, und nichts in cac:PostalAddress.
• Die Rechnung wird für eine Tochtergesellschaft oder Niederlassung ausgestellt, deren Anschrift nie konfiguriert wurde, und der Builder lässt den Block weg, statt abzubrechen.

So korrigieren Sie das Dokument

1. Nehmen Sie die Anschrift der verkaufenden Gesellschaft aus ihren Stammdaten: der Gesellschaft, die in cac:PartyLegalEntity/cbc:RegistrationName genannt ist, nicht die eines Lagers und keine Zahlungsanschrift.
2. Schreiben Sie sie als cac:PostalAddress in cac:AccountingSupplierParty/cac:Party, nach cbc:EndpointID, cac:PartyIdentification und cac:PartyName und vor cac:PartyTaxScheme.
3. Nehmen Sie cac:Country/cbc:IdentificationCode als letztes Kindelement der Anschrift auf, mit dem Alpha-2-Code nach ISO 3166-1, etwa GB. BR-09 verlangt ihn, und BR-CL-14 prüft den Wert.
4. Übermitteln Sie auch Straße, Ort und Postleitzahl. Der Validator akzeptiert eine Anschrift, die nur ein Land enthält, aber das ist das Minimum, das die Regeln prüfen, keine vollständige Anschrift.
5. Hat der Datensatz des Verkäufers keine Anschrift, stoppen Sie den Export und vervollständigen Sie den Datensatz. Kopieren Sie weder die Anschrift des Käufers noch einen Platzhalter in die Partei des Verkäufers.

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 Partei des Verkäufers geht von ihrer elektronischen Adresse direkt zu ihrem Steuerschema über

<cac:AccountingSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <cac:PartyTaxScheme>
      <cbc:CompanyID>GB123456789</cbc:CompanyID>
      <!-- tax scheme omitted from this fragment -->
    </cac:PartyTaxScheme>
    <!-- legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>

Ausschnitt der korrigierten Rechnung: Die Postanschrift des Verkäufers steht zwischen elektronischer Adresse und Steuerschema

<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>
    <cac:PartyTaxScheme>
      <cbc:CompanyID>GB123456789</cbc:CompanyID>
      <!-- tax scheme omitted from this fragment -->
    </cac:PartyTaxScheme>
    <!-- legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>

Die korrigierte Rechnung hat eine cac:PostalAddress des Verkäufers mit Straße, Ort, Postleitzahl und Land GB; die fehlerhafte Rechnung hat keine Anschrift des Verkäufers und ist sonst identisch. BR-08 ist der einzige Befund im fehlerhaften Dokument. Die Regel für das Land des Verkäufers, BR-09, bleibt stumm, weil sie innerhalb der Anschrift läuft und es keine Anschrift gibt, in der sie laufen könnte.

Wo die Regel gilt

• Eine CreditNote trägt die Anschrift des Verkäufers an derselben Stelle. Im Versuch meldete eine Gutschrift ohne sie nur BR-08, verortet am Wurzelelement CreditNote.
• Die Anforderung stammt aus EN 16931 und wird in diesem Prüfschritt gemeldet; im Prüfschritt Peppol beanstandete im aufgezeichneten Beispiel nichts die fehlende Anschrift des Verkäufers.
• Eine Anschrift an der falschen Position unter den Kindelementen von cac:Party scheitert am XSD-Prüfschritt, bevor diese Regel erreicht wird: Im Versuch ergab die Anschrift des Verkäufers nach cac:PartyLegalEntity einen XSD-Fehler, und die Prüfschritte EN 16931 und Peppol wurden übersprungen.
• Fehlen die Anschriften beider Parteien, werden BR-08 und BR-10 nebeneinander gemeldet, beide am Wurzelelement.

Verwandte Regeln

• BR-10 ist dieselbe Vorhandenseinsprüfung für die Postanschrift des Käufers
• BR-CL-14 prüft, ob der Ländercode in der Anschrift ein gültiger Code nach ISO 3166-1 ist
• BR-06 verlangt den rechtlichen Namen des Verkäufers in derselben Partei
• PEPPOL-EN16931-R008 meldet ein Anschriftenelement des Verkäufers, das 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-08 (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.