# BR-CL-06: Use code 3, 35 or 432 as the VAT point date code

The VAT point date code in `cac:InvoicePeriod/cbc:DescriptionCode` must be `3`, `35` or `432`. Other UNTDID 2005 codes, such as `131`, are rejected.

- Layer: EN 16931
- Severity: fatal (the document is invalid)
- Topics: Code lists, VAT
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-CL-06/
- Explanation last updated: 2026-09-28

## The short answer

`BR-CL-06` fails when `cbc:DescriptionCode` in a `cac:InvoicePeriod` holds anything other than `3`, `35` or `432`. Each of the three names the event that fixes when VAT becomes due: `3` the invoice issue date, `35` the actual delivery date, `432` the date of payment.

The recorded example sent `131`, a code from the full UNTDID 2005 list of date qualifiers that EN 16931 does not allow here; the corrected invoice uses `3`. `PEPPOL-EN16931-CL006` checks the same element against the same three codes, so a wrong value is reported by both rules.

## What the rule checks

Any `cac:InvoicePeriod` is covered, at document level or on a line. When tried, `131` in a line period was reported by this rule and `PEPPOL-EN16931-CL006`, together with the warning `UBL-CR-523`, which advises against a code on a line period at all.

The value is trimmed and must then be exactly `3`, `35` or `432`. When tried, ` 3 ` with spaces around it passed, and `03` with a leading zero failed.

An empty `cbc:DescriptionCode` fails as well. When tried, it reported this rule, `PEPPOL-EN16931-CL006` and `PEPPOL-EN16931-R008`.

The code is checked on its own. Whether it may stand beside `cbc:TaxPointDate` is decided by `BR-CO-03`, and nothing compares it with the period dates or the delivery date.

| Term | Meaning | UBL element |
|---|---|---|
| BT-8 | Value added tax point date code | `cac:InvoicePeriod/cbc:DescriptionCode` |
| BT-7 | Value added tax point date | `cbc:TaxPointDate` |

## How an integration ends up here

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

- The code is taken from the full UNTDID 2005 list rather than from the three that EN 16931 allows, for example `131`, which EDIFACT invoices use to qualify a tax point date.
- Codes are stored with a fixed width, producing `03` or `035`.
- The element is filled with a description of the period, because `cbc:DescriptionCode` is mistaken for the free-text `cbc:Description`.
- An empty element is written when the source has no VAT point code, instead of leaving the element out.

## How to fix it

1. Decide what fixes the VAT point for the invoice: its issue date (`3`), the actual delivery date (`35`) or payment (`432`, Paid to date).
2. Write that one code, digits only, in `cbc:DescriptionCode` of the document-level `cac:InvoicePeriod`.
3. If you know the VAT point as a date rather than as an event, send it in `cbc:TaxPointDate` and drop the code; the two must not appear together.
4. Keep codes off line periods. A line period takes dates only, and any code there draws the warning `UBL-CR-523`.

## 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 invoicing period carries VAT point date code 131

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

Fragment of the corrected invoice: code 3, the invoice issue date

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

Only the code in the invoicing period differs: `131` in the failing invoice, `3` in the corrected one, with the August 2026 start and end dates unchanged. The failing document also reports `PEPPOL-EN16931-CL006`, the Peppol layer check of the same element against the same three codes, and the one correction clears both.

### What the validator reported

- The failing invoice reports **BR-CL-06** and [PEPPOL-EN16931-CL006](https://ironfang.com/docs/finance/rules/PEPPOL-EN16931-CL006.md). The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.com/finance/rule-examples/BR-CL-06-invalid.xml)
  - [Download the corrected XML](https://ironfang.com/finance/rule-examples/codelist-vat-point-code-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`. When tried, a credit note whose period held only the code `131` reported this rule and `PEPPOL-EN16931-CL006`.
- No value separates the pair: both trim the code and accept the same three values, so they fail and pass together.
- The element is optional, and a document without a VAT point date code is not checked by this rule.

## Related rules

- [PEPPOL-EN16931-CL006 is the Peppol layer copy of this check](https://ironfang.com/docs/finance/rules/PEPPOL-EN16931-CL006.md)
- [BR-CO-03 forbids the code beside a VAT point date](https://ironfang.com/docs/finance/rules/BR-CO-03.md)
- [BR-CO-19 accepts an invoicing period that holds only this code](https://ironfang.com/docs/finance/rules/BR-CO-19.md)
- [BR-CL-05 checks the VAT accounting currency code, another optional VAT reporting field](https://ironfang.com/docs/finance/rules/BR-CL-05.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-28.1: source checked 2026-09-28, explanation last updated 2026-09-28.

[The official definition of BR-CL-06](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-CL-06/) 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.com/docs/finance/rules/BR-CL-06)
- [Free Peppol invoice validator](https://ironfang.com/tools/peppol-validator)
- [Rule index](https://ironfang.com/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.com/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.com/mcp