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-98 | Schematron ID: ibr-178-ae Fatal (error) cac:AccountingSupplierParty/cac:Party

Assert text: [ibr-178-ae]-Tax scheme code, if provided in (IBT-031-1) shall be '!VAT' when Seller tax registration identifier (IBT-032) is provided

Test: (count(cac:PartyTaxScheme) = 2 and count(cac:PartyTaxScheme[cac:TaxScheme/cbc:ID = "VAT"]) = 1) or count(cac:PartyTaxScheme) < 2

Classification

Transaction Data. The rule governs the internal consistency of the seller's tax scheme block on the specific invoice, checking that the two identifiers it can carry are tagged correctly against each other.

What the Rule Is Checking

A seller party can carry up to two cac:PartyTaxScheme blocks: one for the seller tax identifier (IBT-031) and one for the seller VAT registration identifier (IBT-032). Where both are present — two PartyTaxScheme elements on the seller — exactly one of them must be tagged with tax scheme code VAT. Read together with the label ibr-178-ae carries in the guidelines — that IBT-031-1, the tax scheme code on the general tax identifier, should be something other than VAT — the effect is that the two blocks cannot both claim to be the VAT registration. One is the VAT scheme, the other is not.

If the seller carries only one PartyTaxScheme block, the rule does not engage; the ambiguity it checks for cannot arise with a single entry.

Why This Rule Exists

When a mapping populates both the seller's general tax identifier and its VAT registration number from source systems that were never designed to distinguish the two, a common failure is tagging both with the same scheme code — usually VAT, because that is the code most ERP tax configuration defaults to. That produces a document where a receiving system, or the FTA's own matching logic, cannot tell which of the two values is the actual VAT registration to validate the invoice against. The rule forces the scheme codes to disagree when two blocks are present, which is what makes the pair unambiguous.

UAE Data Example

PASSES ✓

<cac:PartyTaxScheme>
  <cbc:CompanyID>CN-1234567</cbc:CompanyID>
  <cac:TaxScheme><cbc:ID>TIN</cbc:ID></cac:TaxScheme>
</cac:PartyTaxScheme>
<cac:PartyTaxScheme>
  <cbc:CompanyID>100234567800003</cbc:CompanyID>
  <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
</cac:PartyTaxScheme>

One block tagged TIN, the other tagged VAT. Exactly one VAT-scheme entry among the two.

FAILS ✗

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

Both blocks tagged VAT. The document fails, because the two-block condition requires exactly one, not two, VAT-scheme entries.

What Your ERP / IT Team Must Ensure

  • Configure the tax scheme code mapping so the seller's general tax/company identifier and its VAT registration number are tagged from two distinct, deliberately maintained scheme code fields — not the same default value copied twice.
  • Where a source system genuinely has no separate general tax identifier, emit only the single VAT PartyTaxScheme block rather than duplicating it to satisfy a perceived "two fields" requirement.
  • Test this rule together with ibr-177-ae; both govern the same seller tax scheme structure, and a fix aimed at one can silently break the other if the two identifiers are conflated in the mapping.
  • Review UAE branch or free zone entities that hold more than one registration number, since these are the seller records most likely to populate both blocks and most likely to need the distinct-scheme-code fix.

Related Rules