BR-IC-03: Add the VAT identifiers that an intra-community document allowance requires

The short answer

BR-IC-03 fails when a document-level allowance, cbc:ChargeIndicator of false, has tax category K and the document lacks a VAT identifier for the seller side or for the buyer. In the recorded example the full pallet discount of 1.25 is in K and the buyer has no cac:PartyTaxScheme; adding the buyer VAT identifier DE123456789 under the VAT scheme fixes it.

An intra-community discount normally sits beside K lines, so BR-IC-02 arrives with it, as it does here. One missing identifier gives both findings, and adding it clears both.

What the rule checks

The trigger is any cac:AllowanceCharge with cbc:ChargeIndicator of false whose cac:TaxCategory is K under the VAT scheme. The finding is raised once, at the document root.

The allowance is enough without any K line. When tried, the recorded failing invoice with its line moved to category Z, and the breakdowns adjusted to match, reported this rule and not BR-IC-02.

The identifiers asked for are those a K line needs: on the seller side a VAT cac:PartyTaxScheme/cbc:CompanyID for the seller or for a tax representative, and on the buyer side a VAT cac:PartyTaxScheme/cbc:CompanyID for the buyer.

A buyer legal registration identifier is no substitute. The failing invoice keeps 87654321 in the buyer cac:PartyLegalEntity and still fails, whereas the reverse-charge allowance rule BR-AE-03 would accept it.

A buyer number under another scheme does not count either. When tried, DE123456789 with the tax scheme TAX reported this rule and BR-IC-02, exactly as its absence did.

How an integration ends up here

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

• The buyer VAT number is mapped only for reverse-charge documents, and the export fills the parties of an intra-community supply as if it were domestic.
• The customer was set up for EU deliveries by delivery country alone, and its VAT number was never collected.
• The discount takes category K from the lines, while the buyer party comes from an order record that has no tax fields.
• The buyer VAT number is held on a contact or delivery record that the invoice export does not read.

How to fix it

1. Confirm that the discount belongs to the intra-community supply. A discount on K goods takes category K and a rate of 0.
2. Take the buyer VAT identifier from the customer record, with its country prefix, and write it as cac:PartyTaxScheme with cbc:CompanyID and cac:TaxScheme/cbc:ID of VAT, between cac:PostalAddress and cac:PartyLegalEntity in the buyer party.
3. Check the seller side at the same time: the seller cac:PartyTaxScheme must use the VAT scheme, or a cac:TaxRepresentativeParty must carry a VAT identifier. BR-IC-04 shows the seller side failing.
4. If the buyer has no VAT number, take the category of the lines and the discount back to the tax determination rather than inventing an 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: a discount in category K, and a buyer with 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>
<!-- delivery omitted from this fragment -->
<cac:AllowanceCharge>
  <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReasonCode>95</cbc:AllowanceChargeReasonCode>
  <cbc:AllowanceChargeReason>Full pallet discount</cbc:AllowanceChargeReason>
  <cbc:Amount currencyID="GBP">1.25</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 buyer VAT identifier DE123456789 under the VAT scheme

<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 K discount of 1.25 is unchanged -->

The corrected invoice gives the buyer DE123456789 in a VAT cac:PartyTaxScheme; the failing invoice has no buyer VAT identifier, and the discount of 1.25 in K is the same in both. Besides BR-IC-03, the failing document reports BR-IC-02, because its line is also in category K.

Where it applies

• Applies to UBL Invoice and CreditNote. Converted to a credit note, the failing invoice reported BR-IC-02 and this rule when tried.
• Reported by the EN 16931 layer as one fatal finding at the root, whichever side is missing.
• Charges in K have the same requirement under BR-IC-04, and lines under BR-IC-02. The reverse-charge equivalent for allowances, BR-AE-03, also accepts a seller identifier under any scheme and a buyer legal registration identifier.

Related rules

• BR-IC-02 makes the same identifier demand for K lines and is reported beside this rule
• BR-IC-04 is the identifier rule for a K document charge, shown with the seller side missing
• BR-AE-03 is the looser reverse-charge version for document allowances
• BR-IC-06 requires the same K discount 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-03 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.