Skip to content

Ironfang Finance - Rule reference

BR-AE-06: Set the VAT rate of a reverse-charge document allowance to 0

A document-level allowance in VAT category AE must carry a rate of exactly 0; a discount on a reverse-charge supply cannot keep the seller's own rate.

EN 16931Fatal: the document is invalidVATAllowances and charges

On this page

The short answer

BR-AE-06 fails when a cac:AllowanceCharge with cbc:ChargeIndicator of false has a cac:TaxCategory whose cbc:ID is AE and whose cbc:Percent is not 0. In the recorded example the framework agreement discount of 1.50 carries 20; set it to 0, as the reverse-charge line and breakdown already are.

A discount follows the VAT treatment of the supply it reduces. The seller charges no VAT on a reverse-charge service, so there is no VAT to take off the discount either.

What the rule checks

The rule selects each cac:TaxCategory inside an allowance, cbc:ChargeIndicator of false, whose cbc:ID is AE under the VAT scheme, and reports at that cac:TaxCategory. Reverse-charge charges are left to BR-AE-07.

The rate must equal zero as a number. When tried, 0.00 on the discount passed every layer, while leaving cbc:Percent out of the discount failed this rule on its own: an absent rate does not count as zero.

An empty cbc:Percent element never reaches this rule. When tried, the XSD layer rejected it and the business rules were skipped.

The discount still counts towards the reverse-charge taxable amount at the wrong rate. With 20 on it, the breakdown of 28.50 was accepted by BR-AE-08, which adds up AE allowances whatever rate they carry.

The selection is not limited to the document level. When tried, a line-level allowance with its own cac:TaxCategory of AE at 20 was reported under this rule too, beside the warning UBL-CR-558, which says line allowances should not carry a tax category at all.

TermMeaningUBL element
BT-95Document level allowance VAT category codecac:AllowanceCharge[cbc:ChargeIndicator = false]/cac:TaxCategory/cbc:ID
BT-96Document level allowance VAT ratecac:AllowanceCharge[cbc:ChargeIndicator = false]/cac:TaxCategory/cbc:Percent

How an integration ends up here

Possible causes, from the shape of the rule rather than from measured usage:

  • The discount is created from a default allowance tax code that holds the domestic Standard rate, and only its category is switched to AE for a reverse-charge customer.
  • Allowances copy the category from the lines but take the rate from a separate discount setting.
  • The rate is kept to show what the discount would be worth in VAT, which the document has no field for.
  • An allowance built for a Standard rated invoice is reused on a reverse-charge one with only the category code changed.

How to fix it

  1. Confirm that the discount reduces a supply that is itself under reverse charge. If it does, keep category AE on the allowance.
  2. Set cbc:Percent in the allowance's cac:TaxCategory to 0, between cbc:ID and cac:TaxScheme. The allowance amount, the reverse-charge taxable amount and the totals stay as they are.
  3. Give the reverse-charge allowance tax code a rate of 0 at source, so the next discount on a reverse-charge document is generated correctly.
  4. If the discount belongs to Standard rated items on the same invoice, code it S with their rate instead. It then reduces the Standard rated taxable amount under BR-S-08, not the reverse-charge one.

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 discount with a rate of 20

<cac:AllowanceCharge>
  <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReasonCode>95</cbc:AllowanceChargeReasonCode>
  <cbc:AllowanceChargeReason>Framework agreement discount</cbc:AllowanceChargeReason>
  <cbc:Amount currencyID="GBP">1.50</cbc:Amount>
  <cac:TaxCategory>
    <cbc:ID>AE</cbc:ID>
    <cbc:Percent>20</cbc:Percent>
    <cac:TaxScheme>
      <cbc:ID>VAT</cbc:ID>
    </cac:TaxScheme>
  </cac:TaxCategory>
</cac:AllowanceCharge>

Fragment of the corrected invoice: the same discount at 0

<cac:AllowanceCharge>
  <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReasonCode>95</cbc:AllowanceChargeReasonCode>
  <cbc:AllowanceChargeReason>Framework agreement discount</cbc:AllowanceChargeReason>
  <cbc:Amount currencyID="GBP">1.50</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>

Only the rate of the framework agreement discount differs: 20 in the failing invoice, 0 in the corrected one. The failing document reports only BR-AE-06; the call-out charge beside the discount is already at 0, and the reverse-charge breakdown of 28.50 still adds up.

What the validator reported

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. The failing invoice converted to a credit note reported the same finding at the same allowance when tried.
  • Reported by the EN 16931 layer as a fatal finding for each reverse-charge allowance whose rate is not zero.
  • The other places a reverse-charge rate appears have their own rules: BR-AE-05 for lines and BR-AE-07 for document-level charges. An AE allowance also brings in the party identifier check BR-AE-03.

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