BR-DE-9: In der Käuferanschrift fehlt die Postleitzahl
Der Anschrift des Rechnungsempfängers fehlt die Postleitzahl. Ergänzen Sie sie in den Kundendaten; bei Behörden mit Postfach- oder Großempfänger-Anschrift genau die Postleitzahl dieser Anschrift.
[BR-DE-9] Das Element "Buyer post code" (BT-53) muss übermittelt werden.
Betroffen:BG-8BT-53
Was die Regel prüft
- UBL: Kontext
cac:AccountingCustomerParty/cac:Party/cac:PostalAddress, Testcbc:PostalZone[boolean(normalize-space(.))]. - CII: Kontext
ram:BuyerTradeParty/ram:PostalTradeAddress, Testram:PostcodeCode[boolean(normalize-space(.))].
Zusammen mit BR-DE-8 und der EN-Regel zum Ländercode ergibt sich die Mindestanschrift des Käufers in XRechnung: Ort (BT-52), Postleitzahl (BT-53) und Ländercode (BT-55). Straße und Hausnummer (BT-50) sind nicht vorgeschrieben. Das Beispiel unten aus Testdatei 01.14 kommt ohne Straße aus und ist gültig.
Die Regel gilt unabhängig vom Land des Käufers. Für Empfänger in Ländern ohne Postleitzahlsystem sieht das Regelwerk keine Ausnahme vor. Klären Sie in diesem Fall mit dem Empfänger, welcher Wert erwartet wird.
Typische Ursachen
- Postleitzahl im Ortsfeld. „10115 Berlin“ steht vollständig im Feld Ort. Dann meldet die Prüfung BR-DE-9, aber nicht BR-DE-8.
- Postfach ohne Postleitzahl. Für Behörden ist oft nur „Postfach 12 34“ und der Ort gepflegt.
- Kunden aus dem Ausland. Bei ausländischen Kunden wurde das Postleitzahlfeld leer gelassen, weil die Postleitzahl in der Landesschreibweise Teil der Ortszeile ist.
- Spalte beim Import verschoben. Beim Einlesen von Kundendaten landete die Postleitzahl in einer Adresszeile.
Beispiel aus der KoSIT-Testsuite
Testdatei 01.14 enthält eine Käuferanschrift ohne Straße. Ort, Postleitzahl und Ländercode reichen aus.
<cac:PostalAddress>
<cbc:CityName>[Buyer city]</cbc:CityName>
<cbc:PostalZone>98765</cbc:PostalZone>
<cac:Country>
<cbc:IdentificationCode>DE</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>Quelle: KoSIT XRechnung-Testsuite 2026-08-31, Datei instances/standard/01.14a-INVOICE_ubl.xml (Apache 2.0)
<ram:PostalTradeAddress>
<ram:PostcodeCode>98765</ram:PostcodeCode>
<ram:CityName>[Buyer city]</ram:CityName>
<ram:CountryID>DE</ram:CountryID>
</ram:PostalTradeAddress>Quelle: KoSIT XRechnung-Testsuite 2026-08-31, Datei instances/standard/01.14a-INVOICE_uncefact.xml (Apache 2.0)
Würde cbc:PostalZone bzw. ram:PostcodeCode fehlen, bliebe nur Ort und Land übrig, und die Prüfung meldete BR-DE-9.
Lösung
In der Rechnungssoftware
- Tragen Sie im Kundendatensatz die Postleitzahl in das eigene Feld ein und entfernen Sie sie aus dem Ortsfeld.
- Bei öffentlichen Auftraggebern verwenden Sie die Rechnungsanschrift aus dem Auftrag. Dort ist die passende Postleitzahl meist schon angegeben.
- Erzeugen Sie die Rechnung danach neu, damit die korrigierten Stammdaten in der Datei landen.
Im XML
- UBL: Fügen Sie
cbc:PostalZonein der Käuferanschrift direkt nachcbc:CityNameein. - CII: Fügen Sie
ram:PostcodeCodeals erstes Kindelement vonram:BuyerTradeParty/ram:PostalTradeAddressein. - Kontrollieren Sie die neue Fassung in XRechnung prüfen; BR-DE-9 sollte dort nicht mehr erscheinen.
Wessen Anschrift ist bei einer Gutschrift nach § 14 Abs. 2 Satz 2 UStG betroffen?
Bei Code 389 erstellt der Leistungsempfänger das Dokument. Er bleibt in der Datei trotzdem der Käufer (BG-7). BR-DE-9 betrifft dann die eigene Anschrift des Ausstellers, nicht die des Lieferanten.
Reicht die Postleitzahl in der Lieferanschrift?
Nein. Lieferanschrift (BG-15) und Käuferanschrift (BG-8) werden getrennt geprüft. Eine Postleitzahl in der Lieferanschrift ersetzt BT-53 nicht; für die Lieferanschrift selbst gilt BR-DE-11.
Quellen
- XRechnung Schematron 2.6.0 (Release v2.6.0, Dateien ubl/XRechnung-UBL-validation.sch und cii/XRechnung-CII-validation.sch)KoSIT (GitHub itplr-kosit/xrechnung-schematron), 31. August 2026 · geprüft am 7. November 2026
- XRechnung-Testsuite, Release 2026-08-31KoSIT (GitHub itplr-kosit/xrechnung-testsuite), 31. August 2026 · geprüft am 7. November 2026
- Spezifikation XRechnung Version 3.0.2KoSIT (xeinkauf.de), 20. Juni 2024 · geprüft am 7. November 2026