UBL-CR-006: Remove the issue time from the document

The short answer

UBL-CR-006 is a warning raised when cbc:IssueTime appears directly under the Invoice or CreditNote root. EN 16931 records only the issue date, so remove cbc:IssueTime and keep cbc:IssueDate as it is.

The document stays valid with the warning and passes every layer. Removing the element keeps the XML inside the EN 16931 model, where a receiver has no business term to map a time to.

What the rule checks

The rule checks one thing: whether a cbc:IssueTime element is a direct child of the root. Its value is not read.

Issue times elsewhere belong to other rules. The time on an order reference or on a preceding invoice reference, for example, has its own UBL-CR warning.

A time in the wrong format never reaches this warning. 10:30 without seconds, and an empty element, each failed the XSD layer when tried, which skips the EN 16931 and Peppol layers.

A time zone makes no difference: 10:30:00Z and 10:30:00+01:00 gave the same warning when tried.

How an integration ends up here

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

• The document timestamp is split into a date and a time and both parts are written, because UBL 2.1 has an element for each.
• A general UBL library emits every header field it has a value for, whether or not EN 16931 uses it.
• A mapping written for another UBL-based format that uses the issue time is reused for EN 16931 invoices.

How to fix it

1. Stop emitting cbc:IssueTime under the root. cbc:IssueDate stays and needs no change.
2. If your records need the time the document was created, keep it in your own system. EN 16931 has no business term for it, so it has no agreed meaning in the invoice.
3. Review the other optional UBL elements the serialiser writes; elements outside the model raise their own UBL-CR warnings.

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 invoice with the warning: an issue time follows the issue date

<cbc:ID>EXAMPLE-INV-001</cbc:ID>
<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<cbc:IssueTime>10:30:00</cbc:IssueTime>
<cbc:DueDate>2026-10-08</cbc:DueDate>

Fragment of the corrected invoice: the issue date alone

<cbc:ID>EXAMPLE-INV-001</cbc:ID>
<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<cbc:DueDate>2026-10-08</cbc:DueDate>

The invoice with the warning has <cbc:IssueTime>10:30:00</cbc:IssueTime> straight after the issue date, and the corrected invoice does not. That invoice reports only this warning and is valid on every layer, so it would be accepted as it stands; removing the time brings it back within the EN 16931 model.

Where it applies

• Applies to UBL Invoice and CreditNote alike; a credit note with an issue time gave the same warning when tried.
• The warning comes from the EN 16931 layer. Peppol adds nothing about the issue time, and the Peppol layer passes.
• In the schema, cbc:IssueTime sits after cbc:IssueDate. Placed before it, the document failed the XSD layer when tried, and this warning was never reached.

Related rules

• UBL-CR-561 is another warning for a UBL element outside the model, a tax total on an invoice line
• UBL-CR-682 warns about a delivery address in a UBL position the model does not use
• PEPPOL-EN16931-F001 checks the format of the dates that stay in the document
• PEPPOL-EN16931-R002 limits another header element: at most one document-level note
• 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 UBL-CR-006 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.