Attestwire

Rule reference

BR-CO-19 The invoice carries an invoicing period (BG-14) with neither a start date (BT-73), an end date (BT-74) nor a tax point date code (BT-8)

The invoice carries an invoicing period (BG-14) with neither a start date (BT-73), an end date (BT-74) nor a tax point date code (BT-8). An empty period asserts that the supply relates to a timeframe and then declines to say which — and the timeframe is what a periodic invoice is *for*: it is how the buyer accrues the cost to the right month and how both sides detect a gap or an overlap between consecutive invoices. Note that a period carrying only the description code is legal in the UBL binding, because BT-8 has nowhere else to live; a period carrying nothing at all is not.

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
BG-14
Severity
fatal

What the library returns

The exact object in result.errors when this rule fires. Generated by running @attestwire/en16931, not transcribed:

TeachingError
{
  "rule": "BR-CO-19",
  "field": "BG-14",
  "severity": "fatal",
  "message": "The invoice carries an invoicing period (BG-14) with neither a start date (BT-73), an end date (BT-74) nor a tax point date code (BT-8). An empty period asserts that the supply relates to a timeframe and then declines to say which — and the timeframe is what a periodic invoice is *for*: it is how the buyer accrues the cost to the right month and how both sides detect a gap or an overlap between consecutive invoices. Note that a period carrying only the description code is legal in the UBL binding, because BT-8 has nowhere else to live; a period carrying nothing at all is not.",
  "fix": "Set invoicingPeriod.startDate, invoicingPeriod.endDate, or both, as ISO dates. Remove the invoicingPeriod object entirely if the supply is a one-off with a delivery date (BT-72) rather than a period.",
  "example": "\"invoicingPeriod\": { \"startDate\": \"2026-07-01\", \"endDate\": \"2026-07-31\" }",
  "xpath": "/ubl:Invoice/cac:InvoicePeriod",
  "docsUrl": "https://attestwire.com/rules/BR-CO-19"
}

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

the shape this field expects
"invoicingPeriod": { "startDate": "2026-07-01", "endDate": "2026-07-31" }

The fix

Set invoicingPeriod.startDate, invoicingPeriod.endDate, or both, as ISO dates. Remove the invoicingPeriod object entirely if the supply is a one-off with a delivery date (BT-72) rather than a period.

All 292 rules →

Nearby: BR-CO-20 — A line carries an invoice line period (BG-26) with neither a start date (BT-134) nor an end date (BT-135); BR-CO-18 — An invoice must carry at least one VAT breakdown group; BR-CO-21 — Taken individually, the reason (BT-97) and the reason code (BT-98) on the document level allowance at allowances[0] are both optional terms — which is why this constraint exists separately from BR-33: it is the co-occurrence rule that forbids the one combination the cardinalities allow, namely neither.

Check this rule against your invoice via the hosted API → https://api.attestwire.com/docs

Arrived from a stack trace? The docsUrl on every error links straight here. Something wrong on this page — tell us.