Skip to content

BR-IC-12: Add the deliver-to country to an intra-community supply

A document with a K VAT breakdown must give the country the goods were delivered to, in the deliver-to address under cac:Delivery/cac:DeliveryLocation.

EN 16931Fatal: the document is invalidVATParties and addresses

The short answer

BR-IC-12 fails when the VAT breakdown has a K category and there is no country code at cac:Delivery/cac:DeliveryLocation/cac:Address/cac:Country/cbc:IdentificationCode under the document root. Add the deliver-to address with the ISO 3166-1 code of the country the goods went to: DE in the recorded example.

The path is exact. A country in cac:Delivery/cac:DeliveryAddress, or in the buyer postal address, does not satisfy it.

What the rule checks

A K category in the document-level VAT breakdown, under the VAT scheme, is what brings the rule into play; the lines are not consulted. It reports once, at the root.

It reads a single location: the cbc:IdentificationCode in cac:Country of cac:Address in cac:DeliveryLocation of the document-level cac:Delivery, and the value there must be longer than one character.

The buyer address is not used as a fallback. The failing invoice has a buyer in Berlin with country DE and still fails.

The country alone is enough. When tried, a cac:DeliveryLocation/cac:Address holding only cac:Country gave a valid document; the city in the recorded example is optional.

The code is not compared with anything. A deliver-to country of GB, the same as the seller, passed every layer when tried, so the rule will not flag a supply marked K that never left the seller country.

Whether the code is a real country is left to BR-CL-14. With de in lower case this rule passed and BR-CL-14 failed; an empty code failed this rule, BR-CL-14 and PEPPOL-EN16931-R008 together.

An address with no cac:Country fails this rule and BR-57, which wants a country in every deliver-to address.

TermMeaningUBL element
BT-118VAT category codecac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cbc:ID
BG-15Deliver to addresscac:Delivery/cac:DeliveryLocation/cac:Address
BT-80Deliver to country codecac:Delivery/cac:DeliveryLocation/cac:Address/cac:Country/cbc:IdentificationCode

How an integration ends up here

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

  • The mapping writes the destination to cac:Delivery/cac:DeliveryAddress, an element UBL has but Peppol does not use. When tried, that reported this rule plus the warning UBL-CR-682.
  • Only a deliver-to party name is sent, in cac:DeliveryParty, with no location. That also failed when tried.
  • The export leaves out cac:Delivery when the goods go to the buyer address, assuming the buyer address covers it.
  • The deliver-to address is mapped without a country, because the source holds the country only on the customer record.

How to fix it

  1. Take the destination country from the shipping or dispatch record. It can differ from the buyer address; use where the goods were delivered, not where the invoice is addressed.
  2. Write it at cac:Delivery/cac:DeliveryLocation/cac:Address/cac:Country/cbc:IdentificationCode as an upper-case ISO 3166-1 alpha-2 code. Street, city and postcode can go in the same cac:Address when you have them.
  3. If the mapping uses cac:DeliveryAddress, move its content into cac:DeliveryLocation/cac:Address instead.
  4. Keep cbc:ActualDeliveryDate in the same cac:Delivery, ahead of cac:DeliveryLocation. With the date after the location, the document failed the XSD layer when tried.

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 delivery block has a date and no deliver-to location

<cac:Delivery>
  <cbc:ActualDeliveryDate>2026-09-07</cbc:ActualDeliveryDate>
</cac:Delivery>

Fragment of the corrected invoice: the deliver-to address in Berlin with country DE

<cac:Delivery>
  <cbc:ActualDeliveryDate>2026-09-07</cbc:ActualDeliveryDate>
  <cac:DeliveryLocation>
    <cac:Address>
      <cbc:CityName>Berlin</cbc:CityName>
      <cac:Country>
        <cbc:IdentificationCode>DE</cbc:IdentificationCode>
      </cac:Country>
    </cac:Address>
  </cac:DeliveryLocation>
</cac:Delivery>

The corrected invoice has a cac:DeliveryLocation with an address in Berlin and country DE inside cac:Delivery; the failing invoice has only the delivery date there. The failing document reports only BR-IC-12. Its buyer postal address also says DE, which shows that the rule does not borrow the buyer country.

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. Converted to a credit note, the failing invoice produced the same finding when tried.
  • Reported by the EN 16931 layer, so any XSD failure in the document, such as elements in the wrong order inside cac:Delivery, stops it from being reported.
  • Outside category K a deliver-to address is optional, but one that is sent still needs a country under BR-57.

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