BR-DE-3: In der Verkäuferanschrift fehlt der Ort

Was die Regel prüft

BT-37 „Seller city“ ist laut Spezifikation „die Bezeichnung der Stadt oder Gemeinde, in der sich die Verkäuferanschrift befindet“. In der Visualisierung erscheint das Feld als „Ort“ unter den Informationen zum Verkäufer. Die EN 16931 erlaubt eine Anschrift ohne Ort, XRechnung nicht.

• UBL: Kontext cac:AccountingSupplierParty/cac:Party/cac:PostalAddress, Test cbc:CityName[boolean(normalize-space(.))].
• CII: Kontext ram:SellerTradeParty/ram:PostalTradeAddress, Test ram:CityName[boolean(normalize-space(.))].
• normalize-space entfernt Leerzeichen am Anfang und Ende. Ein Element, das nur Leerzeichen oder Zeilenumbrüche enthält, gilt als fehlend.

Die Regel braucht eine vorhandene Anschrift als Kontext. Fehlt cac:PostalAddress bzw. ram:PostalTradeAddress beim Verkäufer ganz, meldet stattdessen die EN-Regel BR-08 die fehlende Verkäuferanschrift (BG-5). Andere Anschriften in der Datei prüft BR-DE-3 nicht: Die Anschrift des Steuervertreters (BG-12) besteht in Testdatei 01.14 nur aus dem Ländercode und ist trotzdem gültig.

Typische Ursachen

• Anschrift als ein Textblock. Die Firmenanschrift ist in der Software als mehrzeiliges Freitextfeld gepflegt. Der Export schreibt den ganzen Text in Adresszeile 1 (BT-35), das Ortsfeld bleibt leer.
• Leeres Element aus der Vorlage. Der Generator schreibt <cbc:CityName/> oder <ram:CityName></ram:CityName>, weil das Feld in der Vorlage vorgesehen, aber nicht belegt ist. Neben BR-DE-3 meldet dann die Peppol-Regel PEPPOL-EN16931-R008 das leere Element.
• Neuer Mandant, unvollständige Firmendaten. In Programmen mit mehreren Firmen ist für den abrechnenden Mandanten nur Name und Straße erfasst.
• Ort im Feld für den Ortsteil oder das Bundesland. Bei Adressen mit Ortsteil landet der Gemeindename in BT-39 „Seller country subdivision“ (UBL cbc:CountrySubentity, CII ram:CountrySubDivisionName), das Ortsfeld bleibt leer.

Beispiel aus der KoSIT-Testsuite

Testdatei 01.21 ist eine der wenigen Dateien der Testsuite mit realistischer Anschrift statt Platzhaltern wie [Seller city]. Der Ort steht in einem eigenen Element.

<cac:PostalAddress>
  <cbc:StreetName>Musterstrasse 4</cbc:StreetName>
  <cbc:CityName>Frankfurt am Main</cbc:CityName>
  <cbc:PostalZone>60388</cbc:PostalZone>
  <cac:Country>
    <cbc:IdentificationCode>DE</cbc:IdentificationCode>
  </cac:Country>
</cac:PostalAddress>

<ram:PostalTradeAddress>
  <ram:PostcodeCode>60388</ram:PostcodeCode>
  <ram:LineOne>Musterstrasse 4</ram:LineOne>
  <ram:CityName>Frankfurt am Main</ram:CityName>
  <ram:CountryID>DE</ram:CountryID>
</ram:PostalTradeAddress>

Typisch fehlerhaft ist eine Anschrift, in der „Musterstrasse 4, 60388 Frankfurt am Main“ komplett in cbc:StreetName bzw. ram:LineOne steht und cbc:CityName fehlt. Für Menschen ist die Adresse lesbar, für die Prüfung fehlt BT-37.

Lösung

In der Rechnungssoftware

1. Öffnen Sie die Firmendaten des Mandanten, der die Rechnung stellt, und prüfen Sie, ob Straße, Postleitzahl und Ort in getrennten Feldern stehen.
2. Gibt es nur ein Freitextfeld für die Anschrift, suchen Sie in den Einstellungen für den E-Rechnungs-Export nach getrennten Adressfeldern. Ohne diese Trennung kann die Software BT-37 nicht füllen.

Im XML

1. UBL: Fügen Sie in cac:AccountingSupplierParty/cac:Party/cac:PostalAddress das Element cbc:CityName nach den Straßenfeldern und vor cbc:PostalZone ein.
2. CII: Fügen Sie in ram:SellerTradeParty/ram:PostalTradeAddress das Element ram:CityName nach den Adresszeilen (ram:LineOne bis ram:LineThree) und vor ram:CountryID ein.
3. Entfernen Sie leere Ortselemente, statt sie stehen zu lassen.
4. Laden Sie die korrigierte Datei in XRechnung prüfen. Fehlt auch die Postleitzahl, erscheint dort zusätzlich BR-DE-4.

XRechnung prüfen