Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-58 | Fatal (error) | cbc:IssueDate | cbc:DueDate | cbc:TaxPointDate | cbc:StartDate | cbc:EndDate | cbc:ActualDeliveryDate |
| Schematron ID: ibr-073 | Field: Date format across IBT-002, IBT-007, IBT-009, IBT-026, IBT-072, IBT-073, IBT-074, IBT-134, IBT-135 | ||
Classification
Syntax & Integration — the rule tests the lexical form of every date on the invoice, wherever it appears: issue date, due date, tax point date, invoicing period start and end, and actual delivery date, on both invoices and credit notes.
What the Rule Is Checking
Two tests on each date element: the text must be exactly ten characters long, and it must be castable as an XML Schema date — meaning the pattern YYYY-MM-DD with a real month and a real day. The length test does independent work: 2026-8-1 might cast as a date in some processors, but at eight characters it fails outright, so single-digit months and days without leading zeros are rejected. So are timezone suffixes and time components, which push the string past ten characters. 2026-13-01 passes the length test and then fails the cast, because there is no month thirteen.
Why This Rule Exists
Dates drive consequential logic downstream: the tax point date determines which VAT return period a transaction falls into, the issue date anchors the transmission-deadline obligations under the UAE regime, and the invoicing period bounds continuous supplies. Ambiguous date formats are one of the oldest failure classes in system integration — 03/04/2026 reads as March in one convention and April in another, and a misread of that kind silently shifts a transaction across a filing period boundary. Fixing the format to ISO 8601 at validation removes the ambiguity before any of the five corners has to interpret it.
Standard / Code List
The format is ISO 8601 calendar date, as constrained by the XML Schema xs:date type with no timezone. This is a case where the standard is enforced structurally rather than through a code list.
UAE Data Example
PASSES ✓: <cbc:IssueDate>2026-08-01</cbc:IssueDate> paired with <cbc:TaxPointDate>2026-07-28</cbc:TaxPointDate> — a July supply invoiced in August, with each date carrying its own leading zeros.
FAILS ✗: A legacy billing system exports 01/08/2026. Ten characters, so the length test passes — then the cast fails on the slashes, and the invoice is rejected before transmission.
What Your ERP / IT Team Must Ensure
Format dates at the extraction layer using an explicit ISO 8601 pattern rather than the system locale, since locale-driven formatting is exactly how DD/MM/YYYY leaks into an XML payload. Test single-digit day and month values specifically — the leading-zero failure only shows up on the first nine days of a month, which is how it escapes a mid-month test cycle and surfaces in production on the first of the next month. Confirm that no timestamp fields are being truncated into date fields by string-slicing, which produces valid-looking output until a timezone conversion shifts the date itself.
Related Rules
The dates this rule formats are mandated elsewhere in the ruleset — the issue date requirement is covered in the early series posts starting at BR-01. This rule adds no obligation to supply a date; it constrains the shape of every date you do supply.