Source: PINT-AE BIS Invoice v1.0.2 Schematron

Rule at a Glance

ID Severity Context (XPath)
BR-25 Fatal (error) ubl:Invoice/cac:InvoiceLine / cac:CreditNoteLine
Schematron ID: ibr-025  |  Field: IBT-153 (Item name)

Classification

Master Data — BR-25 validates that every invoice line contains a non-empty item name within cac:Item/cbc:Name. Item names come from the seller's item master or service catalogue, making this primarily a master data quality issue rather than a transactional data problem. If your catalogue carries blank or whitespace-only names for any item, every invoice line referencing that item will fail BR-25.

What the Rule Is Checking

The rule applies normalize-space() to the cac:Item/cbc:Name value, which strips leading and trailing whitespace and collapses internal whitespace runs to a single space. After that normalisation, the result must not be an empty string. This means both a completely absent cbc:Name element and an element containing only spaces will fail the rule.

BR-25 checks only that a name exists and is non-empty. The standard does not constrain the content of the name — there is no maximum length at the schematron level (though practical limits apply in the UBL schema), and the name does not need to match any external code list. Content quality — whether the name is meaningful, accurate, or describes the supply correctly under UAE VAT — is a governance question beyond the rule's scope.

Why This Rule Exists

UAE VAT legislation (Federal Decree-Law No. 8 of 2017, Article 59) requires a tax invoice to include a description of the goods or services supplied. The PINT-AE mandatory field IBT-153 gives that requirement a structured form. At Corner 5, the authority receives line-level descriptions as part of the invoice data payload — an empty name field means the authority cannot identify what was supplied on that line from the structured data alone.

There is also a practical VAT audit risk. A buyer claiming input tax recovery on a line with an empty item name carries a documentation gap the authority can challenge. The e-invoice system cannot substitute a narrative description from attached PDFs; the structured XML fields carry the legally relevant data.

UAE Data Example

PASSES ✓
<cac:Item>
  <cbc:Name>Industrial Air Compressor — Model AC-750</cbc:Name>
</cac:Item>

<cac:Item>
  <cbc:Name>Consulting Services — ERP Tax Configuration</cbc:Name>
</cac:Item>

FAILS ✗
<cac:Item>
  <cbc:Name>   </cbc:Name>
  <!-- Only whitespace — normalize-space() returns empty, BR-25 fatal -->
</cac:Item>

<cac:Item>
  <!-- No cbc:Name element at all — BR-25 fatal -->
</cac:Item>

What Your ERP / IT Team Must Ensure

  • Audit your item master for records where the item name field is blank, null, or populated with placeholder text (dashes, "N/A", internal codes with no description). Every such record will generate BR-25 failures on every invoice that references it.
  • Add a validation constraint at item master entry — the name field should be non-nullable and must not accept whitespace-only values. This is a data governance control, not a fix to apply at XML generation time.
  • For service lines created ad hoc (not from a catalogue), ensure your invoicing workflow requires a description before the line can be saved. Blank service descriptions are the most common BR-25 source in professional services firms.
  • Do not rely on the item description field (IBT-154, cbc:Description) as a substitute for the item name. IBT-154 is optional; IBT-153 is mandatory. The schematron rule checks the Name element specifically.
  • If your ERP maps internal item codes to display names at print time, confirm that the PINT-AE XML generation uses the display name, not the internal code. An invoice line showing "MAT-00847" with no expansion fails the intent of the rule even if the text is non-empty.

Related Rules

BR-24 (line net amount) · BR-26 (item net price) · IBR-SR-50 (item description maximum one occurrence)