# BR-AE-07: Give a reverse-charge document charge a VAT rate of 0

A document-level charge in VAT category `AE` needs a `cbc:Percent` of exactly 0 in its tax category, and leaving the rate out fails as well.

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

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

1. 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 `AE` stays.
2. Write `cbc:Percent` with the value `0` in the charge's `cac:TaxCategory`, after `cbc:ID` and before `cac:TaxScheme`, replacing any other rate that is there.
3. 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.
4. 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.

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

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

```xml
<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 XML](https://ironfang.com/finance/rule-examples/BR-AE-07-invalid.xml)
  - [Download the corrected XML](https://ironfang.com/finance/rule-examples/reverse-charge-adjustments-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`. As a credit note, the failing invoice reported the same finding at the second `cac:AllowanceCharge` when 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 under `BR-37`.

## Related rules

- [BR-AE-06 asks for the same rate of 0 on a reverse-charge document allowance](https://ironfang.com/docs/finance/rules/BR-AE-06.md)
- [BR-AE-04 checks the seller and buyer identifiers that a reverse-charge charge requires](https://ironfang.com/docs/finance/rules/BR-AE-04.md)
- [BR-AE-08 adds this charge into the reverse-charge taxable amount](https://ironfang.com/docs/finance/rules/BR-AE-08.md)
- [BR-IC-07 is the zero-rate rule for a charge on an intra-community supply](https://ironfang.com/docs/finance/rules/BR-IC-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-07](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/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.

## Links

- [This rule as a web page](https://ironfang.com/docs/finance/rules/BR-AE-07)
- [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