BR-CO-03: Send either the VAT point date or the VAT point date code, not both

The short answer

BR-CO-03 fails when the document has a cbc:TaxPointDate and its cac:InvoicePeriod also carries a cbc:DescriptionCode. Keep the tax point date if you know the actual date VAT became chargeable; otherwise keep the code and remove cbc:TaxPointDate.

Both elements state the VAT point: the date gives it directly, while the code names the event that fixes it. The permitted codes are 3 (Invoice document issue date time), 35 (Delivery date/time, actual) and 432 (Paid to date).

What the rule checks

The rule is evaluated once for the whole document. It looks for cbc:TaxPointDate beneath the root and for cbc:DescriptionCode inside the document-level cac:InvoicePeriod, and fails only when it finds both.

Having neither passes, and so does having only one of them. When tried, the recorded invoice with its tax point date kept and a period holding a start date and an end date added passed: period dates do not conflict with the tax point date, only the code does.

Adding dates to the period does not help. When tried, a period with a start date, an end date and code 35, beside a cbc:TaxPointDate, still reported BR-CO-03.

A code on a line period is not considered. When tried, cbc:DescriptionCode in a line cac:InvoicePeriod next to a tax point date did not report this rule; it reported BR-CO-20 and the warning UBL-CR-523, because a line period needs dates and has no place for the code.

The code value is checked by other rules. A code outside 3, 35 and 432, such as 99, reports BR-CL-06 and PEPPOL-EN16931-CL006.

How an integration ends up here

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

• The template writes a default VAT point date code, for example 35 for goods, while a separate field fills cbc:TaxPointDate whenever the source has a tax point.
• An invoicing period is created just to carry the code, and the code is added even on invoices where the tax point date is already known.
• Both values are taken from the delivery record: the actual delivery date goes to cbc:TaxPointDate, and the fact that it is a delivery date is also sent as code 35.

How to fix it

1. Decide which of the two the invoice needs. If the date VAT became chargeable is known and differs from the issue date, send it in cbc:TaxPointDate and remove cbc:DescriptionCode from the period.
2. If only the event is known when the invoice is issued, send the code in cac:InvoicePeriod/cbc:DescriptionCode and remove cbc:TaxPointDate.
3. If removing the code leaves cac:InvoicePeriod with no children, remove the period as well, or BR-CO-19 and PEPPOL-EN16931-R008 follow.
4. If the VAT point is simply the issue date, neither element is needed: the Peppol description of cbc:TaxPointDate calls for it when the VAT point differs from the issue date.

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 tax point date and VAT point date code 35 side by side

<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<!-- note omitted from this fragment -->
<cbc:TaxPointDate>2026-09-07</cbc:TaxPointDate>
<cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>
<cbc:AccountingCost>COST-123</cbc:AccountingCost>
<cbc:BuyerReference>BUYER-REF-001</cbc:BuyerReference>
<cac:InvoicePeriod>
  <cbc:DescriptionCode>35</cbc:DescriptionCode>
</cac:InvoicePeriod>
<!-- references and parties omitted from this fragment -->
<cac:Delivery>
  <cbc:ActualDeliveryDate>2026-09-07</cbc:ActualDeliveryDate>
  <!-- delivery location omitted from this fragment -->
</cac:Delivery>

Fragment of the corrected invoice: only the tax point date remains

<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<!-- note omitted from this fragment -->
<cbc:TaxPointDate>2026-09-07</cbc:TaxPointDate>
<cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>
<cbc:AccountingCost>COST-123</cbc:AccountingCost>
<cbc:BuyerReference>BUYER-REF-001</cbc:BuyerReference>
<!-- references and parties omitted from this fragment -->
<cac:Delivery>
  <cbc:ActualDeliveryDate>2026-09-07</cbc:ActualDeliveryDate>
  <!-- delivery location omitted from this fragment -->
</cac:Delivery>

The corrected invoice has no cac:InvoicePeriod; the failing one adds a period whose only content is code 35. BR-CO-03 is the only finding. The code said the VAT point is the actual delivery date, and the invoice already states that date, 2026-09-07, as both cbc:ActualDeliveryDate and cbc:TaxPointDate, so dropping the code loses nothing.

Where it applies

• Applies to Invoice and CreditNote alike; when tried, a credit note with both elements reported BR-CO-03 at the document root.
• An EN 16931 rule, reported in the EN 16931 layer.
• A period holding only the code satisfies BR-CO-19, which otherwise requires dates; when tried, removing the tax point date from the failing invoice left a valid document.
• A tax point date written with a time zone suffix, such as 2026-09-07Z, passes the XSD but is rejected in the Peppol layer by PEPPOL-EN16931-F001.

Related rules

• BR-CO-19 lets an invoicing period carry only the VAT point date code, as long as this rule is also met
• PEPPOL-EN16931-F001 checks the format of the tax point date when you keep it
• 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-03 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.