BR-CO-19: Give the invoicing period a start date, an end date or both

The short answer

BR-CO-19 fails when the document-level cac:InvoicePeriod has neither a cbc:StartDate nor a cbc:EndDate. Add the dates of the period the invoice covers, or remove cac:InvoicePeriod if the invoice does not relate to a period.

Text such as August 2026 in cbc:Description does not satisfy the rule, and that element is outside the EN 16931 model anyway. The one exception is a period whose only content is a VAT point date code in cbc:DescriptionCode, which is a different piece of information from the period itself.

What the rule checks

The rule reads the cac:InvoicePeriod beneath the document root. It passes if the period holds a start date, an end date or both; when tried, a period with only cbc:StartDate, and one with only cbc:EndDate, were each accepted.

It also passes when the period holds a cbc:DescriptionCode and no dates. That code is the VAT point date code (BT-8), which the UBL binding places inside the invoicing period; when tried, a period containing only code 3 passed every layer.

Nothing else in the period counts. A cbc:Description on its own fails, and an empty <cac:InvoicePeriod/> fails too, together with PEPPOL-EN16931-R008 for the empty element.

An empty cbc:StartDate or cbc:EndDate never reaches this rule: a date element with no value is invalid against the UBL schema, so the XSD layer fails and the business rules are skipped.

Line periods are checked by BR-CO-20, which has no exception for a code. When tried, a line period holding only cbc:DescriptionCode reported BR-CO-20 and the warning UBL-CR-523.

How an integration ends up here

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

• The billing system stores the period as a label such as a month name, and the export writes that label to cbc:Description instead of converting it to dates.
• The template always emits cac:InvoicePeriod and fills its dates only for subscription or service invoices, leaving an empty or description-only period on other invoices.
• The date fields are null for a one-off charge, and the serialiser drops the null dates but keeps their parent element.

How to fix it

1. Decide whether the invoice really covers a period. If it does not, remove cac:InvoicePeriod altogether.
2. If it does, write the first day to cbc:StartDate and the last day to cbc:EndDate as YYYY-MM-DD, derived from the billing period in the source. A label such as August 2026 becomes 2026-08-01 to 2026-08-31.
3. Remove cbc:Description from the period. If the wording matters to the buyer, the document note, cbc:Note, is the place for free text.
4. If the period only exists to carry the VAT point date code, keep the code and leave the dates out. That passes this rule, but the code cannot sit beside a cbc:TaxPointDate (BR-CO-03).

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 period is described in words and has no dates

<cbc:BuyerReference>BUYER-REF-001</cbc:BuyerReference>
<cac:InvoicePeriod>
  <cbc:Description>August 2026</cbc:Description>
</cac:InvoicePeriod>

Fragment of the corrected invoice: the period has a start date and an end date

<cbc:BuyerReference>BUYER-REF-001</cbc:BuyerReference>
<cac:InvoicePeriod>
  <cbc:StartDate>2026-08-01</cbc:StartDate>
  <cbc:EndDate>2026-08-31</cbc:EndDate>
</cac:InvoicePeriod>

The corrected invoice replaces cbc:Description with cbc:StartDate 2026-08-01 and cbc:EndDate 2026-08-31. The failing document also reports UBL-CR-015, a warning that cbc:Description inside cac:InvoicePeriod is not part of the EN 16931 model. When tried, that warning stayed even with both dates added beside the description, so removing the description is what clears it.

Where it applies

• Applies to Invoice and CreditNote: a credit note uses the same cac:InvoicePeriod element, and when tried, one with only a description reported BR-CO-19 and UBL-CR-015 as well.
• Reported in the EN 16931 layer.
• The code-only exception is narrow. The code must be one of 3, 35 or 432, or BR-CL-06 and PEPPOL-EN16931-CL006 fail, and the document must not also carry cbc:TaxPointDate, or BR-CO-03 fails.
• Once both dates are present, BR-29 checks that the end date is not before the start date.

Related rules

• BR-29 checks the order of the two dates once both are given
• BR-CO-03 forbids the VAT point date code, the one alternative to dates here, beside a VAT point date
• PEPPOL-EN16931-R008 is reported as well when the invoicing period element is left completely empty
• 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-CO-19 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.