An invoice must contain the seller name

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.

• The seller is identified only by a registration number or a Peppol participant id, on the assumption that the receiver can look the name up. The rule requires the name itself.
• A trading name was mapped into a different field and the legal name field left blank.
• The export builds the seller block from a template that was only ever filled for the primary legal entity, so invoices from a subsidiary arrive nameless.

What to change

• Send the seller's registered legal name, the one on the commercial register. That is what the buyer's accounts payable system matches against, and what a tax audit expects to find.
• If you trade under a different name, send the legal name here and put the trading name in the field meant for it rather than choosing between them.

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-06 usually breaks one of these too, because the same mapping gap tends to affect neighbouring fields.

• BR-08: seller postal address
• BR-09: seller country code
• BR-07: buyer name

Questions people actually ask

What does BR-06 mean?

Every invoice names the seller: the party that is owed the money.

Which field does BR-06 apply to?

BT-27, Seller name. 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-06?

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.