Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-78 | Fatal (error) | /ubl:Invoice | /cn:CreditNote |
| Schematron ID: ibr-097 | Field: ibg-14 — Invoicing period, at document level | ||
Classification
Contextual — a cardinality constraint on the group that establishes the tax period the document belongs to.
What the Rule Is Checking
The assert is count(cac:InvoicePeriod) <= 1, evaluated from the document root. A header invoicing period may appear once or not at all. Two occurrences fail.
The rule counts the group, not the dates inside it, so an invoicing period carrying both a start date and an end date is a single occurrence. Line-level periods are counted separately under ibr-110 and are unaffected by this rule.
Why This Rule Exists
The invoicing period tells the recipient and the authority which span of activity the document covers, and it is what makes a document interpretable when the invoice date and the supply period fall in different VAT return periods. Two periods at header level leave the tax point undetermined, which is not a defect the recipient can resolve by inspection.
The UAE jurisdiction rules make this more than a formatting matter. Under ibr-138-ae, an invoicing period is mandatory where the invoice transaction type code (BTAE-002) carries the summary invoice flag XXX1XXXX — so for exactly the documents where consolidation makes a second period tempting, the single period becomes a required field rather than an optional one. A summary invoice covering March and April has to be split into two documents, or stated as one period spanning both.
Standard / Code List
No code list applies to the period itself. The dates are ISO 8601 calendar dates, and the transaction type code that triggers the UAE mandatory-period condition is BTAE-002, an eight-position flag structure defined in the PINT-AE jurisdiction extension.
UAE Data Example
PASSES ✓ — a summary invoice for a UAE facilities management contract billed monthly in arrears:
<cac:InvoicePeriod>
<cbc:StartDate>2027-03-01</cbc:StartDate>
<cbc:EndDate>2027-03-31</cbc:EndDate>
</cac:InvoicePeriod>FAILS ✗ — a two-month consolidation expressed as two groups:
<cac:InvoicePeriod>
<cbc:StartDate>2027-03-01</cbc:StartDate>
<cbc:EndDate>2027-03-31</cbc:EndDate>
</cac:InvoicePeriod>
<cac:InvoicePeriod>
<cbc:StartDate>2027-04-01</cbc:StartDate>
<cbc:EndDate>2027-04-30</cbc:EndDate>
</cac:InvoicePeriod>Stating the span as a single period from 2027-03-01 to 2027-04-30 passes, but only where that genuinely reflects the supply. Where the two months carry different rates or different contract terms, separate documents are the correct answer.
What Your ERP / IT Team Must Ensure
- Derive the header period from the billing document’s period fields once, rather than accumulating a period per settlement run inside the same document.
- Where line periods vary, use ibg-26 at line level and set the header period to the outer span — ibr-085 and ibr-086 require line periods to fall within it.
- Check the summary invoice flag in BTAE-002 against the presence of the header period, since ibr-138-ae makes it mandatory in that case.
- Validate that the end date is on or after the start date, which ibr-029 enforces separately.
- Treat a requirement for two header periods as a signal that the document should be two documents.
Related Rules
ibr-029 orders the period dates. ibr-085 and ibr-086 require line period dates to fall within the header period. ibr-110 applies the same single-occurrence limit at line level. ibr-138-ae makes the header period mandatory for summary invoices under the UAE jurisdiction rules.