Skip to content

Ironfang Finance - Rule reference

BR-IC-04: Identify the seller and buyer under the VAT scheme when a document charge is intra-community

A document-level charge in category K requires a seller VAT identifier, or a tax representative's, and a buyer VAT identifier, both under the VAT scheme.

EN 16931Fatal: the document is invalidVATParties and addressesAllowances and charges

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.

TermMeaningUBL element
BT-102Document level charge VAT category codecac:AllowanceCharge[cbc:ChargeIndicator = true]/cac:TaxCategory/cbc:ID
BT-31Seller VAT identifiercac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID (tax scheme VAT)
BT-32Seller tax registration identifiercac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID (a tax scheme other than VAT)
BT-63Seller tax representative VAT identifiercac:TaxRepresentativeParty/cac:PartyTaxScheme/cbc:CompanyID
BT-48Buyer VAT identifiercac: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:TaxRepresentativeParty is sent without its cac:PartyTaxScheme.
  • Freight is added to the invoice after the party data was built for a domestic document.

How to fix it

  1. Look at every cac:PartyTaxScheme under the seller party and read its cac:TaxScheme/cbc:ID. The seller VAT number has to be under VAT.
  2. If the number there is the seller VAT identifier, change the scheme to VAT. If it is a national tax number, keep it under TAX and add a second cac:PartyTaxScheme holding the VAT identifier.
  3. If the seller acts through a fiscal representative, send cac:TaxRepresentativeParty with name, postal address and a VAT cac:PartyTaxScheme, after cac:AccountingCustomerParty.
  4. Check the buyer as well: in the recorded example, DE123456789 under VAT in 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

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 gave BR-IC-02 and 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 under TAX, and so would the Standard rated seller check BR-S-02.
  • The rate on the charge is a separate matter for BR-IC-07, and the charge amount must be inside the K taxable amount under BR-IC-08.

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.