On this page
The short answer
BR-AE-07 fails when a cac:AllowanceCharge with cbc:ChargeIndicator of true has a cac:TaxCategory in category AE whose rate is not zero. In the recorded example the call-out charge of 5.00 has no cbc:Percent at all; add <cbc:Percent>0</cbc:Percent> directly after its cbc:ID.
Leaving the rate out is not the same as stating zero. The rule reads the value of cbc:Percent, and with no element there is no value that equals 0.
What the rule checks
It looks at every cac:TaxCategory inside a charge, cbc:ChargeIndicator of true, whose cbc:ID is AE under the VAT scheme, and reports each failure at that cac:TaxCategory. Reverse-charge allowances are checked by BR-AE-06.
A rate that is present must be zero as a number: 0 and 0.00 both passed when tried, and rates of 5 and 20 on the call-out charge each failed this rule and nothing else.
With cbc:Percent missing from the charge, this rule was the only finding in the recorded example: no other rule reported the absent rate.
The charge rate is not compared with the breakdown rate, and it does not change the sum. With the charge at 20, the reverse-charge taxable amount of 28.50 still satisfied BR-AE-08 when tried, since that rule counts AE charges at any rate.
| Term | Meaning | UBL element |
|---|---|---|
| BT-102 | Document level charge VAT category code | cac:AllowanceCharge[cbc:ChargeIndicator = true]/cac:TaxCategory/cbc:ID |
| BT-103 | Document level charge VAT rate | cac:AllowanceCharge[cbc:ChargeIndicator = true]/cac:TaxCategory/cbc:Percent |
How an integration ends up here
Possible causes, from the shape of the rule rather than from measured usage:
- The charge is added by a template that writes the category code but has no field for its rate, on the assumption that a reverse-charge rate says nothing.
- Empty values are dropped when serialising, and the call-out fee's tax code had its rate left blank.
- The charge rate is taken from the domestic fee setup, which holds the Standard rate, while the category follows the customer's reverse-charge flag.
- Surcharges are generated by a different module from the lines and never received the rule that sets reverse-charge rates to 0.
How to fix it
- Check that the charge is part of the reverse-charge supply, such as a call-out or travel fee for the same service. If it is, category
AEstays. - Write
cbc:Percentwith the value0in the charge'scac:TaxCategory, aftercbc:IDand beforecac:TaxScheme, replacing any other rate that is there. - Leave the charge amount and the reverse-charge taxable amount alone; in the recorded example they are already consistent at 5.00 and 28.50.
- Make the serialiser write a zero rate rather than dropping it, and set the reverse-charge fee tax code to 0 so every future charge carries it.
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 reverse-charge call-out charge with no rate
<cac:AllowanceCharge>
<cbc:ChargeIndicator>true</cbc:ChargeIndicator>
<cbc:AllowanceChargeReason>Call-out charge</cbc:AllowanceChargeReason>
<cbc:Amount currencyID="GBP">5.00</cbc:Amount>
<cac:TaxCategory>
<cbc:ID>AE</cbc:ID>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:TaxCategory>
</cac:AllowanceCharge>Fragment of the corrected invoice: the rate of 0 sits between the category and the tax scheme
<cac:AllowanceCharge>
<cbc:ChargeIndicator>true</cbc:ChargeIndicator>
<cbc:AllowanceChargeReason>Call-out charge</cbc:AllowanceChargeReason>
<cbc:Amount currencyID="GBP">5.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>The corrected invoice has <cbc:Percent>0</cbc:Percent> in the tax category of the call-out charge; the failing invoice has no rate element there, and nothing else differs. The failing document reports only BR-AE-07.
What the validator reported
- The failing invoice reports BR-AE-07. The corrected document passes every layer with no findings.Download the failing XMLDownload the corrected 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
InvoiceandCreditNote. As a credit note, the failing invoice reported the same finding at the secondcac:AllowanceChargewhen tried. - Reported by the EN 16931 layer, once for each reverse-charge charge that fails.
- A reverse-charge charge also needs party identifiers under
BR-AE-04, and every document-level charge needs a VAT category code underBR-37.
Related rules
- BR-AE-06 asks for the same rate of 0 on a reverse-charge document allowance
- BR-AE-04 checks the seller and buyer identifiers that a reverse-charge charge requires
- BR-AE-08 adds this charge into the reverse-charge taxable amount
- BR-IC-07 is the zero-rate rule for a charge on an intra-community supply
- 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-07 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.

