Rule at a Glance

ID Severity Context (XPath)
Series ref. BR-109 | Schematron ID: ibr-co-19 Fatal (error) cac:InvoicePeriod

Assert text: [ibr-co-19]-If Invoicing period (ibg-14) is used, the Invoicing period start date (ibt-073) or the Invoicing period end date (ibt-074) MUST be filled, or both.

Test: exists(cbc:StartDate) or exists(cbc:EndDate) or (exists(cbc:DescriptionCode) and not(exists(cbc:StartDate)) and not(exists(cbc:EndDate)))

Classification

Transaction Data. The rule governs the shape of an optional block on one invoice: present it properly or leave it out.

What the Rule Is Checking

The invoicing period (IBG-14) states the span of time an invoice covers. The block itself is optional, but once a cac:InvoicePeriod element appears at document level it must carry a start date, an end date, or both. The test carries one further branch: a period block containing only a DescriptionCode — a coded statement of the tax point date — also passes, since that code conveys timing information without needing explicit dates. An empty period block, or one holding only elements outside these three, fails.

Why This Rule Exists

Continuous and periodic supplies — rentals, utilities, subscriptions, retainers, telecom services — are invoiced for a span rather than a moment, and the period is what anchors the invoice to the correct VAT return cycle for both parties. A period block with no dates asserts that a span exists while withholding it, which is worse for a consuming system than no block at all: the recipient's logic branches on the presence of cac:InvoicePeriod and then finds nothing to act on. The rule forces the sender to commit to a span or omit the block.

UAE Data Example

PASSES ✓

<cac:InvoicePeriod>
  <cbc:StartDate>2026-07-01</cbc:StartDate>
  <cbc:EndDate>2026-07-31</cbc:EndDate>
</cac:InvoicePeriod>

FAILS ✗

<cac:InvoicePeriod>
</cac:InvoicePeriod>

A monthly service invoice for July 2026 passes with both dates stated. An empty period element — typically produced by a mapping template that always emits the block and populates it only when the source order carries period fields — fails validation.

What Your ERP / IT Team Must Ensure

  • Make the mapping conditional: emit cac:InvoicePeriod only when at least one of start date, end date, or description code has a value.
  • Source period dates from the billing plan or contract line, since periodic billing documents in most ERPs carry the service span there rather than on the invoice header.
  • Check date formatting alongside presence — the dates themselves must be valid YYYY-MM-DD values to survive the format rules elsewhere in the pack.
  • Cover the line-level counterpart in testing: rule ibr-co-20 applies the same start-or-end requirement to cac:InvoiceLine/cac:InvoicePeriod, so a fix at document level should be mirrored there.

Related Rules