# BR-AE-04: Identify the seller and the buyer when a document-level charge is reverse charged
A reverse-charge document-level charge needs the seller tax identifier as well as a buyer VAT or legal registration identifier in the document.
- Layer: EN 16931
- Severity: fatal (the document is invalid)
- Topics: VAT, Parties and addresses, Allowances and charges
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-AE-04/
- Explanation last updated: 2026-09-28
## 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.
| 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-102 | Document level charge VAT category code | `cac:AllowanceCharge[cbc:ChargeIndicator = true]/cac:TaxCategory/cbc:ID` |
## 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.
## 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
```xml
7300010000001
Example Supplier Ltd
12345678
true
FC
Freight
4.00
AE
0
VAT
```
Fragment of the corrected invoice: the seller VAT identifier restored, with the freight charge unchanged
```xml
7300010000001
GB123456789
VAT
Example Supplier Ltd
12345678
```
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.
### What the validator reported
- The failing invoice reports [BR-AE-02](https://ironfang.com/docs/finance/rules/BR-AE-02.md) and **BR-AE-04**. The corrected document passes every layer with no findings.
- [Download the failing XML](https://ironfang.com/finance/rule-examples/BR-AE-04-invalid.xml)
- [Download the corrected XML](https://ironfang.com/finance/rule-examples/reverse-charge-freight-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 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](https://ironfang.com/docs/finance/rules/BR-AE-02.md)
- [BR-AE-03 is the same test for a reverse-charge document-level allowance](https://ironfang.com/docs/finance/rules/BR-AE-03.md)
- [BR-AE-01 requires the one reverse-charge breakdown that takes in the charge](https://ironfang.com/docs/finance/rules/BR-AE-01.md)
- [BR-AE-07 requires the reverse-charge charge to carry a rate of 0](https://ironfang.com/docs/finance/rules/BR-AE-07.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-28.1: source checked 2026-09-28, explanation last updated 2026-09-28.
[The official definition of BR-AE-04](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/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.
## Links
- [This rule as a web page](https://ironfang.com/docs/finance/rules/BR-AE-04)
- [Free Peppol invoice validator](https://ironfang.com/tools/peppol-validator)
- [Rule index](https://ironfang.com/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.com/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.com/mcp