PEPPOL-EN16931-R111: End each line period on or before the invoicing period end date

The short answer

PEPPOL-EN16931-R111 fails when a line cac:InvoicePeriod/cbc:EndDate falls after the cbc:EndDate of the document-level cac:InvoicePeriod. In the recorded example the invoicing period ends on 2026-08-31 and the line period on 2026-09-15. Correct the line date if it is wrong; if the line really runs longer, end the invoicing period on or after the latest line end date.

The finding is placed on the line end date, so each line that runs past the invoicing period is reported separately.

What the rule checks

The rule only applies when the document period has an end date. When tried, a line ending on 2026-09-15 passed once the document end date was removed, and still failed when the document period had an end date but no start date.

Dates are compared as calendar dates and the boundary is included: a line ending on 2026-08-31, the last day of the invoicing period, passed when tried.

A line that lies wholly after the invoicing period is caught here and nowhere else. When tried, a line period from 2026-09-05 to 2026-09-15 reported this rule alone, since the start date check only looks for lines that begin too early.

Nothing compares a line end date with the document start date. When tried, a line period with only an end date of 2026-07-20, before the invoicing period began, passed every layer.

How an integration ends up here

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

• A subscription or service line is billed for its full term while the invoicing period is set to the calendar month.
• The document period is taken from the first line, and a later line runs longer.
• The line end date is calculated as the start date plus a duration, and an off-by-one error carries it into the next month.
• A time zone conversion shifts a line end date to the following day, past the last day of the period.

How to fix it

1. Take the line named in the finding and check its service end date at source.
2. If the date is wrong, correct it there and write the corrected date to that line cac:InvoicePeriod/cbc:EndDate.
3. If the date is right, the invoicing period is too short. Set the document cac:InvoicePeriod/cbc:EndDate to the latest line end date, and check the earliest line start date against the document start date, as PEPPOL-EN16931-R110 requires.
4. Write both dates as plain YYYY-MM-DD values; a time zone suffix is rejected by PEPPOL-EN16931-F001.

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 ends on 31 August, the line period on 15 September

<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>
  <!-- quantity and line net amount omitted from this fragment -->
  <cac:InvoicePeriod>
    <cbc:StartDate>2026-08-01</cbc:StartDate>
    <cbc:EndDate>2026-09-15</cbc:EndDate>
  </cac:InvoicePeriod>
  <!-- item and price omitted from this fragment -->
</cac:InvoiceLine>

Fragment of the corrected invoice: the line period ends on 15 August, inside 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>
  <!-- quantity and line net amount omitted from this fragment -->
  <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 end date differs: 2026-09-15 in the failing invoice, 2026-08-15 in the corrected one, against an invoicing period ending on 2026-08-31 in both. The failing document reports only PEPPOL-EN16931-R111. The EN 16931 layer has no rule comparing line and document periods: BR-30 checks only that the line does not end before its own start date of 2026-08-01, and it does not.

Where it applies

• Applies to Invoice and CreditNote. The line of a credit note is cac:CreditNoteLine, but its period is still cac:InvoicePeriod; when tried with the same dates, it reported this rule.
• A Peppol BIS rule, reported by the Peppol layer alone.
• A line period that starts before the invoicing period is PEPPOL-EN16931-R110. When tried, a line running from 2026-07-25 to 2026-09-15 reported both rules, one at each date.
• A line end date with a time zone suffix is also reported by PEPPOL-EN16931-F001. When tried, 2026-09-15Z brought both findings.

Related rules

• PEPPOL-EN16931-R110 is the start date counterpart, for lines that begin before the invoicing period
• BR-30 checks that a line period does not end before it starts
• BR-29 checks the same order of dates in the document-level invoicing period
• 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-R111 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.