On this page
The short answer
BR-IC-04 fails when a document-level charge, cbc:ChargeIndicator of true, is in category K and the document does not identify the seller side and the buyer under the VAT scheme. In the recorded example the freight charge of 6.00 is in K, and the seller's GB123456789 sits in a cac:PartyTaxScheme whose scheme is TAX; changing that scheme to VAT fixes it.
A number under TAX is a seller tax registration identifier, not a seller VAT identifier. For the seller side, that distinction is what this rule turns on, while some other VAT category rules accept either.
What the rule checks
The rule fires on any cac:AllowanceCharge with cbc:ChargeIndicator of true whose cac:TaxCategory has cbc:ID of K under the VAT scheme, and reports once, at the root.
On the seller side, only a cbc:CompanyID in a seller cac:PartyTaxScheme with scheme VAT counts, or one in cac:TaxRepresentativeParty with scheme VAT. When tried, removing the seller cac:PartyTaxScheme altogether gave the same two findings as the TAX scheme did.
A seller with both schemes passes. When tried, adding a VAT cac:PartyTaxScheme with GB123456789 next to the TAX one made the failing invoice valid.
A tax representative satisfies the seller side on its own. When tried, a German cac:TaxRepresentativeParty with DE987654321 under VAT, added to the failing invoice with the seller still under TAX, made it valid.
The buyer side has no alternative: it needs a buyer cac:PartyTaxScheme/cbc:CompanyID under VAT. Removing it from the valid freight invoice reported this rule and BR-IC-02 when tried.
The charge triggers the rule without any K line. When tried with the only line moved to category Z and the breakdowns adjusted to match, the freight in K reported this rule without BR-IC-02.
| Term | Meaning | UBL element |
|---|---|---|
| BT-102 | Document level charge VAT category code | cac:AllowanceCharge[cbc:ChargeIndicator = true]/cac:TaxCategory/cbc:ID |
| 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) |
How an integration ends up here
Possible causes, from the shape of the rule rather than from measured usage:
- The seller's VAT number is configured under a generic tax scheme code,
TAX, which domestic Standard rated invoices accept. - The seller holds a national tax number as well as a VAT number, and the export writes only the first one it finds.
- The seller uses a fiscal representative in the destination country, and
cac:TaxRepresentativePartyis sent without itscac:PartyTaxScheme. - Freight is added to the invoice after the party data was built for a domestic document.
How to fix it
- Look at every
cac:PartyTaxSchemeunder the seller party and read itscac:TaxScheme/cbc:ID. The seller VAT number has to be underVAT. - If the number there is the seller VAT identifier, change the scheme to
VAT. If it is a national tax number, keep it underTAXand add a secondcac:PartyTaxSchemeholding the VAT identifier. - If the seller acts through a fiscal representative, send
cac:TaxRepresentativePartywith name, postal address and aVATcac:PartyTaxScheme, aftercac:AccountingCustomerParty. - Check the buyer as well: in the recorded example,
DE123456789underVATin the buyer party already satisfies the buyer side.
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 freight charge in category K, and the seller number under the tax scheme TAX
<cac:AccountingSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
<!-- postal address in London, GB, omitted from this fragment -->
<cac:PartyTaxScheme>
<cbc:CompanyID>GB123456789</cbc:CompanyID>
<cac:TaxScheme>
<cbc:ID>TAX</cbc:ID>
</cac:TaxScheme>
</cac:PartyTaxScheme>
<!-- legal entity omitted from this fragment -->
</cac:Party>
</cac:AccountingSupplierParty>
<!-- buyer and delivery omitted from this fragment -->
<cac:AllowanceCharge>
<cbc:ChargeIndicator>true</cbc:ChargeIndicator>
<cbc:AllowanceChargeReasonCode>FC</cbc:AllowanceChargeReasonCode>
<cbc:AllowanceChargeReason>Freight to Berlin</cbc:AllowanceChargeReason>
<cbc:Amount currencyID="GBP">6.00</cbc:Amount>
<cac:TaxCategory>
<cbc:ID>K</cbc:ID>
<cbc:Percent>0</cbc:Percent>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:TaxCategory>
</cac:AllowanceCharge>Fragment of the corrected invoice: the same seller number under the VAT scheme
<cac:AccountingSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
<!-- postal address in London, GB, omitted from this fragment -->
<cac:PartyTaxScheme>
<cbc:CompanyID>GB123456789</cbc:CompanyID>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:PartyTaxScheme>
<!-- legal entity omitted from this fragment -->
</cac:Party>
</cac:AccountingSupplierParty>
<!-- the K freight charge of 6.00 is unchanged -->Only the seller's tax scheme differs: TAX in the failing invoice, VAT in the corrected one, with GB123456789 in both. The failing document reports BR-IC-02 as well as BR-IC-04, since its line is in category K and meets the same seller-side test.
What the validator reported
- The failing invoice reports BR-IC-02 and BR-IC-04. 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 gaveBR-IC-02and this rule when tried. - Reported by the EN 16931 layer once per document, at the root.
- The reverse-charge rule for charges,
BR-AE-04, would accept the seller number underTAX, and so would the Standard rated seller checkBR-S-02. - The rate on the charge is a separate matter for
BR-IC-07, and the charge amount must be inside theKtaxable amount underBR-IC-08.
Related rules
- BR-IC-02 applies the same seller and buyer test to K lines and is reported beside this rule
- BR-IC-03 is the identifier rule for a K document allowance, shown with the buyer side missing
- BR-AE-04 is the reverse-charge version for document charges, which accepts a seller identifier under any scheme
- BR-IC-07 requires the same K charge to carry a rate of 0
- 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-IC-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.

