PEPPOL-EN16931-R111 A line carries an invoice line period (BG-26) that must not end after the invoicing period ends: the line says 2026-08-31 and the document's invoicing period (BG-14) says 2026-07-31
Line 1 carries an invoice line period (BG-26) that must not end after the invoicing period ends: the line says 2026-08-31 and the document's invoicing period (BG-14) says 2026-07-31. Peppol requires every line period to fall within the document period. A line period that runs past the end of the invoicing period bills for a supply the document has just said it does not cover, which is how the same week gets invoiced twice — once at the end of this period and once at the start of the next. Core EN 16931 constrains each period internally (BR-29, BR-30) but never relates the two, so this is a genuine tightening and one that catches a real class of double billing. This is a Peppol BIS Billing 3.0 profile rule: it applies because profile is "peppol-bis-3". It does not apply to the en16931, xrechnung-ubl or xrechnung-cii profiles, whose validators will accept the same document.
This rule is implemented and its error payload below is real, but the long-form write-up — normative text, worked example, divergence note — is not written yet. Everything the library knows about this rule is on this page. Ask and we will prioritise it.
- Business term
BT-135 / BT-74- Severity
fatal
What the library returns
The exact object in result.errors when this rule fires.
Generated by running @attestwire/en16931, not transcribed:
{
"rule": "PEPPOL-EN16931-R111",
"field": [
"BT-135",
"BT-74"
],
"severity": "fatal",
"message": "Line 1 carries an invoice line period (BG-26) that must not end after the invoicing period ends: the line says 2026-08-31 and the document's invoicing period (BG-14) says 2026-07-31. Peppol requires every line period to fall within the document period. A line period that runs past the end of the invoicing period bills for a supply the document has just said it does not cover, which is how the same week gets invoiced twice — once at the end of this period and once at the start of the next. Core EN 16931 constrains each period internally (BR-29, BR-30) but never relates the two, so this is a genuine tightening and one that catches a real class of double billing. This is a Peppol BIS Billing 3.0 profile rule: it applies because profile is \"peppol-bis-3\". It does not apply to the en16931, xrechnung-ubl or xrechnung-cii profiles, whose validators will accept the same document.",
"fix": "Either move lines[0].period.endDate inside the document period, or widen invoicingPeriod.endDate to cover it. If the line genuinely belongs to another period, it belongs on another invoice.",
"example": "\"invoicingPeriod\": { \"startDate\": \"2026-07-01\", \"endDate\": \"2026-07-31\" }, \"lines\": [{ \"period\": { \"startDate\": \"2026-07-05\", \"endDate\": \"2026-07-20\" } }]",
"xpath": "/ubl:Invoice/cac:InvoiceLine[1]/cac:InvoicePeriod/cbc:EndDate",
"docsUrl": "https://attestwire.com/rules/PEPPOL-EN16931-R111"
}
xpath locates the element in the generated UBL document,
which is where a KoSIT or Peppol validator will report the same problem.
A passing value
"invoicingPeriod": { "startDate": "2026-07-01", "endDate": "2026-07-31" }, "lines": [{ "period": { "startDate": "2026-07-05", "endDate": "2026-07-20" } }]The fix
Either move lines[0].period.endDate inside the document period, or widen invoicingPeriod.endDate to cover it. If the line genuinely belongs to another period, it belongs on another invoice.