The buyer postal address must contain a country code

Why it fires on invoices that look fine

Almost nobody hits this rule because they forgot the field exists. They hit it because something between their system and the document dropped it, changed its shape, or filled it with a value that is right somewhere else. These are the causes worth checking first.

• Same causes as the seller side: a spelled-out country name, an alpha-3 code, a lowercase code, or a field nobody filled because every customer was domestic until one was not.
• The buyer's country was inferred from their VAT number prefix at some point and stored in that form, which puts EL rather than GR on Greek customers.

What to change

• Send the two-letter uppercase ISO 3166-1 alpha-2 code, taken from the address record rather than typed per invoice.
• Derive it from the address, not from the VAT number. The VAT prefix and the country code agree almost always, and the exceptions are exactly the cases that get an invoice rejected.

The validator runs in your browser. Nothing is uploaded, and you can confirm that yourself with the network panel open.

Rules you are likely to hit next

A document that breaks BR-11 usually breaks one of these too, because the same mapping gap tends to affect neighbouring fields.

• BR-09: seller country code
• BR-10: buyer postal address

Questions people actually ask

What does BR-11 mean?

The buyer's address carries a country, as a two-letter ISO 3166-1 code.

Which field does BR-11 apply to?

BT-55, Buyer country code. That is the name the semantic model uses, which is what you search for in your own system's mapping when the identifier alone does not tell you which field to look at.

Does our validator check BR-11?

Yes. Paste your invoice data into the free validator and it reports this rule with the value it actually saw, without the document leaving your browser.