# BR-AE-03: Identify the seller and the buyer when a document-level allowance is reverse charged
A reverse-charge document-level allowance 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, Allowances and charges
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-AE-03/
- Explanation last updated: 2026-09-28
## 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.
| 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-95 | Document level allowance VAT category code | `cac:AllowanceCharge[cbc:ChargeIndicator = false]/cac:TaxCategory/cbc:ID` |
## 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.
## 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
```xml
7300010000001
Example Buyer Ltd
false
95
Volume discount
3.00
AE
0
VAT
```
Fragment of the corrected invoice: the buyer VAT identifier and legal registration identifier are both back
```xml
7300010000001
DE123456789
VAT
Example Buyer Ltd
87654321
```
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.
### What the validator reported
- The failing invoice reports [BR-AE-02](https://ironfang.com/docs/finance/rules/BR-AE-02.md) and **BR-AE-03**. The corrected document passes every layer with no findings.
- [Download the failing XML](https://ironfang.com/finance/rule-examples/BR-AE-03-invalid.xml)
- [Download the corrected XML](https://ironfang.com/finance/rule-examples/reverse-charge-discount-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 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](https://ironfang.com/docs/finance/rules/BR-AE-02.md)
- [BR-AE-04 applies it to reverse-charge document-level charges](https://ironfang.com/docs/finance/rules/BR-AE-04.md)
- [BR-AE-06 requires the reverse-charge allowance to carry a rate of 0](https://ironfang.com/docs/finance/rules/BR-AE-06.md)
- [BR-E-03 is the exempt allowance rule, which looks at the seller only](https://ironfang.com/docs/finance/rules/BR-E-03.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-03](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/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.
## Links
- [This rule as a web page](https://ironfang.com/docs/finance/rules/BR-AE-03)
- [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