# BR-CO-19: Give the invoicing period a start date, an end date or both
An invoicing period in `cac:InvoicePeriod` needs `cbc:StartDate`, `cbc:EndDate` or both. A description of the period in words does not count.
- Layer: EN 16931
- Severity: fatal (the document is invalid)
- Topics: Core fields
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-CO-19/
- Explanation last updated: 2026-09-24
## 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 `` 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`.
| Term | Meaning | UBL element |
|---|---|---|
| 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` |
| BT-8 | Value added tax point date code | `cac:InvoicePeriod/cbc:DescriptionCode` |
## 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`).
## 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
```xml
BUYER-REF-001
August 2026
```
Fragment of the corrected invoice: the period has a start date and an end date
```xml
BUYER-REF-001
2026-08-01
2026-08-31
```
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.
### What the validator reported
- The failing invoice reports **BR-CO-19** and `UBL-CR-015`. The corrected document passes every layer with no findings.
- [Download the failing XML](https://ironfang.uk/finance/rule-examples/BR-CO-19-invalid.xml)
- [Download the corrected XML](https://ironfang.uk/finance/rule-examples/invoice-period-valid.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 `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](https://ironfang.uk/docs/finance/rules/BR-29.md)
- [BR-CO-03 forbids the VAT point date code, the one alternative to dates here, beside a VAT point date](https://ironfang.uk/docs/finance/rules/BR-CO-03.md)
- [PEPPOL-EN16931-R008 is reported as well when the invoicing period element is left completely empty](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R008.md)
## 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](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/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.
## Links
- [This rule as a web page](https://ironfang.uk/docs/finance/rules/BR-CO-19)
- [Free Peppol invoice validator](https://ironfang.uk/tools/peppol-validator)
- [Rule index](https://ironfang.uk/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.uk/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.uk/mcp