BR-AE-04: Identify the seller and the buyer when a document-level charge is reverse charged

The short answer

BR-AE-04 fails when a charge has a cac:TaxCategory of AE and the document does not identify the seller for tax, or does not identify the buyer. The recorded example has lost the seller cac:PartyTaxScheme holding GB123456789; put it back between the seller postal address and legal entity.

The buyer side works as in BR-AE-02: a VAT identifier or a legal registration identifier is enough. When tried on the freight invoice, removing just one of DE123456789 and 87654321 left it valid, while removing both reported this rule and BR-AE-02.

What the rule checks

A charge here is an cac:AllowanceCharge with cbc:ChargeIndicator of true. The rule fires when one has a cac:TaxCategory with cbc:ID of AE under the VAT scheme and either party lacks its identifier; it is reported once at the document root, without saying which party.

The charge starts the buyer check without any help from the lines. When tried on an invoice whose only line was Standard rated, with a reverse-charge freight charge of 4.00 and a buyer holding neither identifier, this rule was reported alone.

On the seller side, a cbc:CompanyID under any scheme counts. When tried, the freight invoice with the seller scheme TAX in place of VAT was valid.

Without a seller identifier, the seller rule of the line category is reported as well: BR-AE-02 for the reverse-charge line of the recorded example, and BR-S-02 when tried with a Standard rated line instead.

How an integration ends up here

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

• The seller VAT number is written only when the document charges VAT, and a reverse-charge invoice charges none.
• The seller tax identifier is held per legal entity and was never set up for the entity that issued this invoice.
• The buyer VAT and registration numbers are missing from the customer record, so the buyer party carries only a name and address.
• A tax representative is used, but cac:TaxRepresentativeParty is sent without its VAT identifier.

How to fix it

1. Find the side that is missing: the seller needs a cac:PartyTaxScheme/cbc:CompanyID or a tax representative VAT identifier, the buyer a VAT identifier under VAT or a cac:PartyLegalEntity/cbc:CompanyID.
2. For the seller, write its VAT number to cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID with cac:TaxScheme/cbc:ID of VAT, after cac:PostalAddress and before cac:PartyLegalEntity.
3. For the buyer, prefer the VAT identifier in the buyer cac:PartyTaxScheme, and add the legal registration identifier where it is known.
4. Keep the freight charge in category AE at 0 if it belongs to the reverse-charge supply; the finding is not about the charge itself.

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 seller party with no PartyTaxScheme, and a reverse-charge freight charge

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

<cac:AllowanceCharge>
  <cbc:ChargeIndicator>true</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReasonCode>FC</cbc:AllowanceChargeReasonCode>
  <cbc:AllowanceChargeReason>Freight</cbc:AllowanceChargeReason>
  <cbc:Amount currencyID="GBP">4.00</cbc:Amount>
  <cac:TaxCategory>
    <cbc:ID>AE</cbc:ID>
    <cbc:Percent>0</cbc:Percent>
    <cac:TaxScheme>
      <cbc:ID>VAT</cbc:ID>
    </cac:TaxScheme>
  </cac:TaxCategory>
</cac:AllowanceCharge>

Fragment of the corrected invoice: the seller VAT identifier restored, with the freight charge unchanged

<cac:AccountingSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <!-- postal address omitted from this fragment -->
    <cac:PartyTaxScheme>
      <cbc:CompanyID>GB123456789</cbc:CompanyID>
      <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
      </cac:TaxScheme>
    </cac:PartyTaxScheme>
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Example Supplier Ltd</cbc:RegistrationName>
      <cbc:CompanyID>12345678</cbc:CompanyID>
    </cac:PartyLegalEntity>
  </cac:Party>
</cac:AccountingSupplierParty>

<!-- the reverse-charge freight charge of 4.00 is the same as in the failing invoice -->

The corrected invoice has the seller cac:PartyTaxScheme with GB123456789 under VAT; the failing invoice has none, while its buyer still has DE123456789 and 87654321. The failing document also reports BR-AE-02, since its reverse-charge line of 25.00 depends on the same seller identifier. The freight charge of 4.00 and the reverse-charge breakdown of 29.00 are the same in both documents.

Where it applies

• Applies to UBL Invoice and CreditNote. A reverse-charge credit note with the freight charge and no seller tax scheme reported this rule and BR-AE-02 when tried.
• Reported by the EN 16931 layer as one fatal finding at the document root.
• Charges in the Standard rated and exempt categories need only the seller identifier, under BR-S-04 and BR-E-04. A reverse-charge charge also needs a rate of 0 under BR-AE-07 and a place in the single AE breakdown that BR-AE-01 requires.

Related rules

• BR-AE-02 is reported with this rule when the lines are reverse charged as well
• BR-AE-03 is the same test for a reverse-charge document-level allowance
• BR-AE-01 requires the one reverse-charge breakdown that takes in the charge
• BR-AE-07 requires the reverse-charge charge 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-28.1: source checked 2026-09-28, explanation last updated 2026-09-28.

The official definition of BR-AE-04 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.