Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-63 | Fatal (error) | //*[not(*) and not(normalize-space())] |
| Schematron ID: ibr-079 | Field: Document-wide structural constraint (applies to any leaf element) | ||
Classification
Syntax & Integration — a blanket structural rule that applies to the entire document rather than one named field, catching a class of error rather than a single missing value.
What the Rule Is Checking
The rule's context matches any element in the document that has no child elements and no meaningful text content after whitespace is stripped out. Put plainly: if a tag exists in the XML but is empty — <cbc:Note></cbc:Note> or <cbc:Note> </cbc:Note> — this rule fails, regardless of which field it is.
Why This Rule Exists
An empty element is a common artefact of template-based generation: a field placeholder gets left in the XML output even when the source system has nothing to put there, because the template logic writes the tag unconditionally rather than only when a value exists. That distinction matters to a receiving system parsing the invoice — an empty tag is not the same as an absent one, and some downstream parsers treat an empty required-looking field as a data quality failure worth flagging even where the schema technically permits the element to be optional. PINT-AE closes the ambiguity at source: if there's nothing to say, don't include the tag.
Standard / Code List
Not applicable — this is a structural constraint, not a value or format check.
UAE Data Example
PASSES ✓: An optional field like cbc:BuyerReference is simply omitted from the XML when the buyer hasn't supplied one, rather than being written as an empty tag.
FAILS ✗: The same field written as <cbc:BuyerReference></cbc:BuyerReference> because the invoice template always emits the tag and only conditionally populates it, and the conditional logic wasn't extended to suppress the tag itself when no value is available.
What Your ERP / IT Team Must Ensure
Audit the XML generation logic for any field that is populated conditionally — the conditional needs to control whether the tag is written at all, not just whether it's populated. This is a common gap in template-driven exports built by copying a "complete" example invoice and then trying to make fields optional after the fact, since removing a value from a template is easy but removing the tag itself under the right condition is often missed. Run a validation pass specifically looking for self-closing or whitespace-only tags across a sample of real invoices before go-live, since this failure mode tends to surface only on the specific transaction types where optional fields are actually left blank.
Related Rules
This rule sits underneath every other field-level requirement in the series — a field that is correctly optional under, for example, the base quantity rules covered from BR-01 onward must still be fully absent, not present-and-empty, to pass validation.