PEPPOL-EN16931-F001: Write dates as plain YYYY-MM-DD with no time zone

The short answer

PEPPOL-EN16931-F001 fails when a date element holds anything other than a ten-character YYYY-MM-DD value. In the recorded example the due date is 2026-10-08Z; remove the time zone suffix and write 2026-10-08.

The XSD does not catch this. The UBL date type allows an optional time zone, so 2026-10-08Z and 2026-10-08+01:00 are both valid against the schema and only this Peppol rule rejects them.

What the rule checks

The rule selects every element named cbc:IssueDate, cbc:DueDate, cbc:TaxPointDate, cbc:StartDate, cbc:EndDate or cbc:ActualDeliveryDate, wherever it sits, and reports each failing one at its own location. When tried, a time zone on a line period start date, on the delivery date and on the preceding invoice issue date inside cac:BillingReference was reported each time.

A value passes when it is exactly ten characters long and is a valid date. Anything longer fails, surrounding spaces included: when tried, 2026-10-08 passed the XSD, which collapses whitespace in a date, and failed this rule.

Values that are not dates at all, such as 08/10/2026 or 2026-10-08T00:00:00, never get here. The XSD layer rejects them as schema errors, and the Peppol rules are skipped.

Elements outside that list are not checked. When tried, a credit note with cac:PaymentMeans/cbc:PaymentDueDate set to 2026-10-08Z passed every layer, although the Peppol syntax page for that element lists this rule.

How an integration ends up here

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

• Dates are serialised from a timestamp type, and the library appends Z or an offset because the value carries a time zone.
• An XML binding generated from the UBL schema maps xs:date to a calendar type that writes its time zone by default.
• The value is formatted with an ISO 8601 routine that adds the current offset, such as +01:00 during British Summer Time.
• A template or a fixed-width source field pads the date with spaces or leaves a line break inside the element.

How to fix it

1. Use the location in each finding to find the element. There is one finding per bad date, so the list is complete.
2. Take the calendar date in the business time zone of the invoice first, then drop the time, so that removing the suffix does not also move the date by a day.
3. Format it from a plain local date type, with no time and no zone, using an explicit four-digit year, two-digit month and two-digit day separated by hyphens.
4. Write the value with nothing else inside the element: no spaces, no line breaks.
5. Use the same formatter for every date in the document, including line periods, the delivery date, the preceding invoice issue date and the credit note due date, even though this rule does not check the last one.

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 due date carries a Z time zone suffix

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

Fragment of the corrected invoice: the due date is a plain date

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

Only cbc:DueDate differs: 2026-10-08Z in the failing invoice, 2026-10-08 in the corrected one. The failing document reports only PEPPOL-EN16931-F001; the XSD and EN 16931 layers both pass because a date with a time zone is still a valid xs:date.

Where it applies

• Applies to Invoice and CreditNote. When tried, a credit note issue date of 2026-09-08Z was reported. A credit note has no root-level cbc:DueDate: adding one fails the XSD, and its due date belongs in cac:PaymentMeans/cbc:PaymentDueDate, which is outside this rule.
• A Peppol rule, reported in the Peppol layer only. The EN 16931 layer accepted every suffixed date that was tried.
• Dates the schema cannot read are reported as XSD schema errors, never as this rule.

Related rules

• BR-29 compares the invoicing period dates whose format this rule checks
• PEPPOL-EN16931-R110 compares line period start dates, another set of dates this rule formats
• BR-CO-03 decides whether a tax point date, one of the checked elements, may be sent at all
• 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-24.1: source checked 2026-09-24, explanation last updated 2026-09-24.

The official definition of PEPPOL-EN16931-F001 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.