BR-30: Put the line period end date on or after its start date

The short answer

BR-30 fails when the cac:InvoicePeriod of an invoice or credit note line has a cbc:EndDate that falls before its cbc:StartDate. Correct the service dates of that line so the start is the first day it covers and the end the last, as in the corrected invoice: 2026-08-01 to 2026-08-15.

The finding names the line, such as cac:InvoiceLine[1]/cac:InvoicePeriod[1], so on a long invoice it tells you exactly which service dates to recheck.

What the rule checks

The rule visits every line period and compares its two dates as calendar dates, but only when both are present. When tried, a line period with only a start date and one with only an end date each passed.

Equal dates are accepted. When tried, a line period starting and ending on 2026-08-15 passed every layer, and moving the end back by one day to 2026-08-14 reported BR-30.

The line is judged on its own two dates. When tried, the reversed line period reported BR-30 just the same after the document-level invoicing period had been removed.

Peppol compares each line date with the document period on its own, and a reversed line period can pass both of those comparisons. When tried, a line period from 2026-09-10 back to 2026-07-20, in an invoicing period for August, reported BR-30 but neither PEPPOL-EN16931-R110 nor PEPPOL-EN16931-R111, because its start is after 1 August and its end before 31 August.

How an integration ends up here

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

• The line template maps the start and end values to each other's elements, while the document period is mapped correctly.
• Line dates held as text are read month first when the source writes day first: a line covering 12 July to 3 August, stored as 12/07/2026 and 03/08/2026, becomes 7 December to 8 March.
• A usage or subscription line computes its end date from a start date and a duration, and a cancellation produces a negative duration.
• A reversal line built from an earlier invoice line swaps its dates to show the reversal, instead of keeping the period and negating the quantity.

How to fix it

1. Open the line named in the finding and look up the service period it bills in the source record.
2. Write the first day of that period to cbc:StartDate and the last day to cbc:EndDate inside the line cac:InvoicePeriod, both as YYYY-MM-DD.
3. Parse text dates with an explicit format that matches the source, never with a locale default.
4. For a credit or reversal, keep the period in its natural order and let the negative quantity or amount express the reversal.
5. Recheck the line against the document period: its start must not precede it (PEPPOL-EN16931-R110) and its end must not go beyond it (PEPPOL-EN16931-R111).

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: line 1 runs from 15 August back to 1 August

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

Fragment of the corrected invoice: line 1 covers 1 to 15 August

<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>

The two line dates have swapped places: 2026-08-15 to 2026-08-01 in the failing invoice, 2026-08-01 to 2026-08-15 in the corrected one. The document period for August is the same in both, and BR-30 is the only finding; each line date on its own still lies inside that period, so the Peppol line period rules have nothing to report.

Where it applies

• Applies to Invoice and CreditNote. In a credit note the line is cac:CreditNoteLine, with its period element still named cac:InvoicePeriod; when tried, a reversed period there reported BR-30 at cac:CreditNoteLine[1]/cac:InvoicePeriod[1].
• An EN 16931 rule, reported in that layer only.
• The document-level period has its own rule for the same comparison, BR-29.
• A line date with a time zone, such as 2026-08-15Z, passes the XSD and is rejected by PEPPOL-EN16931-F001. When tried with both reversed dates suffixed that way, BR-30 and two PEPPOL-EN16931-F001 findings were reported.

Related rules

• BR-29 makes the same comparison for the invoicing period of the whole document
• BR-CO-20 rejects a line period with no dates at all, the case this rule does not look at
• PEPPOL-EN16931-R110 rejects a line period that starts before the invoicing period
• PEPPOL-EN16931-R111 rejects a line period that ends after the invoicing period
• 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-28.1: source checked 2026-09-28, explanation last updated 2026-09-28.

The official definition of BR-30 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.