- Most of a UAE e-invoicing project's real risk is measurable today, with no provider appointed and no software bought — because the risk lives in your data, not your connectivity.
- Twenty-five criteria across seven areas: your own party data, counterparties, line-level data, tax logic, edge-case documents, systems and process, and the honest gaps.
- Score each item Green (verified, with evidence), Amber (true in theory, untested) or Red (not true, or nobody can say). Ambers are Reds that haven't been tested yet.
- The work is provider-independent: whichever ASP you choose, this data work is yours and it transfers with you.
Across the GCC rollouts we have worked through, the pattern repeats: connecting to the network is the quick part; the slippage lives in the data. An e-invoice is not a PDF — every one is a structured document validated field by field before it moves. An invoice with a malformed identifier, a missing address element, or an unmapped tax category doesn't arrive late. It doesn't arrive at all.
Which means most of an e-invoicing project's real risk can be measured now, before a provider is appointed. The exercise below is the one we run before any implementation plan is written. The binding field definitions live in the Ministry of Finance publications and the PINT AE specification — the Ministry's field list defines 51 mandatory fields on an electronic Tax Invoice, and we keep a separate field-by-field guide to all 51, and what breaks. This checklist answers a different question: where will your data fail those definitions?
Rate each item Green (verified true today, with evidence), Amber (true in theory, unverified), or Red (not true, or nobody can say).
A. Your own party data
1. Every tax registration your group invoices under is current and matches the FTA record exactly — entity legal name included. Note that your participant identifier for e-invoicing is not the same thing as your 15-digit VAT TRN; the identifier rules are where we see the most rework.
2. Legal names in the ERP match the trade licence and tax registration character for character — including the "LLC" / "FZCO" suffixes and Arabic/English variants.
3. Registered addresses exist as structured data — emirate, country code, the elements the format requires — not as one free-text line.
4. Multi-entity groups: the entity → registration → issuing-system mapping is documented, current, and owned by a named person.
5. Branches and free-zone entities: you know which entity issues which invoice streams, and under which registration.
B. Counterparty data
6. Customer master records carry the buyer's tax identifier where the buyer is registered — collected, current, and validated, not merely present.
7. You can distinguish, in data, which flows are B2B, B2G and B2C — because obligations and timelines differ by flow.
8. Supplier records carry the same discipline: under the UAE's exchange model you will be a Recipient as well as an Issuer.
9. Duplicate counterparty records are identified and merged. One customer existing three times is three chances to invoice against the wrong record.
C. Line-level data
10. Every sellable item carries a description and a unit of measure from a controlled list — not free text improvised at invoice entry.
11. Tax category is held per line, not inferred from the customer or the document total. The mandatory list is line-heavy: 13 of the 51 fields sit on the invoice line.
12. Discounts, charges and rounding are represented as structured elements, not buried in a line description or a netted price.
D. Tax logic
13. Every VAT treatment you actually use — standard, zero-rated, exempt, out-of-scope, reverse charge — is mapped to the correct code in the invoice format, and someone has confirmed the mapping against the current specification.
14. Foreign-currency invoices: the exchange-rate source is defined, and the line-level AED amounts the Tax Invoice requires can actually be produced by your systems. In our experience this is where an otherwise clean integration becomes engineering.
15. Rounding behaviour at line level versus document level is known, consistent, and matches what your ERP actually does — not what its manual says.
E. Documents beyond the clean invoice
16. Credit notes reference the original invoice in structured form.
17. The awkward flows are inventoried: debit notes, prepayments and part-deliveries, self-billing, agent arrangements, inter-company charges. In our implementation experience these — not standard invoices — are where validation failures concentrate.
18. For each awkward flow, someone has answered: which system issues it, what data it carries, and whether that data survives field-level validation.
F. Systems and process
19. The complete inventory of systems that issue invoices exists — including the edge cases: the POS, the subscription tool, the spreadsheet a branch still uses.
20. Manual and exception invoices have a defined route into the compliant flow. "We'll handle those by email" is a Red.
21. Invoice identifiers are unique across the group, and you retain — or your provider contract guarantees you retain — the transmission evidence: identifiers, timestamps and confirmations that prove issuance within the required window.
22. Retention: invoice data and its audit trail are kept for the full statutory period — five years after the relevant tax period as the baseline, longer where there is a dispute and for certain sectors such as real estate — in a form you can extract, whatever provider you use. Verify the current schedule in the Ministry's Electronic Invoicing Guidelines for your sectors.
23. Rejection handling has an owner: a named role that sees failures, fixes root causes in master data, and reissues within the deadline — not a shared inbox. (Why master data? See the rejection log as a data audit.)
G. The honest gaps
24. Every item above that scored Amber has a test date — an actual sample of production invoices run against the format's validation rules, not a workshop opinion.
25. Every item that scored Red has an owner and a date. A Red with no owner is the project plan's first slippage, already booked.
Ambers are the dangerous ones. They are Reds that haven't been tested yet.
Reading your score
More than a handful of Reds in sections A–C means the realistic critical path of your project runs through data remediation, not system integration — plan and budget accordingly, and be sceptical of any implementation estimate that didn't ask these questions first.
Heavy Ambers with few Reds is the most common profile we see: the organisation believes it is ready and has never tested the belief. One production-data validation run converts most Ambers into answers in days, not months.
And if the table is green with evidence attached: your e-invoicing project is genuinely an integration exercise, and a short one.
We publish the criteria because buyers decide better with the full picture. If you want a second pair of eyes on your scoring, the readiness assessment is the structured version of this exercise — and that conversation is free, with a senior practitioner.
Specifications are revised. This page carries a visible last-verified date for that reason — check the Ministry's primary documents before relying on any count or deadline.