Source: PINT-AE BIS Invoice v1.0.2 Schematron — PINT UBL Validation Rules (UAE jurisdiction-aligned)

Rule at a Glance

ID Severity Context (XPath)
Series ref. BR-97 | Schematron ID: ibr-177-ae Fatal (error) cac:AccountingSupplierParty/cac:Party

Assert text: [ibr-177-ae]-Either Seller tax registration identifier (IBT-032) or Seller tax identifier (IBT-031) MUST be provided

Test: not(matches(cbc:ProfileExecutionID, "^[01]{5}1[01]{2}$")) or cac:PartyTaxScheme/cbc:CompanyID != cac:PartyIdentification/cbc:ID

Classification

Transaction Data, evaluated against the profile execution flags carried on the invoice. The rule engages a specific transaction-type condition rather than applying unconditionally to every seller party.

What the Rule Is Checking

Seller party identification separates two distinct concepts: the seller tax identifier (IBT-031), the general identifier used to recognise the seller as a taxable person, and the seller VAT registration identifier (IBT-032), the specific registration number under which VAT is accounted. The rule reads the invoice's profile execution flag — the bit string that signals which transaction-type conditions apply — and, where the relevant flag is set, requires that a real value be present and that it not simply duplicate the seller's general party identifier under cac:PartyIdentification/cbc:ID.

In plain terms: for the class of transaction this flag identifies, the seller's tax registration cannot be inferred from the seller's general business identifier. It has to be stated as its own value.

Why This Rule Exists

A trade licence number, a chamber of commerce registration, and a VAT registration number are three different identifiers a UAE seller may hold, and only one of them is the tax registration the FTA matches invoices against. Systems that populate the seller identification block from a single "company ID" field in the ERP master risk repeating the same value in both PartyIdentification and PartyTaxScheme, which looks complete on inspection but tells the receiving system nothing distinctive about the seller's tax standing. The rule forces the two to diverge where the transaction type requires a genuine tax registration to be visible.

UAE Data Example

PASSES ✓

<cac:AccountingSupplierParty>
  <cac:Party>
    <cac:PartyIdentification>
      <cbc:ID>CN-1234567</cbc:ID>
    </cac:PartyIdentification>
    <cac:PartyTaxScheme>
      <cbc:CompanyID>100234567800003</cbc:CompanyID>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
    </cac:PartyTaxScheme>
  </cac:Party>
</cac:AccountingSupplierParty>

Trade licence number and VAT registration number stated as two distinct values.

FAILS ✗

<cac:AccountingSupplierParty>
  <cac:Party>
    <cac:PartyIdentification>
      <cbc:ID>CN-1234567</cbc:ID>
    </cac:PartyIdentification>
    <cac:PartyTaxScheme>
      <cbc:CompanyID>CN-1234567</cbc:CompanyID>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
    </cac:PartyTaxScheme>
  </cac:Party>
</cac:AccountingSupplierParty>

The same trade licence number is echoed into the tax scheme identifier for a transaction where the flag requires a genuine, distinct VAT registration value. The document fails on the relevant transaction types even though a value is technically present.

What Your ERP / IT Team Must Ensure

  • Hold seller trade licence, chamber registration, and VAT registration number as separate fields in the business master data, never as one shared "company identifier" copied into multiple UBL locations.
  • Confirm the mapping populates PartyTaxScheme/CompanyID from the actual FTA VAT registration record, not from whichever generic company code is easiest to source at invoice-build time.
  • Test the specific transaction-type profile that triggers this rule, since it does not apply universally — a mapping that passes on standard domestic sales can still fail on the flagged transaction class.
  • Reconcile this rule with ibr-178-ae, which separately governs the tax scheme code that must accompany the registration identifier once it is present.

Related Rules