UAE e-invoicing readiness: what your business must decide before buying software
Map your deadline, invoice data, existing software and operating responsibilities before choosing a UAE e-invoicing provider.
An e-invoicing proposal can arrive before anyone has traced how an invoice leaves your business. Sales creates the customer, finance adjusts the tax treatment, the accounting package produces a PDF, and someone emails it. Buying a connector without examining those steps leaves important decisions inside the supplier’s assumptions.
Start with a readiness map. It should tell you which obligations need accountant confirmation, where invoice data comes from, what your current software can supply, and who will operate the new process. Then you have something concrete to compare against a provider’s offer.
Rules checked: 30 September 2026. This guide explains operational preparation and source-backed rules. It is educational, not legal advice or a determination of your business’s obligations. Ask your accountant or qualified tax adviser to resolve scope and tax questions.
Establish the deadline before setting the project date
For persons and entities in scope, the amended schedule separates appointment of an accredited service provider (ASP) from implementation:
| Cohort | Appoint an ASP by | Implement by |
|---|---|---|
| Revenue equal to or exceeding AED 50 million | 30 October 2026 | 1 January 2027 |
| Revenue below AED 50 million | 31 March 2027 | 1 July 2027 |
| Government entities | 31 March 2027 | 1 October 2027 |
These dates come from Article 5 of Decision 244 as consolidated with amendment 66. The earlier 31 July 2026 appointment date for the first cohort was replaced by Decision 66. Some older official material still prints July; use the amended decision.
A signed provider agreement and an implemented invoicing process are separate milestones. Plan time between them for data repair, onboarding and tests. Use the deadline and scope worksheet before assigning a cohort, especially where revenue evidence or customer classification is unclear.
Trace the actual invoice, including the buying side
The FTA’s definition excludes unstructured PDFs, scans, Word documents and emails from e-invoices. A redesigned PDF template does not establish readiness for structured exchange and reporting.
Draw the current route for an ordinary invoice, a credit note and a supplier invoice. Include any spreadsheet, booking tool or sales application that contributes data. Write down where a person intervenes and what they change. A manual adjustment may be an important business control, or it may conceal missing data that the integration must now collect.
Include receipt and accounts-payable processing. Decision 243, Articles 5 to 7 addresses issuer and recipient responsibilities, including credit notes and processing received documents. An outbound export demonstration leaves the purchasing workflow unanswered.
For each step, identify the source record and responsible person. If the invoice shows a buyer address that exists only in someone’s saved email, record that gap before deciding which API to use.
Build a one-page readiness map
Copy this table into a working document. The evidence column should contain a record or a specific unresolved question, not a general assurance that someone is handling it.
| Decision | Evidence to collect | Suggested owner | Ready to proceed when |
|---|---|---|---|
| Scope and cohort | Entity, transaction mix, revenue evidence, adviser questions | Owner with accountant | Applicable dates and unresolved cases are documented |
| Billing and buying route | Systems, versions, manual steps, invoice and credit-note examples | Finance lead | Each document has a traceable source and destination |
| Data gaps | Field map and representative record checks | Finance and system administrator | Missing values have a repair plan and owner |
| Software route | Supported vendor option or documented integration constraints | Technical lead | Exact edition and proposed route can be evaluated |
| Provider selection | Registry status, written responsibilities, pricing and support terms | Contract owner | Proposal covers the actual workflow |
| Acceptance | Expected results and evidence required for each test | Finance and technical leads | Business and technical acceptance criteria are agreed |
| Ongoing operation | Reconciliation, incident handoffs, archive and exit arrangements | Named operator | Someone owns unresolved documents after launch |
Use an explicit status such as unresolved, evidence collected or decision approved. A blank cell is easy to overlook; an unresolved decision with a named owner is work you can schedule.
Diagnose data before deciding to replace software
Review invoice data readiness before treating a missing field as a software failure. Customer identifiers may need correcting in the existing system. A transaction classification may require an accountant’s decision. Neither problem is solved by moving the same records into a new package.
Evaluate the current software’s exact edition and version. Can it expose line-level data and credit-note references? Does its supported provider route cover your scenarios? What happens to incoming invoices? Ask for documentation and demonstrations using representative, anonymised examples.
The keep-or-replace decision guide helps separate data problems, access limitations and workflow shortcomings. Replacement may be justified, but it adds migration work that deserves its own evidence.
Buy defined responsibilities
Check the exact contracting entity in the MoF provider registry. It distinguishes accredited providers from pre-approved providers under final accreditation assessment. Save the checked status and date; a product logo is insufficient evidence.
Ask who supplies the integration, who repairs invalid customer records, and which statuses finance can see. The ASP contract questions turn these into a comparison sheet. If you want to understand the regulated provider role, read the separate accreditation guide.
Keep tax classification approval with qualified finance advisers. Describe the technical work separately from the ASP’s exchange and reporting services. Nesaku’s role in a systems review is to examine the existing workflow and proposed responsibilities; this guide does not claim Nesaku accreditation or a tested connector for your software.
Require evidence before handover
Agree tests before accepting the implementation. Include a correction, a credit note, an incoming invoice and a failed submission. Require an explanation of what each provider status proves. The acceptance-testing guide provides a worksheet for expected and observed results.
After launch, someone must investigate differences between source records and provider outcomes. Decide who can authorise a correction and who can safely retry a technical operation. Use the errors and ownership guide for those handoffs, then check record access and provider exit before relying on the provider’s archive.
Bring the readiness map, your software list and any provider proposal to a systems review conversation. Keep customer invoices and identifiers out of the public contact form. Start with the decisions you need help making, then agree an appropriate way to share evidence.
Sources and limits
Sources checked on 30 September 2026:
- FTA consolidated Decision 244 with amendment 66, Article 5. The English publication is marked as an unofficial translation.
- MoF Decision 66 of 2026, amended first-cohort appointment deadline.
- MoF Decision 243 of 2025, issuer and recipient responsibilities.
- FTA e-invoicing hub, structured-invoice definition.
- MoF provider registry, dynamic accreditation status. Recheck before contracting.
The map is a preparation tool. It does not certify compliance, establish a platform’s capabilities or replace advice on your specific facts.