BR-IC-02: Add the seller and buyer VAT identifiers to an intra-community supply

The short answer

BR-IC-02 fails when a line is classified K, intra-community supply, and the document is missing a VAT identifier on one side. The seller side needs cbc:CompanyID in a VAT cac:PartyTaxScheme under cac:AccountingSupplierParty/cac:Party, or under cac:TaxRepresentativeParty; the buyer side needs the same under cac:AccountingCustomerParty/cac:Party. Add whichever is missing.

The finding does not say which side is at fault, so check both. In the recorded example it is the buyer VAT identifier, and the buyer company registration number that the document still carries is no substitute for it.

What the rule checks

The trigger is a line: any cac:ClassifiedTaxCategory with cbc:ID of K under the VAT tax scheme, which in UBL sits in the cac:Item of an invoice or credit note line. A K VAT breakdown or document-level allowance does not set the rule off by itself, because those use cac:TaxCategory.

Once triggered, two things must both be present. Seller side: a VAT identifier for the seller, or one for the seller tax representative; either will do. Buyer side: a VAT identifier for the buyer, with no alternative.

Only a cac:PartyTaxScheme whose cac:TaxScheme/cbc:ID is VAT counts, on both sides. When tried, the buyer identifier DE123456789 placed under the scheme TAX still reported BR-IC-02. The Standard rated check BR-S-02 is looser on the seller side and accepts a tax registration under any scheme.

Legal registration identifiers play no part. The failing invoice keeps the buyer cac:PartyLegalEntity/cbc:CompanyID of 87654321 and fails regardless. Reverse charge is different: BR-AE-02 accepts a buyer legal registration identifier instead of a buyer VAT identifier.

The rule tests presence, not content. An empty buyer cbc:CompanyID satisfied it when tried and was reported by PEPPOL-EN16931-R008 instead. A buyer VAT identifier with a GB prefix, the same country as the seller, passed every layer: the two countries are never compared.

There is one finding per document, located at the root, whether one identifier is missing or both.

How an integration ends up here

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

• The buyer VAT number is on the customer record but the export maps it only for reverse-charge documents, not for intra-community supplies.
• The customer master holds a company registration number and nothing else, so the buyer ends up with cac:PartyLegalEntity/cbc:CompanyID and no cac:PartyTaxScheme.
• The buyer VAT identifier is written under a tax scheme code other than VAT, taken from a generic tax-type field in the source system.
• The seller invoices through a tax representative, and the cac:TaxRepresentativeParty is sent without its own cac:PartyTaxScheme while the seller identifier is also left out.
• Category K is assigned from the delivery country alone, so a buyer who never supplied a VAT number still gets K. Then the category decision is what needs fixing.

How to fix it

1. Look at both parties. Under cac:AccountingSupplierParty/cac:Party and cac:AccountingCustomerParty/cac:Party, find a cac:PartyTaxScheme whose cac:TaxScheme/cbc:ID is VAT and whose cbc:CompanyID has a value.
2. For the buyer, take the VAT identifier the buyer gave you, stored on the customer record, in full with its country prefix. If there is none, go back to the tax determination: category K assumes a buyer VAT number, and neither a copied nor a guessed number is a fix.
3. Write it as cac:PartyTaxScheme with cbc:CompanyID and cac:TaxScheme/cbc:ID of VAT, after cac:PostalAddress and before cac:PartyLegalEntity. Placed after the legal entity, it failed the XSD layer when tried, and the EN 16931 rules were skipped.
4. For the seller, send the seller VAT identifier in the same structure. If the seller is represented, a cac:TaxRepresentativeParty with name, postal address and a VAT cac:PartyTaxScheme also satisfies the seller side: when tried, it made the document valid without a seller VAT identifier.

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: the buyer has a legal registration identifier but no VAT identifier

<cac:AccountingCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <!-- postal address in Berlin, DE, omitted from this fragment -->
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Example Buyer Ltd</cbc:RegistrationName>
      <cbc:CompanyID>87654321</cbc:CompanyID>
    </cac:PartyLegalEntity>
  </cac:Party>
</cac:AccountingCustomerParty>

Fragment of the corrected invoice: the buyer VAT identifier sits between the address and the legal entity

<cac:AccountingCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <!-- postal address in Berlin, DE, omitted from this fragment -->
    <cac:PartyTaxScheme>
      <cbc:CompanyID>DE123456789</cbc:CompanyID>
      <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
      </cac:TaxScheme>
    </cac:PartyTaxScheme>
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Example Buyer Ltd</cbc:RegistrationName>
      <cbc:CompanyID>87654321</cbc:CompanyID>
    </cac:PartyLegalEntity>
  </cac:Party>
</cac:AccountingCustomerParty>

The corrected invoice gives the buyer a cac:PartyTaxScheme holding DE123456789 under the VAT scheme; the failing invoice has no buyer VAT identifier. The seller VAT identifier GB123456789 and the K line are the same in both. The failing document reports only BR-IC-02, even though the buyer legal registration identifier is still there.

Where it applies

• Applies to UBL Invoice and CreditNote. The failing invoice converted to a credit note, with cac:CreditNoteLine for its line, reported the same single finding when tried.
• Reported by the EN 16931 layer, which runs only after the XSD layer passes. A cac:PartyTaxScheme in the wrong position fails the schema first and hides this rule.
• The other intra-community rules are separate findings: BR-IC-10 for the exemption reason, BR-IC-11 for the delivery date or invoicing period and BR-IC-12 for the deliver-to country. BR-CO-09 then checks the country prefix of the identifiers you add.
• Validation checks that the identifiers are there, not that they are registered. Confirming a buyer VAT number, for example through the EU VIES service, is a separate step.

Related rules

• BR-AE-02 is the reverse-charge counterpart, which also accepts a buyer legal registration identifier
• BR-G-02 asks only for the seller side when the line is an export outside the EU
• BR-CO-09 checks the country prefix on the VAT identifiers this rule requires
• BR-IC-12 is the next requirement on the same document: the deliver-to country
• 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-24.1: source checked 2026-09-24, explanation last updated 2026-09-24.

The official definition of BR-IC-02 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.