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

The short answer

BR-AE-03 fails when an allowance has a cac:TaxCategory of AE and the document lacks either a seller tax identifier or a buyer identifier. In the recorded example the buyer has neither a VAT identifier nor a legal registration identifier; restoring either one would do, and the corrected invoice has both, DE123456789 under VAT and 87654321.

Like BR-AE-02, this rule takes the buyer legal registration identifier in place of a VAT number. Send the buyer VAT identifier all the same when the buyer has one: the validator only sees that some buyer identifier is present, not whether the buyer can account for the VAT.

What the rule checks

The trigger is an cac:AllowanceCharge with cbc:ChargeIndicator of false whose cac:TaxCategory has cbc:ID of AE under the VAT scheme. Reverse-charge lines are covered by BR-AE-02 and reverse-charge charges by BR-AE-04, which test the parties in the same way.

Either buyer identifier is enough on its own. When tried on the discount invoice, removing only the buyer VAT identifier left it valid, and so did removing only the legal registration identifier.

The buyer VAT identifier counts only under the VAT scheme. With the legal registration identifier gone, a buyer scheme of TAX failed when tried, and so did the buyer VAT number moved to cac:PartyIdentification/cbc:ID; each time BR-AE-02 came too.

The seller side accepts a cbc:CompanyID under any scheme. When tried, the seller scheme set to TAX passed, while removing the seller tax scheme reported this rule and BR-AE-02.

The allowance brings in the buyer condition by itself. When tried on an invoice with a Standard rated line, a reverse-charge discount of 3.00 and a buyer with no identifier, this rule was reported alone.

How an integration ends up here

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

• The customer was set up as a domestic account, so its record holds neither a VAT number nor a registration number.
• The buyer party is built from a delivery or order address that has no tax fields.
• The buyer VAT number is sent under a scheme other than VAT, or only as the party identifier.
• The seller tax scheme is left out of documents with no VAT to charge, which a reverse-charge invoice is.

How to fix it

1. Check both parties, since the finding does not say which side is short: the seller needs a cac:PartyTaxScheme/cbc:CompanyID or a tax representative, and the buyer a VAT identifier under VAT or a legal registration identifier.
2. For the buyer, write the VAT number to cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID with cac:TaxScheme/cbc:ID of VAT, between cac:PostalAddress and cac:PartyLegalEntity, and a known registration number to cac:PartyLegalEntity/cbc:CompanyID.
3. Leave the allowance as it is: a reverse-charge volume discount of 3.00 in category AE at 0 is correct when it reduces reverse-charge supplies.
4. Validate again. BR-AE-02 reads the same identifiers and clears at the same time.

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 buyer with only a name and address, and a reverse-charge volume discount

<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:AllowanceCharge>
  <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReasonCode>95</cbc:AllowanceChargeReasonCode>
  <cbc:AllowanceChargeReason>Volume discount</cbc:AllowanceChargeReason>
  <cbc:Amount currencyID="GBP">3.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 buyer VAT identifier and legal registration identifier are both back

<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 reverse-charge volume discount of 3.00 is the same as in the failing invoice -->

The corrected invoice gives the buyer a VAT identifier, DE123456789 under VAT, and a legal registration identifier, 87654321; the failing invoice has neither. The failing document also reports BR-AE-02, because its line of 25.00 is reverse charged too and depends on the same buyer identifiers. The volume discount of 3.00 and the reverse-charge breakdown of 22.00 are the same in both documents.

Where it applies

• Applies to UBL Invoice and CreditNote. A reverse-charge credit note with the discount and no buyer identifiers reported this rule and BR-AE-02 when tried.
• Reported by the EN 16931 layer as a single fatal finding at the document root, covering the seller and the buyer together.
• The exempt allowance rule BR-E-03 asks for the seller identifier only. A reverse-charge allowance must also carry a rate of 0 under BR-AE-06.

Related rules

• BR-AE-02 applies the same seller and buyer test to reverse-charge lines
• BR-AE-04 applies it to reverse-charge document-level charges
• BR-AE-06 requires the reverse-charge allowance to carry a rate of 0
• BR-E-03 is the exempt allowance rule, which looks at the seller only
• 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-03 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.