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

A document with a reverse-charge line needs a seller tax identifier and, for the buyer, a VAT identifier or a legal registration identifier.

- Layer: EN 16931
- Severity: fatal (the document is invalid)
- Topics: VAT, Parties and addresses
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-AE-02/
- Explanation last updated: 2026-09-24

## 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.

| Term | Meaning | UBL element |
|---|---|---|
| BT-31 | Seller VAT identifier | `cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID (tax scheme VAT)` |
| BT-32 | Seller tax registration identifier | `cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID (a tax scheme other than VAT)` |
| BT-63 | Seller tax representative VAT identifier | `cac:TaxRepresentativeParty/cac:PartyTaxScheme/cbc:CompanyID` |
| BT-48 | Buyer VAT identifier | `cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID (tax scheme VAT)` |
| BT-47 | Buyer legal registration identifier | `cac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity/cbc:CompanyID` |
| BT-151 | Invoiced item VAT category code | `cac:InvoiceLine/cac:Item/cac:ClassifiedTaxCategory/cbc:ID (cac:CreditNoteLine/cac:Item/cac:ClassifiedTaxCategory/cbc:ID in a credit note)` |

## 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.

## 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

```xml
<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

```xml
<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.

### What the validator reported

- The failing invoice reports **BR-AE-02**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/BR-AE-02-invalid.xml)
  - [Download the corrected XML](https://ironfang.uk/finance/rule-examples/reverse-charge-valid.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

- 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](https://ironfang.uk/docs/finance/rules/BR-S-02.md)
- [BR-AE-10 requires the reverse-charge reason in the VAT breakdown](https://ironfang.uk/docs/finance/rules/BR-AE-10.md)
- [BR-CO-09 checks the country prefix on the seller and buyer VAT identifiers](https://ironfang.uk/docs/finance/rules/BR-CO-09.md)
- [BR-AE-05 requires every reverse-charge line to carry a rate of 0](https://ironfang.uk/docs/finance/rules/BR-AE-05.md)

## 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](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/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.

## Links

- [This rule as a web page](https://ironfang.uk/docs/finance/rules/BR-AE-02)
- [Free Peppol invoice validator](https://ironfang.uk/tools/peppol-validator)
- [Rule index](https://ironfang.uk/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.uk/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.uk/mcp