On this page
The short answer
PEPPOL-EN16931-CL006 fails when the cbc:DescriptionCode of an invoicing period holds anything other than 3, 35 or 432. The element is the VAT point date code: it says whether VAT becomes due on the invoice issue date (3), the actual delivery date (35) or the payment date (432, paid to date). Write the one of those three that matches your VAT treatment, or leave the element out.
The recorded example carries 5, the invoice date code of the CII syntax, where the same business term uses the codes 5, 29 and 72. In UBL the invoice issue date is 3. EN 16931 checks the element against the same three codes with BR-CL-06, so the value is reported on both layers.
What the rule checks
The rule runs on every cbc:DescriptionCode inside a cac:InvoicePeriod, trims its text and compares it with the three permitted codes. When tried, 35 surrounded by spaces passed, and so did 432.
Only three of the UNCL 2005 date and time qualifiers are accepted. When tried, 137, a UNCL 2005 code for a document issue date, was reported by this rule and BR-CL-06, and so were 29, 72, 003 and 3 35.
The Peppol list and the EN 16931 list for this element hold the same three codes and both are compared after trimming, so for every value tried the two findings came together: this rule on the Peppol layer and BR-CL-06 on the EN 16931 layer.
An empty <cbc:DescriptionCode></cbc:DescriptionCode> fails too. When tried it brought BR-CL-06 and PEPPOL-EN16931-R008, the Peppol rule against empty elements, beside this one.
Line periods are checked as well. When tried, 5 in the invoicing period of a line was reported by this rule and BR-CL-06, with the warning UBL-CR-523, which advises against a description code at line level; 3 there left only that warning.
| Term | Meaning | UBL element |
|---|---|---|
| BT-8 | Value added tax point date code | cac:InvoicePeriod/cbc:DescriptionCode |
| BG-14 | Invoicing period | cac:InvoicePeriod |
How an integration ends up here
Possible causes, from the shape of the rule rather than from measured usage:
- The mapping was written for CII, or converts from it, and copies
5,29or72into UBL, where the codes with the same meanings are3,35and432. - An internal tax point setting, such as
INVOICE,DELIVERYorPAYMENT, or a number standing for it, is written to the element without translation. - The element name suggests a description, so a label for the period, such as a month name, ends up in it.
How to fix it
- Find out from your VAT set-up which date the VAT point follows: the invoice issue date, the actual delivery date or the payment date.
- Write the matching code:
3,35or432. If you convert from CII, map5to3,29to35and72to432. - If the VAT point date itself is known, you may send it in
cbc:TaxPointDateinstead and leave the code out:BR-CO-03rejects the two together. - Keep the period itself in
cbc:StartDateandcbc:EndDate; nothing descriptive belongs in the code element.
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 invoicing period carries the CII code 5
<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<!-- due date, type code, currency and buyer reference omitted from this fragment -->
<cac:InvoicePeriod>
<cbc:StartDate>2026-08-01</cbc:StartDate>
<cbc:EndDate>2026-08-31</cbc:EndDate>
<cbc:DescriptionCode>5</cbc:DescriptionCode>
</cac:InvoicePeriod>Fragment of the corrected invoice: code 3, VAT due on the invoice issue date
<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<!-- due date, type code, currency and buyer reference omitted from this fragment -->
<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 description code differs: 5 in the failing invoice, 3 in the corrected one, which makes the issue date 2026-09-08 the VAT point. The failing document also reports BR-CL-06, the EN 16931 check of the same element against the same three codes, and the one correction clears both findings.
What the validator reported
- The failing invoice reports BR-CL-06 and PEPPOL-EN16931-CL006. The corrected document passes every layer with no findings.Download the failing XMLDownload the corrected 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 UBL
InvoiceandCreditNote. When tried, a credit note whose invoicing period carried5reported the same two rules. - Reported on the Peppol layer. The EN 16931 layer reported the same values through
BR-CL-06in every case tried, so a document failing here does not pass EN 16931 either. - The code is optional. An invoicing period with only its two dates passes, and when tried a period holding
35and no dates at all passed every layer too.
Related rules
- BR-CL-06 applies the same three codes to this element on the EN 16931 layer
- BR-CO-03 forbids sending the VAT point date code together with a VAT point date
- BR-CO-19 accepts an invoicing period that holds only a description code
- PEPPOL-EN16931-CL007 is the Peppol code list check for the currency of every amount
- Browse every rule in the reference
- Background: How Peppol invoice validation actually works
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 PEPPOL-EN16931-CL006 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.

