The short answer
BR-18 fails when cac:TaxRepresentativeParty has no cac:PartyName/cbc:Name, or the name is blank. Put the name of the tax representative, the party accountable for VAT on the seller's behalf, in cac:PartyName/cbc:Name as the first child of cac:TaxRepresentativeParty.
Seller and buyer names go in cac:PartyLegalEntity/cbc:RegistrationName; the tax representative name does not. When tried, the name placed in a cac:PartyLegalEntity inside the representative left BR-18 failing and added the warning UBL-CR-335, because the model has no legal entity for this party.
What the rule checks
The rule runs once for each cac:TaxRepresentativeParty and reports at that element, so an invoice without a tax representative is never tested.
It trims the text of cac:PartyName/cbc:Name and fails if nothing remains. When tried, an empty name and a name of three spaces both reported BR-18, together with PEPPOL-EN16931-R008 for the blank element.
Any visible text satisfies it. The rule cannot tell whether the name is the one on the representative appointment.
| Term | Meaning | UBL element |
|---|---|---|
| BG-11 | Seller tax representative party | cac:TaxRepresentativeParty |
| BT-62 | Seller tax representative name | cac:TaxRepresentativeParty/cac:PartyName/cbc:Name |
How an integration ends up here
Possible causes, from the shape of the rule rather than from measured usage:
- The representative block is generated from a VAT registration record that holds the VAT number and address of the representative but not its name.
- A party builder shared with the seller and buyer writes the name only to
cac:PartyLegalEntity/cbc:RegistrationName, which is right for them and wrong here. - The block is written for every invoice from a seller registered abroad, with empty fields when no representative has been appointed.
How to fix it
- Confirm that the seller really has a tax representative for this invoice. If it does not, leave
cac:TaxRepresentativePartyout; the group is optional. - Take the representative name from the appointment or registration record, and write it as
cac:TaxRepresentativeParty/cac:PartyName/cbc:Name, beforecac:PostalAddress. - Complete the rest of the group from the same record: the representative also needs a VAT identifier (
BR-56), a postal address (BR-19) and a country code in that address (BR-20). - Do not add a
cac:PartyLegalEntityto the representative; it is outside the model and draws a warning.
Validate your corrected invoice
Before and after
These are fragments, not complete documents. The complete synthetic documents they come from are linked below.
Fragment of the failing invoice: the tax representative starts with its address and has no name
<cac:TaxRepresentativeParty>
<cac:PostalAddress>
<cbc:StreetName>4 Example Street</cbc:StreetName>
<!-- rest of the address omitted from this fragment -->
</cac:PostalAddress>
<cac:PartyTaxScheme>
<cbc:CompanyID>GB987654321</cbc:CompanyID>
<!-- tax scheme omitted from this fragment -->
</cac:PartyTaxScheme>
</cac:TaxRepresentativeParty>Fragment of the corrected invoice: PartyName comes first in the tax representative
<cac:TaxRepresentativeParty>
<cac:PartyName>
<cbc:Name>Example Fiscal Representative Ltd</cbc:Name>
</cac:PartyName>
<cac:PostalAddress>
<cbc:StreetName>4 Example Street</cbc:StreetName>
<!-- rest of the address omitted from this fragment -->
</cac:PostalAddress>
<cac:PartyTaxScheme>
<cbc:CompanyID>GB987654321</cbc:CompanyID>
<!-- tax scheme omitted from this fragment -->
</cac:PartyTaxScheme>
</cac:TaxRepresentativeParty>The corrected invoice opens cac:TaxRepresentativeParty with cac:PartyName holding Example Fiscal Representative Ltd; nothing else differs. The failing document reports BR-18 alone, because its representative still has an address with a country code and a VAT identifier.
What the validator reported
- The failing invoice reports BR-18. The corrected document passes every layer with no findings.Download the failing XMLDownload the corrected XML
Recorded on phive 12.1.0 / phive-rules-peppol 4.5.6 / Saxon-HE 12.10, the engine behind the free validator, using synthetic data. A recorded result is regression evidence for these documents; it is not a certification.
Where it applies
- The tax representative has the same structure in a
CreditNote. When tried, a credit note whose representative had no name reportedBR-18alone. - An EN 16931 rule. In the recorded example the name is the only thing wrong, and the Peppol layer has no finding.
- The seller and buyer name rules,
BR-06andBR-07, readcbc:RegistrationName. A shared party mapping has to switch tocac:PartyNamefor the representative.
Related rules
- BR-56 requires the VAT identifier of the same tax representative
- BR-06 names the seller through RegistrationName, the element this rule does not read
- PEPPOL-EN16931-R008 is reported with this rule when the name element is present but blank
- BR-17 is the naming rule for the other optional party, a payee who is not the seller
- Browse every rule in the reference
- Background: Understanding EN 16931 validation errors
Scope and source
Written for Peppol BIS Billing 3.0.21 (May 2026), EN 16931 1.3.16, as applied to UBL 2.1 Invoice and CreditNote documents. Other profiles, syntaxes and releases can define this identifier differently. Guidance version 2026-09-24.1: source checked 2026-09-24, explanation last updated 2026-09-24.
The official definition of BR-18 carries the normative wording and test. This page is our explanation of it, not a copy.
Guidance does not change the engine verdict. Fixing this finding does not mean the document passes every layer, and validation does not certify legal or tax compliance or transmit a document over Peppol.