Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-100 | Schematron ID: ibr-119 | Fatal (error) | //cbc:*[ends-with(local-name(), 'Time')] |
Assert text: [ibr-119]-A time MUST be formatted hh:mm:ss with optional fractional seconds .sss and time zone expression (ibt-168).
Test: (string(.) castable as xs:time)
Classification
Syntax & Integration. The rule applies to every UBL common basic component (cbc) element whose local name ends in “Time”, wherever it occurs, and checks the value against the XML Schema time type rather than any UAE-specific business condition.
What the Rule Is Checking
Any element carrying a time component — issue time, generation time, or a timestamp embedded elsewhere in the invoice — must be castable to xs:time: hh:mm:ss, with an optional fractional-second suffix and an optional time zone offset. The rule does not check which time zone is used or whether the time is plausible; it checks that the string is structurally a time at all.
This is a pure syntax gate: a time recorded as “14.30” or “2:30 PM” fails regardless of whether the underlying transaction detail is otherwise correct, because the field cannot be parsed as a time value by any downstream system.
Why This Rule Exists
PINT-AE payloads are machine-read by the receiving platform, the ASP's validation layer, and eventually the FTA's own systems. None of those can interpret a free-text or locally formatted time string reliably across senders. Fixing the format to ISO 8601 time removes ambiguity between a 12-hour clock, a 24-hour clock, and locale-specific separators, and it lets every downstream system parse the value with the same library call rather than writing sender-specific tolerance into their intake logic.
UAE Data Example
PASSES ✓
<cbc:IssueTime>14:30:00</cbc:IssueTime>
<cbc:IssueTime>14:30:00.500+04:00</cbc:IssueTime>Both are valid xs:time values — the second includes fractional seconds and the UAE time zone offset.
FAILS ✗
<cbc:IssueTime>2:30 PM</cbc:IssueTime>
<cbc:IssueTime>14.30</cbc:IssueTime>Neither string is castable to xs:time — the first uses a 12-hour clock with an AM/PM marker, the second uses a period instead of a colon separator. Both fail regardless of what the underlying event actually was.
What Your ERP / IT Team Must Ensure
- Confirm that any field mapped into a “Time”-suffixed UBL element is generated from a proper datetime object in the source system, not a formatted display string pulled from a report or a UI label.
- Check locale settings on the generating system — a server configured for 12-hour display or a non-UAE date-time locale can silently produce a non-ISO string even when the underlying timestamp is correct.
- Decide whether to include the time zone offset explicitly (recommended for UAE-issued invoices, given the fixed +04:00 offset) rather than relying on downstream systems to assume it.
- Add this to automated pre-transmission validation rather than relying on the ASP to catch it — a fatal syntax error at this level blocks the whole document, not just one field.