Good morning, or good evening, wherever you are watching. Today I'm walking through the UAE E-Invoicing module we've built for ERPNext. We released it a few days ago, and Umair and Husna were scheduled to host a full webinar — that's still coming. But because many users were already asking for a getting-started guide, I wanted to put this together so you have something to work with in the meantime.
What Is This Module?
The UAE E-Invoicing app is 100% open source — consistent with what we've done for Saudi Arabia, Malaysia, and other countries. It's comprehensive, it includes ZATCA compliance support, and we've published full documentation. It's also available directly on Frappe Cloud — I'll put the link below the video.
The Core Concept: Why E-Invoicing?
The UAE government has made it mandatory for all B2B (business-to-business) companies to submit invoices directly to the government. This is already live in several countries. In Saudi Arabia, we've been running this for over two years, and it's now widely adopted across the ecosystem — partners, clients, everyone.
Since many of our clients operate in both Saudi Arabia and the UAE, I'll draw comparisons between the two systems throughout this walkthrough. It's the easiest way to explain the differences.
Key Difference #1: You Cannot Submit Directly to the UAE Government
This is the most fundamental difference from other countries.
In Saudi Arabia, you submit directly to ZATCA — the government's tax authority. In Malaysia, you submit directly to the government server. But in the UAE, you cannot submit directly to the FTA (Federal Tax Authority). Instead, you must go through what is called a pre-approved e-invoicing service provider, also known as an Accredited Service Provider (ASP).
Becoming a direct e-invoicing provider yourself is a complicated, expensive, and time-consuming process. We are not going down that route. Instead, our module integrates with pre-approved ASPs.
The list of approved providers is published on the Ministry of Finance website. If a provider is not on that list, do not use them. We've built all the listed providers into the module's settings page, and we'll add new ones as they are approved.
We have no commercial interest in any particular provider — this is open source and we're not earning commissions. Shop around, negotiate a good deal, and go with whichever provider suits you best. For our own testing, we used a provider called Waek (number 15 on the list), and you can request sandbox credentials from them to get started.
Key Difference #2: UAE Requires Only B2B Submissions
In Saudi Arabia, you must submit both B2C (business-to-customer) and B2B invoices. For high-volume businesses — supermarkets, hypermarkets — this means hundreds of thousands of invoice submissions per day.
In the UAE, as of today, you only need to submit B2B invoices. This is a significant relief. If you're selling to consumers, you don't need to submit those invoices. But for most companies in the UAE — especially those doing business across industries and free trade zones — B2B selling is the core of operations, so this still applies broadly.
Key Difference #3: UAE Requires Purchase Invoice Submission Too
In Saudi Arabia, you submit sales invoices, credit notes, and debit notes. In the UAE, you must submit both sales invoices and purchase invoices. This is an important distinction to understand before you begin implementation.
Key Difference #4: No QR Code Requirement
In Saudi Arabia, when you submit an invoice to ZATCA, you receive a QR code that must be printed on the invoice. Anyone scanning it via the ZATCA app can verify that it's an authorised, submitted invoice.
In the UAE, there is no QR code requirement. You may print one for internal purposes if you wish, but it is not a government requirement. Instead, when you submit, you receive a JSON or XML response — more on that shortly.
How the Submission Flow Works: The Five-Corner Model
The UAE uses what is technically called a five-corner model. Here's how it works:
You (the seller) create a sales invoice.
You submit it to your ASP (Accredited Service Provider).
Your ASP submits it to the FTA.
The FTA routes it to the buyer's ASP — which may be a different provider entirely. There's no requirement for the buyer and seller to use the same ASP.
The buyer's ASP delivers it to the buyer.
From the buyer's perspective, what you submitted as a sales invoice arrives as a purchase invoice on their side. This is why the UAE module handles both — submission and receipt.
Implementation Timeline
The FTA has published a clear timeline:
July 2026 (next month): Readiness and sandbox testing begins. You can start submitting test invoices now without any tax liability.
31 July 2026: Mandatory go-live for companies with annual turnover above AED 50 million.
31 March (24 months later): Mandatory for all remaining companies below that threshold.
AED 50 million is not a very high threshold in the UAE context. Thousands of companies will need to be live by 31 July. If you are on ERPNext now — or migrating to it — I strongly recommend starting your sandbox testing immediately.
The Technical Standard: PEPPOL
The UAE follows the PEPPOL framework — a European and Latin American standard that is widely used globally for e-invoice submission. The format of the XML or JSON you submit follows PEPPOL specifications. We've already implemented this in the module, so you don't need to build the format yourself.
Module Walkthrough
Company Settings
The UAE E-Invoicing configuration lives on the Company page in ERPNext, under a section called UAE E-Invoicing Settings. We put it here — rather than a global settings page — because many users have multiple companies, each with different tax registrations and ASP credentials.
The key fields are:
Enable UAE E-Invoicing toggle
Accredited Service Provider — select from the built-in list
Base URL, Participant ID, and API Token — provided by your ASP
Client ID and Client Secret — for access token management (tokens typically expire every 60 minutes; the module handles renewal automatically at the time of each submission)
Webhook configuration — your ASP will provide a UUID and secret for receiving incoming invoices
Once you enter your credentials and click Verify Token, the module will confirm authentication and retrieve your participant details. We store all ASP and FTA responses as-is — we don't transform them — for audit and legal purposes.
Sales Invoice Submission
When creating a sales invoice, you'll see additional UAE-specific fields:
VAT Category — Standard rate, zero rate, exempt, reverse charge, not subject to VAT, or margin scheme
Billing and Payment Code — frequency/method (monthly, weekly, etc.)
Trade zone details — relevant for free zones in Dubai and elsewhere
For most businesses, you'll set these as defaults so you don't need to fill them in on every invoice.
Once you save and submit:
The invoice is sent to your ASP.
You receive an ASP response — success or failure.
The status shows as FTA Pending while the FTA processes it (typically 3–5 seconds in testing).
You can click Check Status to refresh, or wait for the automatic update.
Once approved, the status updates to FTA Reported.
If you receive a rejection, correct the relevant fields and resubmit.
After a successful submission, the invoice record will have three attachments: a JSON file (what was submitted), an XML file, and a PDF of the invoice. These are generated and attached automatically.
Purchase Invoice — Receiving Incoming Invoices
This is where the UAE module differs significantly from Saudi Arabia.
When another party issues a sales invoice against you, it travels through the ASP network and arrives at your system via webhook as an incoming purchase invoice. These are logged in a new DocType: FTA UAE Incoming Invoice List.
From there, you have two options:
If you've already created a purchase invoice (some accountants do this proactively): Use the Match and Approve button on the purchase invoice. The system will check whether a matching FTA invoice exists and approve it.
If you haven't created one yet: Go to the incoming invoice log, select the relevant entry, and click Get FTA Incoming Invoice to import it directly into a new purchase invoice.
By default, we do not automatically post incoming invoices to your accounts. We log them and let your team review before posting — this is intentional, to avoid automatic changes to your books. However, if you prefer automatic posting, there is a setting for that on the configuration page.
Reports and Dashboard
The module includes:
UAE Invoice Dashboard — overview of submitted sales and purchase invoices
Tax submission reports — all invoices by tax rate, for VAT filing
Submission log — full record of every submission and response
Webhook log — all incoming webhook events
Failed invoice report — quick access to invoices that were rejected or errored
We'll continue adding reports based on feedback. There's also an error log for troubleshooting any submission failures.
Getting Started
If you're self-hosting, install the app via standard bench commands:
bench get-app <repo-url>
bench --site yoursite install-app erpgulf_uae_einvoicingIf you're on Frappe Cloud, search for the UAE app in the marketplace.
For support, reach us at support@erpgulf.com or open an issue on GitHub. Like our Saudi module, we expect to continue refining this based on real-world feedback as clients go live. Thank you for joining us.
For questions and a more detailed walkthrough, a full Q&A webinar with Husna is coming soon.
Curious to see how it works? Watch the full video walkthrough and explore the solution in action:
▶ https://youtu.be/Z8n6A0ObsiE
Discover key features, real-world use cases, and the value it can bring to your business.
