The short answer
BR-IC-11 fails when the VAT breakdown has a K category and the document has neither cac:Delivery/cbc:ActualDeliveryDate nor a cac:InvoicePeriod with content, both read directly under the document root. Add the date the goods were delivered, or the period the invoice covers, from the dispatch or billing records.
Periods on lines do not count. Only the document-level delivery and invoicing period are read.
What the rule checks
The trigger is the breakdown, not the lines: the rule applies when any cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory under the VAT scheme has cbc:ID of K. The finding is raised once, at the document root.
The delivery route passes when the document-level cac:Delivery has a cbc:ActualDeliveryDate with a value. An empty date element never reaches this rule: when tried, it failed the XSD layer, because the schema requires a real date.
The period route passes when cac:InvoicePeriod has any child element at all. When tried, a period holding only cbc:StartDate, only cbc:EndDate, or only cbc:DescriptionCode each gave a valid document.
Because any child counts, a period with nothing but cbc:Description gets past this rule, yet that document failed BR-CO-19, which wants a start or end date, and drew the warning UBL-CR-015. An empty cac:InvoicePeriod fails here and also reports BR-CO-19 and PEPPOL-EN16931-R008.
With the delivery date removed and a period of 1 to 30 September added to line 1 only, the rule still failed when tried: a line cac:InvoicePeriod is outside what it reads.
A delivery date and a period together are accepted; the rule needs one of them and objects to neither.
| Term | Meaning | UBL element |
|---|---|---|
| BT-118 | VAT category code | cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cbc:ID |
| BT-72 | Actual delivery date | cac:Delivery/cbc:ActualDeliveryDate |
| BG-14 | Invoicing period | cac:InvoicePeriod |
| BT-73 | Invoicing period start date | cac:InvoicePeriod/cbc:StartDate |
| BT-74 | Invoicing period end date | cac:InvoicePeriod/cbc:EndDate |
How an integration ends up here
Possible causes, from the shape of the rule rather than from measured usage:
- The delivery date is held in a dispatch or warehouse system that the invoice export never joins to.
- The invoice is raised before dispatch, no delivery date exists yet, and no invoicing period is sent in its place.
- The billing period is written on each line for recurring charges but never at document level.
- The export writes
cac:Deliveryonly for the deliver-to address and has no mapping for the date. - The date of supply is sent as
cbc:TaxPointDateor only as the issue date, neither of which this rule reads.
How to fix it
- Take the actual delivery date from the dispatch or proof-of-delivery records, not from the invoice date.
- Write it as
cbc:ActualDeliveryDatein the document-levelcac:Delivery, in the form YYYY-MM-DD and ahead ofcac:DeliveryLocation. In UBL order,cac:Deliverycomes after the parties and beforecac:PaymentMeans. - If the invoice covers a period instead, send
cac:InvoicePeriodwithcbc:StartDateandcbc:EndDate, aftercbc:BuyerReferenceand before any document references and the parties. - Leave the deliver-to country in place in the same
cac:Delivery;BR-IC-12requires it on every document with aKbreakdown.
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 delivery location but no delivery date, and no invoicing period in the document
<cac:Delivery>
<cac:DeliveryLocation>
<cac:Address>
<cbc:CityName>Berlin</cbc:CityName>
<cac:Country>
<cbc:IdentificationCode>DE</cbc:IdentificationCode>
</cac:Country>
</cac:Address>
</cac:DeliveryLocation>
</cac:Delivery>
<!-- VAT breakdown with category K omitted from this fragment -->Fragment of the corrected invoice: the actual delivery date opens the delivery block
<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 cbc:ActualDeliveryDate 2026-09-07 as the first child of cac:Delivery; the failing invoice keeps the deliver-to location without a date, and neither document has a cac:InvoicePeriod. The failing document reports only BR-IC-11, because the deliver-to country that BR-IC-12 looks for is still there.
What the validator reported
- The failing invoice reports BR-IC-11. 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. The failing invoice rewritten as a credit note gave the same finding when tried. - Removing
cac:Deliveryaltogether reportedBR-IC-11andBR-IC-12together when tried, since the deliver-to country goes with the date. - The rule does not compare the delivery date with the issue date or with any period.
BR-29separately requires a period end date that is not before its start date.
Related rules
- BR-IC-12 needs the deliver-to country in the same cac:Delivery block
- BR-CO-19 rejects an invoicing period that has neither a start date nor an end date
- BR-29 checks that an invoicing period does not end before it starts
- BR-IC-02 checks the seller and buyer VAT identifiers on the same kind of document
- 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-11 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.
