BR-AE-02: Identify the seller and the buyer on a reverse-charge invoice

The short answer

BR-AE-02 fails when a line has VAT category AE and the document does not identify both parties. The seller needs a cac:PartyTaxScheme/cbc:CompanyID or a tax representative VAT identifier; the buyer needs a VAT identifier in cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID or a legal registration identifier in cac:PartyLegalEntity/cbc:CompanyID. The recorded example has lost both buyer identifiers, and adding either would satisfy the rule.

Send the buyer VAT identifier whenever the buyer has one. Reverse charge moves the VAT accounting to the buyer, and the validator only confirms that some buyer identifier is there, not that the reverse charge is justified.

What the rule checks

The rule is triggered by a cac:ClassifiedTaxCategory with cbc:ID of AE under the VAT scheme, that is by a reverse-charge line. When tried, a reverse-charge document charge without buyer identifiers was reported as BR-AE-04, and a reverse-charge document allowance as BR-AE-03, instead of this rule.

For the seller, any cbc:CompanyID inside a seller cac:PartyTaxScheme counts, whatever tax scheme it names, and so does a tax representative identifier under the VAT scheme. When tried, removing only the seller VAT identifier reported this rule, while a seller cac:PartyTaxScheme with scheme TAX in place of VAT passed.

For the buyer, either a buyer cac:PartyTaxScheme/cbc:CompanyID under the VAT scheme or cac:PartyLegalEntity/cbc:CompanyID is accepted. Removing just one of them from the valid reverse-charge invoice left it valid when tried; only removing both failed.

The buyer's tax scheme is checked, unlike the seller's. With the buyer scheme changed to TAX and no legal registration identifier, the rule failed when tried, and a buyer cac:PartyIdentification/cbc:ID did not count either.

Presence is the whole test. An empty buyer cac:PartyLegalEntity/cbc:CompanyID got past this rule when tried, and was reported by PEPPOL-EN16931-R008 instead.

How an integration ends up here

Possible causes, from the shape of the rule rather than from measured usage:

• The buyer VAT number is held on the customer record but never mapped, because domestic invoices did not need it.
• Buyer details come from an order or delivery address that has no tax fields, rather than from the customer master.
• The buyer VAT number is written to cac:PartyIdentification or used only as the electronic address, where it does not count.
• The buyer VAT identifier is sent with a tax scheme other than VAT.
• The seller VAT number is missing from the seller party for the reasons described under BR-S-02.

How to fix it

1. Work out which side is missing: look in the seller party for a cac:PartyTaxScheme/cbc:CompanyID, and in the buyer party for a VAT identifier or a legal registration identifier. The single finding does not say which.
2. For the buyer, take the VAT registration number, with its country prefix, from the customer record. Write it to cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID with cac:TaxScheme/cbc:ID of VAT, between cac:PostalAddress and cac:PartyLegalEntity.
3. If the buyer has a company registration number on record, send it too, in cac:PartyLegalEntity/cbc:CompanyID after cbc:RegistrationName.
4. For the seller, write its own VAT number in the seller cac:PartyTaxScheme, or the tax representative's in cac:TaxRepresentativeParty.
5. If the buyer has no VAT registration, take the question of whether reverse charge applies back to whoever owns the tax setup before changing anything else.

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: a reverse-charge line, and a buyer with neither a VAT identifier nor a legal registration identifier

<cac:AccountingCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <!-- postal address omitted from this fragment -->
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Example Buyer Ltd</cbc:RegistrationName>
    </cac:PartyLegalEntity>
  </cac:Party>
</cac:AccountingCustomerParty>

<cac:ClassifiedTaxCategory>
  <cbc:ID>AE</cbc:ID>
  <cbc:Percent>0</cbc:Percent>
  <cac:TaxScheme>
    <cbc:ID>VAT</cbc:ID>
  </cac:TaxScheme>
</cac:ClassifiedTaxCategory>

Fragment of the corrected invoice: the buyer VAT identifier and legal registration identifier are both present

<cac:AccountingCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <!-- postal address omitted from this fragment -->
    <cac:PartyTaxScheme>
      <cbc:CompanyID>DE123456789</cbc:CompanyID>
      <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
      </cac:TaxScheme>
    </cac:PartyTaxScheme>
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Example Buyer Ltd</cbc:RegistrationName>
      <cbc:CompanyID>87654321</cbc:CompanyID>
    </cac:PartyLegalEntity>
  </cac:Party>
</cac:AccountingCustomerParty>

The corrected invoice gives the buyer a VAT identifier, DE123456789 under the VAT scheme, and a legal registration identifier, 87654321; the failing invoice has neither. The failing document reports only BR-AE-02. The seller side is not at issue, since the seller VAT identifier GB123456789 is present in both documents.

Where it applies

• Applies to UBL Invoice and CreditNote. A reverse-charge credit note with no buyer identifier reported the same rule when tried.
• Reported by the EN 16931 layer as one fatal finding at the document root, covering the seller side and the buyer side together.
• Unlike BR-S-02, which looks only at the seller, this rule also asks for a buyer identifier. It is looser than the intra-community rule BR-IC-02, which accepts only a buyer VAT identifier and also checks the seller's tax scheme.
• Fixing it leaves the other reverse-charge rules to satisfy: a reason in the breakdown under BR-AE-10, a line rate of 0 under BR-AE-05 and a breakdown tax amount of 0 under BR-AE-09.

Related rules

• BR-S-02 is the Standard rated counterpart, which asks for the seller identifier only
• BR-AE-10 requires the reverse-charge reason in the VAT breakdown
• BR-CO-09 checks the country prefix on the seller and buyer VAT identifiers
• BR-AE-05 requires every reverse-charge line to carry a rate of 0
• 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-AE-02 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.