Skip to content

BR-IC-11: Add a delivery date or invoicing period to an intra-community supply

When the VAT breakdown includes category K, the document needs an actual delivery date or an invoicing period at document level.

EN 16931Fatal: the document is invalidVATCore fields

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.

TermMeaningUBL element
BT-118VAT category codecac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cbc:ID
BT-72Actual delivery datecac:Delivery/cbc:ActualDeliveryDate
BG-14Invoicing periodcac:InvoicePeriod
BT-73Invoicing period start datecac:InvoicePeriod/cbc:StartDate
BT-74Invoicing period end datecac: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:Delivery only for the deliver-to address and has no mapping for the date.
  • The date of supply is sent as cbc:TaxPointDate or only as the issue date, neither of which this rule reads.

How to fix it

  1. Take the actual delivery date from the dispatch or proof-of-delivery records, not from the invoice date.
  2. Write it as cbc:ActualDeliveryDate in the document-level cac:Delivery, in the form YYYY-MM-DD and ahead of cac:DeliveryLocation. In UBL order, cac:Delivery comes after the parties and before cac:PaymentMeans.
  3. If the invoice covers a period instead, send cac:InvoicePeriod with cbc:StartDate and cbc:EndDate, after cbc:BuyerReference and before any document references and the parties.
  4. Leave the deliver-to country in place in the same cac:Delivery; BR-IC-12 requires it on every document with a K breakdown.

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

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. The failing invoice rewritten as a credit note gave the same finding when tried.
  • Removing cac:Delivery altogether reported BR-IC-11 and BR-IC-12 together 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-29 separately requires a period end date that is not before its start date.

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.