Your ERP is not the problem. Your master data is.

Almost every conversation about UAE e-invoicing readiness starts with the ERP. Can it produce XML, does it have a connector, which version are we on. Those are real questions and they are usually not what delays a programme.

What delays programmes is that the data going into the invoice was never good enough to be checked by a machine, and nobody noticed because for twenty years a human read the PDF.

Why this is different from what came before

The UAE uses a decentralised continuous transaction control and exchange model. Your invoice is submitted to your accredited provider, validated, converted to the standard format, transmitted to your customer's provider and reported to the Federal Tax Authority — all as part of sending it. Validation happens before delivery, not during an audit two years later.

That inverts the economics of a data error. Previously a wrong customer name was a query at payment time. Now it can be a document that fails at corner two and is never delivered. The invoice is not late; it does not exist.

Five checks you can run this week

Export your customer master and twelve months of invoice lines. You do not need a provider, a budget or a project to do any of this.

1. Tax registration numbers

Count customer records with no TRN, with a TRN of the wrong length, with letters in a numeric field, or with the same TRN against several unrelated customers. In most mid-sized UAE businesses this is a double-digit percentage of the file. Every one is a potential validation failure and each takes an email to a customer and a wait to fix.

2. Legal entity names

Compare the customer name as held against the name on their trade licence. Trading names, abbreviations, an ampersand where the licence has "and", missing "LLC" or "FZ-LLC" suffixes. Machine validation does not exercise judgement about whether two strings mean the same company.

3. Addresses

Check whether addresses are held as structured fields or as a single free-text block. A structured specification needs discrete elements; a text blob that a human could read fine has to be parsed, and parsing legacy address text is slow, error-prone work.

4. Tax treatment consistency

Find item or service codes that have been invoiced under more than one VAT treatment over the year. Sometimes there is a good reason. Often it means the treatment was decided case by case by whoever raised the invoice, and that judgement now has to be encoded as a rule that produces a defensible answer every time.

5. Your document population

Count invoices and credit notes separately, including intercompany, and look at the peak month rather than the average. This drives provider pricing and it tells you the blast radius if something breaks: a business issuing 200 documents a month can reconcile failures manually for a while, one issuing 20,000 cannot.

Then look at the awkward transactions

Separately from data quality, list the transaction types in your business that are not a simple invoice for a simple supply. Self-billing arrangements. Agent and principal structures. Advance payments and the final invoices that must link to them. Multi-currency. Reverse charge. Disbursements and recharges. Credit notes raised long after the original.

These are what break in testing, and they break late, because test cycles naturally start with the straightforward cases. Identifying them early lets you put them in front of prospective providers during evaluation, which is both a better test of the provider and a shorter path to a working configuration.

Do not scope only the sales side

Recipients have obligations too: processing electronic invoices and credit notes through the system, and reporting their own side. It is common for a programme to be scoped entirely around accounts receivable and for accounts payable to surface late as an unbudgeted workstream.

For businesses below the AED 50 million threshold this matters sooner than the calendar suggests. Your own go-live is 1 July 2027, but your large customers and suppliers go live on 1 January 2027. You will be dealing with structured documents six months before your own obligation starts.

Two obligations that need an owner, not a project

Both are procedural, both are cheap to solve, and both are routinely unassigned:

• System failure notification. Issuers and recipients must notify the FTA within two business days of a system failure. Somebody has to be responsible for noticing, and there has to be a documented route. At AED 1,000 per day of delay this is the cheapest exposure on the list to eliminate.
• Registered data changes. When data registered with the FTA changes, you have five business days from the FTA confirming the amendment to notify your appointed provider. A trade licence renewal handled by an administrator who has never heard of your ASP is exactly how this one gets missed.

The point of doing this now

Data remediation is the one workstream that does not depend on having chosen a provider. It is also the one with the longest lead time, because a meaningful share of it requires other companies to reply to you. Running it in parallel with procurement rather than sequentially after it is, for most Phase 1 businesses still evaluating, the difference between a tight go-live and a missed one.

Sources: Ministerial Decision No. 243 of 2025, Articles 5 to 12; MoF eInvoicing portal, DCTCE process description; UAE Electronic Invoice mandatory field requirements.