- Your PDF invoice stops being the invoice. The invoice becomes structured data in the PINT AE format, sent through an Accredited Service Provider (ASP) and reported to the Federal Tax Authority (FTA).
- The first deadline is 30 October 2026. Businesses with revenue of AED 50 million or more must appoint an ASP by then and go live on 1 January 2027. Everyone else follows in 2027.
- This is a software change, not just a tax filing. Your data model, invoice and credit note flows, retries, and customer onboarding all need work. Choosing an ASP is only the first step.
UAE e-invoicing is a mandate under which B2B and B2G invoices must be created as structured data in the PINT AE format, exchanged between buyer and seller through accredited providers on the Peppol network, and reported to the FTA in near real time. PINT AE is the UAE's Peppol invoice specification, and an ASP is the provider you appoint to send, receive and report on your behalf. For custom billing systems, SaaS products and marketplaces, your software has to produce, validate and track these documents itself, or hand clean data to a provider that does.
This article is about the engineering side. It covers what the rules require of your software, what changed in October 2026, and what a development partner should build before 1 January 2027. It is not tax advice. Have your tax adviser confirm how the rules apply to your transactions.
Who is covered, and when
The scope is wide. According to EY's summary of Ministerial Decisions 243 and 244 of 2025, e-invoicing applies to all businesses conducting commercial transactions in the UAE, including nonresidents, unless specifically excluded. It also covers any person doing business in the UAE, whether or not they are VAT-registered. The mandate covers B2B and B2G transactions. B2C is excluded until further notice.
The rollout is phased by revenue and entity type:
| Group | Appoint an ASP by | Go live |
|---|---|---|
| Revenue of AED 50 million or more (Phase 1) | 30 October 2026 | 1 January 2027 |
| Revenue under AED 50 million | 31 March 2027 | 1 July 2027 |
| Government entities | 31 March 2027 | 1 October 2027 |
Source: UAE Inform, checked 19 October 2026. The Phase 1 ASP deadline was extended from 31 July 2026.
If you are in Phase 1 and have not appointed an ASP, do that before any code is written. If you are in the second group, you have more time, but the build work is the same.
How the Peppol model works
The UAE uses a decentralised Peppol five-corner model with the PINT AE format. Invoices become structured data exchanged through accredited providers and reported to the FTA in near real time, replacing PDF invoices.
In practice, five parties are involved:
- The seller, which is your software.
- The seller's ASP, which validates and sends the invoice.
- The buyer's ASP, which receives it.
- The buyer, whose system ingests it.
- The FTA, which receives the tax data.
Your software only talks to its own ASP. But everything you send must be right at the data level, because the buyer's system and the FTA both read it. The Ministry of Finance's public consultation document describes the PINT AE data dictionary as a structured catalogue of the data elements used to generate, exchange, process and report an e-invoice. That dictionary is your build spec. Every field your invoices need must exist somewhere in your system, in a usable form.
One common trap: existing Peppol connectivity from another country is not enough. You still need a UAE ASP, support for the PINT AE format, and tax data reporting to the FTA.
What changed in October 2026
Three recent changes affect your plan.
- Ministerial Decision No. 197 of 2026 took effect on 1 October 2026 and was announced on 19 October. It amends Decision 243 and leaves the 1 January 2027 go-live unchanged. It excludes transactions between members of the same VAT group for 24 months from 1 January 2027. It also removes the UAE-only data storage requirement and repeals the two-business-day system-failure notice (Enerpize, TaxAdepts).
- Ministerial Decision No. 168 of 2026 replaced the pre-approval stage for service providers with direct accreditation, effective 1 October 2026 (TaxAdepts).
- Providers that held pre-approval have 30 days from 1 October to complete accreditation or lose it (TaxAdepts).
For you, this has two practical effects. First, with the UAE-only storage requirement removed, you have more room to choose where invoice data is hosted. Check this against your other legal obligations before moving anything. Second, check the Ministry of Finance register before you sign with an ASP. A secondary source reports that, as at 10 October 2026, the register listed 69 accredited providers and 3 pre-approved providers still in final assessment. Confirm the current status of your provider on the official register, not from their sales page.
What it costs to be late
The Ministry of Finance's Cabinet Resolution on fines sets:
- AED 5,000 per month for failing to implement the system or appoint an approved service provider on time.
- AED 100 per e-invoice not issued or sent on time, capped at AED 5,000 per month. The same applies to credit notes.
The AED 5,000 fine applies per month "or part thereof". A delay of a few days counts as a full month, and two months late means AED 10,000 before any e-invoice is issued. Voluntary adopters are exempt from these fines until they become mandatorily subject to the system.
What your software has to build
Whatever your product type, the core work is the same. Here is what we would expect a development partner to cover.
1. A clean invoice data model
Map every field in the PINT AE data dictionary to a source in your system. Gaps show up quickly: customer tax identifiers, structured addresses, line-level tax categories, unit codes, payment terms. Many billing systems store these loosely, or only as text printed on a PDF. Fix this first, because everything else depends on it.
2. Customer and supplier onboarding
Your product needs places to capture and validate customers' tax details, and a defined path for customers who are not ready yet. Decide what happens when a B2B customer has missing data. Blocking the invoice and chasing the data is usually better than guessing.
3. An ASP integration layer
Do not wire your billing logic directly to one provider's API. Put an interface between them. Your code calls "submit invoice", and an adapter translates it for the ASP. That keeps a provider change from becoming a rewrite.
4. Asynchronous submission with proper state
Sending an e-invoice is not one request that either works or fails. An invoice moves through states: drafted, validated, submitted, accepted or rejected. Build a queue, store each state, make submissions idempotent so a retry never creates a duplicate, and surface rejections to a person with a clear reason.
5. Credit notes and corrections
Credit notes carry the same fine structure as invoices. If your current process is "edit the invoice and resend the PDF", that has to end. Corrections become new, linked documents. Refunds, partial credits and cancelled orders all need a defined path.
6. Receiving invoices, where relevant
If you are a buyer as well as a seller, you will receive structured invoices too. At minimum, store them and make them readable. Better, feed them into your accounts payable flow.
7. Audit trail and monitoring
Log what was sent, when, to whom, and what came back. Add alerts for stuck or rejected invoices. With a per-invoice fine, a silent queue failure can become a real cost quickly.
What it means for each type of product
| Product type | Main challenge | What to build |
|---|---|---|
| Custom billing or ERP | Invoice data scattered across modules, PDFs as the source of truth | Central invoice model, ASP adapter, credit note flow |
| SaaS with subscriptions | High volume, usage-based lines, proration, many small customers | Automated per-invoice submission, queue with retries, tax data capture at signup |
| Marketplace | Several parties in one transaction; unclear who invoices whom | A clear invoicing model per transaction type, confirmed with your tax adviser, then data capture for every party |
SaaS products feel the volume problem most. A subscription business can issue many small invoices in one billing run, so submission has to be automated, monitored and safe to retry. A manual fix-up process will not hold.
Marketplaces have the hardest design question. Depending on your contracts, the marketplace may invoice the buyer, the seller may invoice the buyer, or both may invoice for different parts of the transaction, such as goods and platform fees. Which applies is a tax and legal decision. Settle it before the build, because it determines your data model. For an example of a platform built around marketplace sellers' data, see our Xolt profit analytics platform.
Build the integration or buy it?
You are required to use an ASP, so the question is how much you build around it. There are three realistic options.
- Use your ERP or billing vendor's built-in support. This works if you run standard software and the vendor offers an accredited path. It is the least effort.
- Integrate your own product with an ASP's API. This is the usual route for custom software and SaaS. You control the data and the experience, and you carry the engineering work.
- Do both. Use the vendor tool for internal finance and build into your customer-facing product.
If you sell software with invoicing inside it, option two is usually the answer, because your customers will expect e-invoicing to work inside your product.
What to ask a development partner
Whoever you hire, ask these before you sign:
- Which ASPs have you integrated with, and are they on the Ministry of Finance register today?
- How will you map our data to the PINT AE data dictionary, and who signs off the mapping?
- How do you handle rejections, retries and duplicate prevention?
- What is tested before go-live, and against what environment?
- Who owns the code and the provider relationship afterwards?
Treat vague answers as a warning sign, especially to "what happens when the ASP is down?"
Timing, honestly
Phase 1 businesses must appoint an ASP by 30 October 2026 and go live on 1 January 2027, so the window for building is short. A focused integration on a well-structured system is a smaller job than a multi-product platform with messy invoice data. We would tell you which one you have during scoping, not after.
You can use our project planner to outline the work, or read how our pricing works. Our Dubai software development team can help, and you can see the kind of products we ship on our work page. For billing and platform builds, start from software development. If you want a straight read on your situation, get in touch.
FAQ
Does UAE e-invoicing apply to my business if I am not VAT-registered?
Yes, it can. The mandate covers any person conducting business in the UAE, whether or not VAT-registered, and applies to B2B and B2G transactions. B2C is excluded until further notice. Nonresidents conducting commercial transactions in the UAE are also in scope unless specifically excluded.
Can I use my existing Peppol setup from another country?
Not on its own. You still need a UAE Accredited Service Provider, support for the PINT AE format, and tax data reporting to the FTA. Your existing experience helps with the engineering, but the UAE requirements must be met separately.
What happens if I miss the 30 October 2026 ASP deadline?
The fine is AED 5,000 per month for failing to appoint an approved service provider on time, and it applies per month "or part thereof", so a few days late counts as a full month. Appoint as soon as you can, and confirm the provider's accreditation on the official register first.
Do transactions between companies in the same VAT group need e-invoices?
Ministerial Decision No. 197 of 2026 excludes transactions between members of the same VAT group for 24 months from 1 January 2027. Confirm with your tax adviser whether your group structure qualifies, and design your system so the exclusion can be switched off when the period ends.
Is the 1 January 2027 date still firm?
Decision 197 amended Decision 243 but left the 1 January 2027 go-live unchanged. Plan against that date.
