BR-DE-3: what it means and how to fix it

The seller's city must be given.

RuleBR-DE-3
StandardXRechnung 3.0 (the German CIUS of EN 16931, published by KoSIT)
SeverityError (the invoice is not conformant)
ConcernsBT-37: Seller city

How to fix it

Add the city to the seller's address.

Where the field is in the XML

TermCII (XRechnung-CII, ZUGFeRD, Factur-X)UBL (XRechnung-UBL, Peppol)
BT-37
Seller city
ram:SellerTradeParty/ram:PostalTradeAddress/ram:CityNamecac:AccountingSupplierParty/cac:Party/cac:PostalAddress/cbc:CityName

Check your own file for this rule

Up to 5 MB. Read in memory for this one request and not stored.

From your code

curl -H "Authorization: Bearer $API_KEY" -H "Content-Type: application/xml" \
  --data-binary @invoice.xml "https://agent-data-tools.revmesh2074.workers.dev/einvoice/validate"

The answer lists every broken rule with its number, the field, a message with the figures from your file and the fix. E-invoice API: validate, convert to JSON, and create XRechnung or ZUGFeRD XML from JSON.

Questions

What does BR-DE-3 mean?

The seller's city must be given. It is a rule of XRechnung 3.0 (the German CIUS of EN 16931, published by KoSIT).

How do I fix BR-DE-3?

Add the city to the seller's address.

Is BR-DE-3 an error or a warning?

An error: a validator reports the invoice as not conformant, and a recipient that validates incoming e-invoices can reject it.

Does BR-DE-3 apply to ZUGFeRD and Factur-X too?

Only when the file declares the XRechnung specification identifier (the ZUGFeRD profile "XRECHNUNG" does). Files in the plain EN 16931 profile are checked against the European rules, not the German additions.

Rule numbers are those of XRechnung 3.0 (KoSIT); the explanation is ours. Not tax or legal advice.