Source: PINT-AE BIS Invoice v1.0.2 Schematron — Jurisdiction-Aligned (UAE) Business Rules

Rule at a Glance

ID Severity Context (XPath)
Series ref. BR-118 | Schematron ID: ibr-103-ae Fatal (error) cac:InvoiceLine/cac:Item/cac:ClassifiedTaxCategory (AE, VAT) | cac:CreditNoteLine equivalent

Assert text: [ibr-103-ae]-When the Invoiced item VAT category code (ibt-151) is VAT reverse charge, then Buyer VAT identifier (ibt-048) MUST be provided.

Test: exists(../../../cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID)

Classification

Transaction Data / Conditional (VAT-treatment-driven).

What the Rule Is Checking

Wherever an invoice line carries the VAT category code 'AE' — reverse charge — this rule requires the buyer's VAT identifier, held in the Party Tax Scheme block at the invoice header level, to be present. It checks upward from the line item through three levels of the document tree to confirm the header-level buyer VAT number exists whenever any line uses reverse charge treatment.

Why This Rule Exists

Reverse charge shifts the obligation to account for VAT from the supplier to the buyer, which only functions as a compliance mechanism if the buyer is an identifiable, VAT-registered party who can actually self-account for the tax on their own return. An invoice that applies reverse charge treatment to a line without naming a VAT-registered buyer is asserting a tax position with no counterparty capable of fulfilling it — the field exists to make that counterparty verifiable, in the same way ibr-162-ae then requires the line VAT amount itself to sit at zero once reverse charge is asserted.

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>
...
<cac:ClassifiedTaxCategory>
  <cbc:ID>AE</cbc:ID>
  <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
</cac:ClassifiedTaxCategory>

FAILS ✗

<!-- no cac:PartyTaxScheme on AccountingCustomerParty -->
...
<cac:ClassifiedTaxCategory>
  <cbc:ID>AE</cbc:ID>
  <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
</cac:ClassifiedTaxCategory>

The line-level reverse charge classification is well-formed on its own, but without a buyer VAT identifier anywhere on the document the rule fails — this is one of a small number of rules that reaches from a line-level condition up to a header-level field, so line-level testing in isolation will not catch it.

What Your ERP / IT Team Must Ensure

  • Validate that reverse-charge tax codes cannot be applied at the line level in the ERP's tax determination engine unless the customer master record already carries a verified VAT registration number.
  • Treat this as a hard block in procurement or sales order processing for reverse-charge-eligible transactions (commonly imports of services, or specified domestic reverse-charge goods) rather than a warning that can be overridden.
  • Cross-check against ibr-162-ae, which requires the VAT line amount to be zero on the same reverse-charge line, and ibr-174-ae, which requires a specific item standard identifier scheme — all three fire together on the same line context and should be tested as a set.
  • Confirm the buyer VAT number captured matches the format and checksum UAE FTA registration numbers follow, since a malformed but present value will pass this particular rule while still failing validation elsewhere.

Related Rules

No directly related published rule posts yet in this series.