If your company invoices other businesses or government bodies in the UAE, your invoicing is about to become a software project. Under the UAE's mandatory e-invoicing programme, a PDF emailed to a customer will no longer count as a tax invoice for in-scope transactions. Invoices must be issued as structured data, sent through an accredited provider and reported to the Federal Tax Authority (FTA).
Most of the advice online is written by tax advisers and e-invoicing vendors, and it focuses on the law. This guide focuses on the other half of the job: what your ERP, billing system or in-house software actually needs to do, and how to plan that work without a last-minute scramble.
It is a practical overview, not tax advice. Confirm your own obligations with your tax adviser and the FTA, because the rules have been amended several times during 2026.
The timeline in brief
The phases are set out in Ministerial Decision No. 244 of 2025, with later amendments. As reported by advisers including Taxually, VIVOS and UAE Inform in October and November 2026:
- 1 July 2026: pilot programme and voluntary adoption opened.
- 30 October 2026: deadline for businesses with annual revenue of AED 50 million or more to appoint an Accredited Service Provider (moved from 31 July 2026).
- 1 January 2027: go-live for businesses with revenue of AED 50 million or more.
- 31 March 2027: deadline for businesses under AED 50 million, and for government entities, to appoint a provider.
- 1 July 2027: go-live for businesses under AED 50 million.
- 1 October 2027: go-live for government entities.
Revenue is measured on the most recent accounting period. B2B and B2G transactions are in scope; B2C sales are excluded for now, with no date set for bringing them in. There are specific exclusions, for example some passenger transport and certain financial services, so check where your transactions sit.
If you are a smaller business, July 2027 can sound distant. In software terms it is not. Choosing a provider, cleaning master data, building the integration and testing it properly takes months, and every other company in your bracket will be doing the same thing at the same time.
How the UAE model works
The UAE uses what the Ministry of Finance calls a decentralised continuous transaction control and exchange model, built on Peppol. Advisers usually describe it as a "five-corner" model:
- You, the supplier, create the invoice.
- Your Accredited Service Provider (ASP) validates it and sends it on.
- Your buyer's ASP receives it.
- Your buyer gets it in their system.
- The FTA receives the tax data.
Two points matter for your software. First, you cannot connect to the FTA directly; every in-scope business, whether issuing or receiving invoices, must appoint an ASP. Second, unlike Saudi Arabia's clearance model under ZATCA, the FTA does not approve each invoice before it reaches the buyer. Your system still has to produce correct data first time, because errors become corrections and credit notes rather than rejected drafts.
Invoices must follow the PINT AE specification, the UAE version of the Peppol international invoice format, as structured XML. A PDF, scan or Word file is not an e-invoice. KPMG's summary of the FTA's February 2026 technical guidance lists 51 mandatory fields for an electronic tax invoice, grouped into invoice details, seller, buyer, totals, tax breakdown and line items, plus transaction-type flags such as free-zone or margin-scheme supplies.
What your billing system or ERP must be able to do
Whatever software you use, it needs to cover the following. This is where most of the real work sits.
- Produce complete, structured invoice data. Every mandatory field, in the right format, with the right transaction flags. If your current system prints a nicely laid-out PDF but stores half the information as free text, that needs fixing.
- Hold clean master data. Your TRN, legal names and addresses for customers, and the VAT treatment of each line. Buyers are identified on the network by a participant ID based on their tax number, so customer records need that information too.
- Talk to your ASP. Usually through an API or a connector the ASP provides. Your system sends invoices, receives status messages and stores the response.
- Handle the awkward cases. Credit notes for cancellations, price changes and refunds; self-billing; exports to buyers who are not on the network; buyers who have not onboarded yet. Advisers report the FTA has published placeholder identifiers for some of these cases, and your system must know when to use them.
- Receive invoices, not just send them. From your go-live date, suppliers will send you e-invoices. Your accounts payable process needs to accept structured invoices and match them to purchase orders.
- Meet the timing rule. E-invoices must be issued and transmitted within 14 days of the transaction (or of payment, if earlier). Your system should flag anything at risk of missing that window.
- Keep an audit trail. Store what was sent, when, and what the ASP returned, for the retention period required.
The penalties make this worth getting right. Under Cabinet Decision No. 106 of 2025, as summarised by several advisers, failing to implement the system or appoint an ASP on time can cost AED 5,000 for each month or part of a month, and each e-invoice not issued on time can cost AED 100, capped at AED 5,000 per month. VIVOS reports a newer penalty decision announced on 30 October 2026, so check the current amounts with your adviser.
Three starting points, three different projects
How much work you face depends mostly on what you run today.
A mainstream accounting or ERP package
Many established packages are working with ASPs on connectors. Your job is mainly to choose an ASP that supports your package, clean up master data, configure the mapping and test. The risk is assuming the vendor has done everything; ask exactly which document types and edge cases the connector supports.
A custom or in-house system
If you invoice from software built for your business, nobody else is going to make it compliant. You will need a developer to add the missing fields, build the ASP integration, add credit-note and exception handling, and set up monitoring. This is often a well-defined project of a few weeks to a few months, depending on how tidy the existing data model is.
Spreadsheets and manual invoicing
This is the hardest starting point. You need a proper invoicing system before you can do e-invoicing at all. That may be a good moment to decide whether an off-the-shelf package fits your business, or whether a simple custom system that matches the way you sell is the better long-term choice. Leave enough time: you are choosing and adopting a system and making it compliant, in one go.
A sensible project plan
Whichever route you take, the work tends to follow the same order:
- Confirm your phase and dates with your tax adviser, based on revenue and transaction types.
- Inventory your invoicing. Which systems issue invoices, credit notes and self-billed invoices? Which receive supplier invoices? Many businesses find more than one.
- Gap-check your data against the mandatory field list. This is usually the most revealing step.
- Shortlist ASPs based on support for your software, pricing, how they handle credit notes and exceptions, and archiving.
- Build or configure the integration, including error handling and alerts.
- Test with real scenarios: a normal invoice, a credit note, an export, a free-zone supply, a buyer who is not onboarded, a failed transmission.
- Use the voluntary window. Voluntary adoption has been open since July 2026, so you can run live before your mandatory date rather than on it.
Where an outside development team helps
Tax advisers tell you what the law requires and ASPs move the data. The gap in the middle, changing your own software so it produces the right data and handles the exceptions, is development work.
At NextiForce we build and maintain custom business software, including billing and stock systems such as the business management system and cashier screen we built for Fazal Traders, and a multi-tenant invoicing and inventory SaaS for GNL Pakistan. For a UAE e-invoicing project we would start with a short review of your current invoicing flows and data, give you a written scope covering fields, ASP integration, exception handling and testing, and then deliver in weekly releases you can test against your ASP's sandbox. You can see the kinds of systems we build in our case studies.
If you also operate in Saudi Arabia, the ZATCA requirements are different in important ways; our guide to outsourcing software development for Saudi businesses covers them.
If your billing system needs to be ready for UAE e-invoicing, tell us what you run today and a senior engineer will reply within one business day with an honest view of the work involved.