The Ministry of Finance publishes a list of fifty-one mandatory fields, and most readiness work begins and ends there: the fields are mapped, the export is adjusted, the project is declared complete. The field list is not, however, what an invoice is validated against. Validation is performed by a machine-readable rule set distributed with the PINT AE specification, and that rule set contains conditions the field list does not express — conditions on combinations of fields, on formats, and on what one value obliges you to provide elsewhere in the document.
We extracted the rule set from the official schematrons of PINT AE release 1.0.4, published 3 June 2026. The invoice rule set contains 302 rules, of which 95 are specific to the United Arab Emirates. The rule set for credit notes is identical. Every one of the 95 carries the severity level fatal: a breach is a rejection, not a warning.
A note on the release number, because it matters more than it looks. The specification is revised quarterly and has moved through five releases in twelve months. Rules have been corrected, and in one case the element carrying the exchange rate was moved. An implementation validated against an older release can be wrong in ways that are invisible until documents start being rejected. Every statement below was verified by execution against 1.0.4, not carried forward from an earlier reading.
Grouped by subject, the 95 rules fall out as follows.
| Subject | Rules |
|---|---|
| VAT categories and rates | 26 |
| Buyer identification | 10 |
| Seller identification | 10 |
| Transaction type and scenarios | 10 |
| Line-level amounts | 7 |
| Item description and classification | 7 |
| Currency and exchange rate | 5 |
| Tax registration number formats | 4 |
| Allowances, charges and payment | 4 |
| Credit notes and references | 4 |
| Invoice lines and pricing | 3 |
| Document identifiers | 3 |
| Addresses | 1 |
| Dates and periods | 1 |
The concentration in the first group is instructive. More than a quarter of the UAE-specific rules govern how a transaction is characterised for VAT — not how it is formatted. Characterisation is a judgement made once and then applied consistently, and no software makes it on your behalf.
The item type field is optional in the semantic model: it has cardinality 0..1, and no rule requires it to be populated. But the moment it is populated, classification becomes mandatory. Where the item is goods, a Harmonised System classification code is required; where it is services, a Service Accounting Code is required; where a line covers both, both codes are required. The scheme identifiers are fixed as HS and SAC respectively.
The two codes do not sit together. The HS code goes in the item classification element, where only the HS scheme is permitted; the SAC code goes in a separate additional-identification element. Implementations that place both in the same element are rejected on the second one.
Most businesses do not hold these codes in their item master at all. Populating them is not an adjustment to an export routine — it is work on the product and service catalogue, requiring a view on the correct classification of each item. It should be planned in months rather than days, and it is the element of readiness most likely to be discovered too late.
Every invoice line carrying a VAT category must also carry a line amount and a line VAT amount in a dedicated block. This applies to ordinary dirham invoices, not only to foreign-currency ones.
The field names in the specification include the words "in AED", but the executed rule does not test the currency attribute: in the official export example these amounts are stated in US dollars and the invoice validates. What is enforced is the presence of the block. For a foreign-currency invoice, the dirham total including VAT is carried separately at document level, and the total VAT in dirhams requires a second tax-total block of its own.
Both seller and buyer must state the basis on which they are registered: a commercial or trade licence, an Emirates ID, a passport, or a Cabinet decision. A trade licence additionally requires the name of the issuing authority; a passport additionally requires the issuing country code in ISO 3166-1 form.
The tax registration number is tested against a pattern, not merely a length: fifteen digits, beginning with 1 and ending with 03. A fifteen-digit number that does not meet the pattern is rejected.
A transaction type code is mandatory on every document: eight binary flags covering free trade zone, deemed supply, margin scheme, summary invoice, continuous supply, disclosed agent billing, e-commerce and exports. Exactly eight characters, each 0 or 1.
Each flag set brings its own further requirements, and they are not where you would look for them:
| Flag | What becomes mandatory | Where it lives |
|---|---|---|
| Free trade zone | Beneficiary identifier | Buyer customer party |
| Disclosed agent billing | Principal identifier, different from the seller's | Seller supplier party |
| Summary invoice | Invoicing period | |
| Continuous supply | Frequency of billing; if "other", a note explaining it | |
| E-commerce, Exports | Full delivery address with subdivision |
A flag set casually therefore produces a rejection that does not name the flag, but names the fields the flag required. Diagnosis is correspondingly slow.
Zero-rated, exempt and out-of-scope are three distinct categories, and the specification treats them differently in ways that catch implementations out. A zero-rated line carries a rate of zero. An exempt line carries no rate at all — not zero, absent — and no line VAT amount, but it does require an exemption reason code. An out-of-scope line carries no rate either, but does carry a zero VAT amount.
An invoice consisting solely of exempt and out-of-scope lines cannot be issued as a commercial invoice; it requires the out-of-scope document type. Reverse charge, in turn, requires a non-zero rate on the line with a zero VAT amount, plus a standard item identifier and a goods-or-services type from a dedicated list.
None of this can be derived from the field list. All of it is enforced.
Each rule carries a machine-readable test, and the two do not always say the same thing. Both observations below were confirmed by running official reference documents through the official validator with a single value altered in each case, on release 1.0.4.
The VAT category for standard rate with additional VAT is published in the official code list as the character Ν — the Greek capital letter nu. The executed rule tests membership of the set S, E, O, AE, Z, N, in which N is the Latin letter. The two characters are visually identical and are not the same character.
Substituting the value exactly as published in the code list produces a rejection for a category code outside the permitted list. Substituting the Latin letter is accepted. A business that copies the value carefully from the official source is therefore rejected, and will look for the error where it is not, because the difference cannot be seen.
Use the Latin letter.
The rule on country subdivisions states that where the country code is AE, the subdivision must be one of seven codes — AUH, DXB, SHJ, UAQ, FUJ, AJM, RAK — and it names the seller, buyer and delivery addresses as being in scope. Tested against all three, it fires for none of them.
The reason is structural. Within a schematron pattern, a node is processed by the first rule whose context matches it, and no other. The rules appear in this order:
rule context="cac:AccountingCustomerParty/cac:Party/cac:PostalAddress"
rule context="cac:AccountingSupplierParty/cac:Party/cac:PostalAddress"
rule context="cac:PostalAddress" <- the emirate rule
The buyer and seller addresses are claimed by the two more specific rules above and never reach the third. The delivery address is not in scope at all: it is carried in a different element, which the rule's context does not match. In a PINT AE invoice the only remaining postal address is that of a tax representative — an element most invoices do not contain.
The practical position today is that an invoice showing "Dubai" instead of "DXB" is accepted, although the rule as written forbids it.
This is not a reason to leave the data as it is. The requirement stands in the text of the specification; the behaviour of the validator is a defect that can be corrected in any quarterly release, and on the day it is corrected every affected invoice begins to fail at once. It is also the clearest illustration of why a readiness assessment should test against the rules as written, not only against what the validator currently happens to catch.
Of the 95 rules, twelve can be tested against a flat invoice register — the kind of export a finance team can produce without development work. The remaining 83 describe relationships between fields, structural conditions and dependencies that do not exist in a flat file; they can only be tested against a fully assembled document.
A register-level check is a useful first signal and will find missing tax numbers, malformed identifiers, arithmetic that does not reconcile and unclassified items. It cannot, and should not be presented as, a statement that invoices will be accepted. That statement requires the assembled document to be run against the rule set itself — and the release of the rule set it was run against should be stated alongside it, because "passes validation" without a version means very little.
The conclusion drawn from the field list — that fifty-one items must be populated — understates the work. The interdependencies outnumber the fields, and several of them, item classification in particular, reach into master data rather than into the invoicing process. A readiness assessment that examines only the fields will report a position more comfortable than the one that exists.
Where this page and a source disagree, the source is right. Tell us: hello@involane.com
Regulatory statements on this page come from the sources above. Anything about how long work takes, what it costs, or what companies typically do is our own estimate — it is not in any of them, and it carries no more weight than an estimate.
This material is provided for general information only and does not constitute tax, legal or accounting advice. Requirements and thresholds change; positions depend on individual circumstances. Consult a qualified adviser before acting.