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.
| Term | Meaning | UBL element |
|---|---|---|
| BT-118 | VAT category code | cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cbc:ID |
| BG-15 | Deliver to address | cac:Delivery/cac:DeliveryLocation/cac:Address |
| BT-80 | Deliver to country code | cac: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 warningUBL-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:Deliverywhen 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
- 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.
- Write it at
cac:Delivery/cac:DeliveryLocation/cac:Address/cac:Country/cbc:IdentificationCodeas an upper-case ISO 3166-1 alpha-2 code. Street, city and postcode can go in the samecac:Addresswhen you have them. - If the mapping uses
cac:DeliveryAddress, move its content intocac:DeliveryLocation/cac:Addressinstead. - Keep
cbc:ActualDeliveryDatein the samecac:Delivery, ahead ofcac: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
- The failing invoice reports BR-IC-12. 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. 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
Ka deliver-to address is optional, but one that is sent still needs a country underBR-57.
Related rules
- BR-57 requires a country in any deliver-to address, whatever the VAT category
- BR-IC-11 asks for the delivery date or invoicing period on the same document
- UBL-CR-682 warns when the address is sent as cac:DeliveryAddress, where this rule does not look
- BR-CL-14 checks that the deliver-to country code is a valid ISO 3166-1 code
- 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-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.
