PEPPOL-EN16931-R110: Start each line period on or after the invoicing period start date

The short answer

PEPPOL-EN16931-R110 fails when a line cac:InvoicePeriod/cbc:StartDate is earlier than the cbc:StartDate of the document-level cac:InvoicePeriod. Either the line date is wrong and should be corrected, or the line really covers earlier days and the invoicing period should start on or before them.

The finding points at the line start date itself, so on a document with many lines it tells you which one is out of range. Line end dates are the business of PEPPOL-EN16931-R111.

What the rule checks

The rule runs only if the document-level period has a cbc:StartDate. When tried, the same early line date passed when the document period had only an end date, and again when there was no document period at all.

Each line period start date is then compared with the document start date as a calendar date. The same day passes: in the corrected invoice both periods start on 2026-08-01.

Only start dates take part. A line whose end date is after the document end date reports PEPPOL-EN16931-R111 instead; when tried, a line ending on 2026-09-05 in a period ending on 2026-08-31 did exactly that.

The rule does not ask whether a line starts after the invoicing period has ended. When tried, a line period with only a start date of 2026-09-05, beyond the document end date of 2026-08-31, passed every layer.

How an integration ends up here

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

• The invoicing period is set to the current billing month while a line carries charges for earlier days, such as usage billed in arrears or a pro-rated first period.
• The document period is copied from the first line, and a later line starts earlier.
• Line dates and document dates go through different time zone conversions, so a line starting at local midnight is written as the previous day.
• A correction line keeps the service dates of the original invoice while the document period is the current one.

How to fix it

1. For the line named in the finding, check its service dates in the source: is the start date right?
2. If it is wrong, correct it at source and write the corrected date to that line cac:InvoicePeriod/cbc:StartDate.
3. If it is right, the invoicing period does not cover the whole invoice. Set the document cac:InvoicePeriod/cbc:StartDate to the earliest line start date, and compare the document end date with the latest line end date, which PEPPOL-EN16931-R111 requires.
4. Write every date as a plain YYYY-MM-DD taken from the calendar date in the business time zone, with no conversion to UTC.

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 starts on 1 August, the line period on 25 July

<cac:InvoicePeriod>
  <cbc:StartDate>2026-08-01</cbc:StartDate>
  <cbc:EndDate>2026-08-31</cbc:EndDate>
</cac:InvoicePeriod>
<!-- parties, VAT and totals omitted from this fragment -->
<cac:InvoiceLine>
  <cbc:ID>1</cbc:ID>
  <cbc:InvoicedQuantity unitCode="C62">2</cbc:InvoicedQuantity>
  <cbc:LineExtensionAmount currencyID="GBP">25.00</cbc:LineExtensionAmount>
  <cac:InvoicePeriod>
    <cbc:StartDate>2026-07-25</cbc:StartDate>
    <cbc:EndDate>2026-08-15</cbc:EndDate>
  </cac:InvoicePeriod>
  <!-- item and price omitted from this fragment -->
</cac:InvoiceLine>

Fragment of the corrected invoice: the line period starts on 1 August, the first day of the invoicing period

<cac:InvoicePeriod>
  <cbc:StartDate>2026-08-01</cbc:StartDate>
  <cbc:EndDate>2026-08-31</cbc:EndDate>
</cac:InvoicePeriod>
<!-- parties, VAT and totals omitted from this fragment -->
<cac:InvoiceLine>
  <cbc:ID>1</cbc:ID>
  <cbc:InvoicedQuantity unitCode="C62">2</cbc:InvoicedQuantity>
  <cbc:LineExtensionAmount currencyID="GBP">25.00</cbc:LineExtensionAmount>
  <cac:InvoicePeriod>
    <cbc:StartDate>2026-08-01</cbc:StartDate>
    <cbc:EndDate>2026-08-15</cbc:EndDate>
  </cac:InvoicePeriod>
  <!-- item and price omitted from this fragment -->
</cac:InvoiceLine>

Only the line start date differs: 2026-07-25 in the failing invoice, 2026-08-01 in the corrected one. The failing document reports only PEPPOL-EN16931-R110. Its EN 16931 layer passes because the line-level period rule there, BR-30, compares a line start date only with the end date of the same line, and 2026-08-15 is later than 2026-07-25.

Where it applies

• Applies to Invoice and CreditNote. In a credit note the line is cac:CreditNoteLine, whose period element is still called cac:InvoicePeriod; when tried, the same early date reported this rule there.
• This is a Peppol BIS rule and appears in the Peppol layer alone; the EN 16931 layer passed the recorded failing invoice.
• A date that is not a date at all, such as 25/07/2026, fails the XSD layer before this rule can run; one with a time zone suffix passes the XSD and is rejected by PEPPOL-EN16931-F001.
• A line end date before its own start date is BR-30; a line end date after the document end date is PEPPOL-EN16931-R111.

Related rules

• BR-29 checks that the invoicing period this rule measures against does not end before it starts
• BR-CO-19 requires a date in the invoicing period, and only a start date there brings this rule into play
• PEPPOL-EN16931-F001 rejects line and document period dates that carry a time zone
• 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-R110 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.