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-95 | Schematron ID: ibr-179-ae Fatal (error) cac:AccountingCustomerParty/cac:Party

Assert text: [ibr-179-ae]-Buyer tax identifier (IBT-048) MUST occur maximum once

Test: count(cac:PartyTaxScheme/cbc:CompanyID) <= 1

Classification

Transaction Data. The rule checks the shape of the buyer party block as it is assembled for a specific invoice, not how the buyer's tax registration is held in the customer master.

What the Rule Is Checking

Buyer tax identifier (IBT-048) is the buyer's VAT registration number, carried inside cac:PartyTaxScheme/cbc:CompanyID under the buyer party. The rule counts how many cbc:CompanyID elements appear under that path and fails if more than one is present. Zero is allowed — not every buyer is VAT-registered — but a document cannot assert two different tax identifiers for the same buyer.

This is distinct from the buyer's legal registration identifier (IBT-047), which sits under cac:PartyLegalEntity and is governed separately. A buyer can legitimately carry one legal registration identifier and one tax identifier at the same time; what it cannot carry is two of either.

Why This Rule Exists

The buyer tax identifier is what the recipient's own VAT system and, ultimately, the FTA use to match the invoice against the buyer's registration record. A single, unambiguous value is what makes that match deterministic. Two tax identifiers on one buyer party leaves the receiving system to guess which one is authoritative, and an authority reconciling declared input VAT against transmitted invoices has no basis to choose between them.

The failure mode this rule catches is usually structural rather than deliberate: a mapping that populates PartyTaxScheme once from the customer master and once again from a transaction-level override, without suppressing the first when the second is present.

UAE Data Example

PASSES ✓

<cac:AccountingCustomerParty>
  <cac:Party>
    <cac:PartyTaxScheme>
      <cbc:CompanyID>100234567800003</cbc:CompanyID>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
    </cac:PartyTaxScheme>
  </cac:Party>
</cac:AccountingCustomerParty>

One buyer VAT registration number, cleanly asserted.

FAILS ✗

<cac:AccountingCustomerParty>
  <cac:Party>
    <cac:PartyTaxScheme>
      <cbc:CompanyID>100234567800003</cbc:CompanyID>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
    </cac:PartyTaxScheme>
    <cac:PartyTaxScheme>
      <cbc:CompanyID>100234567800011</cbc:CompanyID>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
    </cac:PartyTaxScheme>
  </cac:Party>
</cac:AccountingCustomerParty>

Two PartyTaxScheme blocks under the same buyer party, each carrying a different registration number. The document fails regardless of which value is correct.

What Your ERP / IT Team Must Ensure

  • Map the buyer VAT identifier from a single authoritative field in the customer master, and suppress any secondary or historical registration number carried on the same record.
  • Where a transaction can override the customer master value — a one-off buyer, a group entity billed under a different registration — the mapping must replace, not append to, the master data value.
  • Audit customer records with multiple active VAT registrations (common after a group restructure or entity merger) before go-live, since these are the accounts most likely to trigger this failure.
  • Keep buyer tax identifier and buyer legal registration identifier in separate, independently validated mapping paths so a fix to one does not introduce a duplicate in the other.

Related Rules