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

`cbc:TaxPointDate` and the VAT point date code in `cac:InvoicePeriod/cbc:DescriptionCode` must not appear together. Send one of them, or neither.

- Layer: EN 16931
- Severity: fatal (the document is invalid)
- Topics: VAT, Core fields
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-CO-03/
- Explanation last updated: 2026-09-24

## 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`.

| Term | Meaning | UBL element |
|---|---|---|
| BT-7 | Value added tax point date | `cbc:TaxPointDate` |
| 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 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.

## 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

```xml
<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

```xml
<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.

### What the validator reported

- The failing invoice reports **BR-CO-03**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/BR-CO-03-invalid.xml)
  - [Download the corrected XML](https://ironfang.uk/finance/rule-examples/invoice-rich.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` 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](https://ironfang.uk/docs/finance/rules/BR-CO-19.md)
- [PEPPOL-EN16931-F001 checks the format of the tax point date when you keep it](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-F001.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-03](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/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.

## Links

- [This rule as a web page](https://ironfang.uk/docs/finance/rules/BR-CO-03)
- [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