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

Inside a line `cac:InvoicePeriod` that has both dates, `cbc:EndDate` must not be earlier than `cbc:StartDate`. A line period of a single day passes.

- Layer: EN 16931
- Severity: fatal (the document is invalid)
- Topics: Core fields, Lines and prices
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-30/
- Explanation last updated: 2026-09-28

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

| Term | Meaning | UBL element |
|---|---|---|
| BT-134 | Invoice line period start date | `cac:InvoiceLine/cac:InvoicePeriod/cbc:StartDate (cac:CreditNoteLine/cac:InvoicePeriod/cbc:StartDate in a credit note)` |
| BT-135 | Invoice line period end date | `cac:InvoiceLine/cac:InvoicePeriod/cbc:EndDate (cac:CreditNoteLine/cac:InvoicePeriod/cbc:EndDate in a credit note)` |

## 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`).

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

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

```xml
<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.

### What the validator reported

- The failing invoice reports **BR-30**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.com/finance/rule-examples/BR-30-invalid.xml)
  - [Download the corrected XML](https://ironfang.com/finance/rule-examples/period-valid.xml)

Recorded on phive 12.1.0 / phive-rules-peppol 4.5.6 / Saxon-HE 12.10, the engine behind the free validator, using synthetic data. A recorded result is regression evidence for these documents; it is not a certification.

## 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](https://ironfang.com/docs/finance/rules/BR-29.md)
- [BR-CO-20 rejects a line period with no dates at all, the case this rule does not look at](https://ironfang.com/docs/finance/rules/BR-CO-20.md)
- [PEPPOL-EN16931-R110 rejects a line period that starts before the invoicing period](https://ironfang.com/docs/finance/rules/PEPPOL-EN16931-R110.md)
- [PEPPOL-EN16931-R111 rejects a line period that ends after the invoicing period](https://ironfang.com/docs/finance/rules/PEPPOL-EN16931-R111.md)

## 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](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/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.

## Links

- [This rule as a web page](https://ironfang.com/docs/finance/rules/BR-30)
- [Free Peppol invoice validator](https://ironfang.com/tools/peppol-validator)
- [Rule index](https://ironfang.com/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.com/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.com/mcp