What is e-invoicing integration in the UAE?
E-invoicing integration in the UAE is the connection between the software where your invoices are created and the Accredited Service Provider you appoint to exchange them. Without it, staff would have to re-key every invoice into a portal, which does not scale beyond a handful a day.
The Ministry of Finance defines an eInvoice as a structured form of invoice data exchanged electronically between supplier and buyer and reported to the Federal Tax Authority. Its e-invoicing portal is explicit that PDFs, Word documents, images, scanned copies and emails are not eInvoices. So the PDF your system emails today is not enough; the same invoice must also exist as machine-readable data in the agreed format.
That is why UAE e-invoicing integration is mostly about data. Your ASP handles the Peppol exchange and the reporting. What it cannot do is invent a buyer's tax registration number your system never captured, or guess which emirate an address belongs to. Integration means making sure your system holds every required value, formats it the way your ASP expects, sends it reliably, and records what happened.
When must UAE businesses go live with e-invoicing?
Businesses with revenue of AED 50 million or more must appoint an ASP by 30 October 2026 and implement e-invoicing by 1 January 2027. Businesses below AED 50 million must appoint an ASP by 31 March 2027 and implement by 1 July 2027. Government entities follow by 1 October 2027.
Those dates come from Ministerial Decision No. 244 of 2025 on the Implementation of the Electronic Invoicing System, as amended by Ministerial Decision No. 66 of 2026, which moved the first group's ASP appointment deadline from 31 July 2026 to 30 October 2026 while keeping the 1 January 2027 go-live. The same decision allowed voluntary implementation from 1 July 2026 and set up a pilot programme from that date.
Two points matter for planning your e-invoicing integration in the UAE. First, Decision 244 states that business-to-consumer transactions are not subject to the system, and a person engaged exclusively in them is out of scope, until the Minister decides otherwise. Second, “revenue” is defined as gross income in the most recent accounting period. Which phase you fall into is a question for your accountant, not for us, but once you know it, count backwards: an ASP contract, sandbox access, a mapping phase and a test phase all need to fit before your date.
- Revenue of AED 50 million or more: ASP by 30 October 2026, live by 1 January 2027.
- Revenue below AED 50 million: ASP by 31 March 2027, live by 1 July 2027.
- Government entities: ASP by 31 March 2027, live by 1 October 2027.
Dates can change by later decision, so check the Ministry of Finance portal before you lock your plan. We re-check it at the start of every engagement.
How does the UAE five-corner e-invoicing model work?
The UAE uses a decentralised model on the OpenPeppol network with five parties: the supplier, the supplier's ASP, the buyer's ASP, the buyer, and the Federal Tax Authority. The Ministry calls it the Decentralised Continuous Transaction Control and Exchange model, or DCTCE.
In practice: your system (corner 1) produces the invoice data and passes it to your ASP (corner 2). Your ASP validates it, converts it to the UAE standard, and sends it across Peppol to the buyer's ASP (corner 3), who delivers it to the buyer (corner 4). In parallel, the ASP reports tax data to the FTA (corner 5). The Ministry notes this reporting is intended to support pre-population of VAT return fields.
For UAE e-invoicing integration, the important part is the boundary between corners 1 and 2. Everything to the left of that line is yours to get right: the data, the timing, the numbering and the record of what was sent. Everything to the right belongs to the ASP. A good integration keeps that boundary clean, so you can change ASP later without rewriting your invoicing, and so each rejection can be traced back to a specific field in a specific invoice.
What data does PINT AE require on each invoice?
PINT AE is the UAE's customisation of the Peppol International invoice specification, and it defines the data every e-invoice must carry. The Ministry's mandatory fields document (version 1.0, 23 February 2026) lists 51 fields for an electronic tax invoice, grouped into invoice details, seller, buyer, totals, tax breakdown and invoice lines.
Several of these fields will not exist in a typical store or small ERP. The invoice transaction type code is a string of eight flags covering free trade zone, deemed supply, margin scheme, summary invoice, continuous supply, disclosed agent billing, supply through e-commerce and exports. The seller legal registration identifier type must say whether the identifier is a trade licence (TL), Emirates ID (EID), passport (PAS) or Cabinet Decision (CD). Invoice lines need a unit of measure code, item tax category and rate, and the VAT and line amounts expressed in AED even when the invoice currency differs.
Identity also changes. The document explains that your Peppol participant identifier is based on your Tax Identification Number, the first 10 digits of your 15-digit TRN, and that for UAE-registered sellers the electronic identifier scheme is the fixed value 0235. Buyers need the same kind of details. Collecting these reliably at the point of sale is usually the largest single piece of work in e-invoicing integration for the UAE.
How to choose an ASP with integration in mind
For e-invoicing integration in the UAE, choose an ASP from the Ministry's list of accredited service providers, then compare them on how easily your systems can talk to them. Accreditation covers the exchange; it does not tell you whether the API suits your software.
The Ministry's accreditation service page sets out what ASPs must show, including active Peppol certification with conformance testing, at least two years of experience operating an e-invoicing system, and ISO/IEC 27001 and ISO 22301 certificates. That is reassuring on security and continuity. What you still need to find out is practical:
- Which input formats does the ASP accept: PINT AE XML only, or also JSON, CSV or its own schema?
- Is there a sandbox with realistic validation, and how quickly is access granted?
- Does it offer a ready connector for your ERP or store platform, and who maintains it?
- How are rejections returned: synchronous response, webhook, or polling?
- Can it deliver inbound supplier invoices to you by API as well as portal?
- How is pricing structured, and what happens to your data if you switch provider?
We are happy to join the technical calls with shortlisted ASPs and ask these questions for you. The commercial decision and the contract remain yours.
What a developer can and cannot do for UAE e-invoicing
In UAE e-invoicing integration, a developer makes your systems produce, send and track correct invoice data; a developer does not exchange invoices over Peppol, report to the FTA, or decide how a transaction is taxed. Keeping that line clear protects you.
What we do
Audit invoice data, map fields to your ASP's format, add missing fields to forms and records, clean master data, build the API connector, handle rejections and retries, add credit-note flows, build monitoring, and document everything for your team.
What we do not do
We are not an Accredited Service Provider, not a tax agent, and not accountants. We do not advise whether a supply is zero-rated, exempt or out of scope, whether you are in the first or second phase, or how to file VAT returns.
Where the two meet
Tax categories and transaction flags are configured from a decision table your accountant approves. We implement the table exactly and show test invoices for each case so your accountant can confirm the output.
This split also shapes the contract. Our quote covers software work only, and ASP fees are paid to the ASP. See our terms for how scope and approvals work.
Four ways to connect a UAE business system to an ASP
There are four common patterns for e-invoicing integration in the UAE, and the right one depends on invoice volume and how many systems issue invoices.
1. Portal upload
Staff export invoices from your system and upload them to the ASP's portal. Workable for a few invoices a week; error-prone beyond that, and every upload is a manual step someone can forget.
2. Native ERP connector
Your ERP vendor or ASP provides a ready connector. Fastest when it exists and your data is clean; our role, if any, is data clean-up and testing.
3. Direct API connector
Your store or custom software calls the ASP's API when an invoice is finalised. This is the most common pattern for custom and niche systems, with connectors from US$600.
4. Middleware hub
A small service collects invoices from several systems, such as a store, a service billing app and an ERP, normalises them and sends them to one ASP. Useful for groups with multiple entities or invoicing sources.
Patterns 3 and 4 keep the ASP-specific code in one place. If you later change ASP, only that component changes, not your invoicing logic.
Cleaning master data before your e-invoicing go-live
Most e-invoicing rejections trace back to master data, not code: a TRN with a typo, an address with no city, an emirate typed five different ways, or a product with no unit of measure. Fix these before the first live invoice and you avoid a flood of rejections in week one.
We start by exporting customers, suppliers and products and running checks against the rules in the mandatory fields document: TRN length and format, presence of legal registration identifiers and their type, address line and city, country subdivision values, country code, unit of measure codes and tax category. Each failure goes into a review sheet grouped by problem, so your finance team fixes fifty similar records in one sitting rather than hunting individually.
Then we stop the problem coming back, because UAE e-invoicing integration is only as good as the data behind it. Customer forms get required fields with validation, emirate becomes a dropdown instead of free text, and product creation insists on a unit and tax category. Small changes, but they are what keep your e-invoicing integration clean after the project team has moved on.
E-invoicing integration for UAE online stores
If your store sells only to consumers, Decision 244 currently places those transactions outside the system; if it also sells to businesses, the B2B invoices need full e-invoicing data. Many UAE stores sit in between: trade accounts, bulk orders from companies, or corporate gifting.
For mixed stores, e-invoicing integration in the UAE means separating the flows. Business customers get an account type that captures legal name, TRN, trade licence number and a structured address, and B2B orders generate invoices through the connector while consumer orders continue as before. The transaction type flag for supply through e-commerce is set according to your accountant's decision table rather than hard-coded.
Store platforms differ in how much of this they can hold natively. WooCommerce allows custom checkout and account fields plus a connector plugin or service; hosted platforms usually need an app or an external service reading orders by API. Our guides to WooCommerce development in Dubai and payment gateway integration in the UAE cover the checkout side of the same store.
Custom and legacy software: invoicing rules that must exist first
Before custom software is ready for e-invoicing integration in the UAE, its invoicing has to behave like invoicing: sequential numbers that never repeat, issued invoices that cannot be edited, corrections made by credit note, and a record of who did what. Many in-house tools built for quotations or job tracking do not meet that bar yet.
We check four things. Numbering must be unique per issuing entity and never reused, even after deletion. Once issued, an invoice must be locked; changes happen through a linked credit note carrying its own number and a reference to the original. Every invoice needs a stored copy of the exact data sent to the ASP and the response received. And totals must be computed consistently, with rounding rules that match what the ASP validates.
If these are missing, we add them as a module inside your software, from US$900, before building the connector. For firms weighing a wider rebuild of inventory and billing, ERP software development in Dubai covers that decision.
Receiving supplier e-invoices into your accounts
E-invoicing runs both ways: once your suppliers are live, their invoices arrive through your ASP as structured data. Inbound UAE e-invoicing integration turns those into purchase records automatically instead of printing them for data entry.
Your ASP delivers inbound invoices by portal, API or webhook. We build a receiver that stores the original data, matches the supplier by TIN, tries to match lines to purchase orders or goods received, and routes exceptions to a named person for approval. Matched invoices flow into your accounting system; unmatched ones wait in a queue with the reason shown.
This is where the mandate can save time rather than only cost it. Invoice data arrives already structured, so there is nothing to type. For larger volumes, an AI automation step can suggest matches for irregular lines, with a person approving before posting.
Testing an e-invoicing integration before your deadline
Test any e-invoicing integration in the UAE in your ASP's sandbox using real invoice patterns from your own history, including the awkward ones. A connector that passes ten clean invoices and fails on the first credit note is not ready.
We build a test set from the past year: standard invoices, zero-rated and exempt lines if you have them, multi-currency invoices, credit notes, free-zone customers, very long item descriptions, and customers with incomplete data. Each goes through the sandbox, and each response is compared with what we expected. Your accountant reviews a sample of rendered outputs for tax categories and flags.
Failure handling gets tested deliberately: the ASP timing out, returning an error, or accepting an invoice twice. The connector must retry without creating duplicates, keep a queue that survives a server restart, and show staff clearly which invoices need attention. Only after that do we plan the live switch-over, usually starting with one invoice series before moving everything.
What does e-invoicing integration in the UAE cost?
With us, a connector from an existing system to your ASP starts from US$600, and a full invoicing module for software that lacks one starts from US$900. ASP fees are separate and paid to the ASP.
The biggest cost drivers are the number of invoicing sources, the state of your master data, and the quality of the ASP's API documentation and sandbox. One store sending B2B invoices with clean customer records is a small project. Three entities, a legacy billing tool with editable invoices, and ten thousand customer records with free-text addresses is a larger one, mainly because of clean-up and the invoicing fixes that must come first. Credit notes, self-billing and inbound invoice processing each add scope.
Quotes for UAE e-invoicing integration vary widely across the market, often because some include ASP subscriptions or ERP licences and some do not. Ask for the software work to be itemised separately from any third-party fees so you can compare. For wider technology budgeting, see website development cost in Dubai.
Working with a remote development team in India on UAE e-invoicing
India is 1.5 hours ahead of UAE time, so an e-invoicing integration project run from India shares almost all of your working day. Calls with your finance team and your ASP's technical contact can happen in normal UAE office hours without anyone staying late.
We work through access you grant: a read-only database copy or export for the audit, a staging copy of your system for development, and sandbox credentials issued by your ASP to your business, never to us personally. Production credentials stay in your secrets store, and at the end of the project you revoke our access. Confidentiality terms are agreed in the written quote before you share financial data.
Invoices for our work are in USD and issued from India; you pay by Wise or bank wire, and nothing is billed before written approval of the quote. We do not advise on how imported services are treated for your VAT; your accountant handles that.
First two weeks
Week one: kick-off with finance and IT, access set up, invoice data exported, ASP shortlist or contract confirmed. Week two: readiness audit delivered with a field-by-field gap report, master data review sheets, and a build plan with dates that land before your deadline.
Worked example: a hypothetical Dubai distributor preparing for 1 July 2027
Say a Dubai-based distributor of catering equipment, with revenue under AED 50 million, invoices hotels and restaurants from a custom order system and also runs a small online store for trade buyers. This is an illustration, not a client case.
The accountant confirms the phase: ASP appointed by 31 March 2027, live by 1 July 2027. In January the readiness audit finds that the order system allows editing invoices after issue, stores emirate as free text, and has no unit of measure on about a third of products. The store captures company name but not TRN.
The UAE e-invoicing integration plan runs in three blocks. February: invoice locking, credit notes and numbering added to the order system, and the store's trade accounts gain TRN and licence fields. March: master data clean-up with the finance team, ASP contract signed, sandbox access received. April to May: connector built, test set of sixty historic invoice patterns run through the sandbox, accountant signs off tax mapping. June: live on one invoice series, then all. The distributor goes live ahead of the deadline with time to spare for fixes.
UAE e-invoicing integration checklist
Work through this e-invoicing integration checklist for the UAE with your finance lead and your ASP. Items marked for the accountant are decisions we implement, not decisions we make.
- Accountant confirms which phase applies and your deadlines.
- ASP chosen from the Ministry list and contract signed in your business's name.
- Every system that issues invoices identified, including side tools and spreadsheets.
- Gap report of the 51 mandatory fields against each system completed.
- Invoice numbering unique and permanent; issued invoices locked; credit notes linked.
- Customer and product master data cleaned, with validation to keep it clean.
- Tax category and transaction-flag decision table approved by your accountant.
- Connector tested in the ASP sandbox with real historic invoice patterns.
- Rejection queue, alerts and a named owner in finance in place.
- Inbound supplier invoices routed to approval or accounts payable.
Red flags when hiring help for e-invoicing integration
When hiring for e-invoicing integration in the UAE, be cautious of anyone who claims to “make you compliant” end to end without mentioning your ASP or your accountant. Compliance under the UAE system depends on an accredited provider, correct tax decisions and correct data, and no single developer controls all three.
- A developer describing themselves as an ASP without appearing on the Ministry's list.
- Credentials for your ASP account issued in the developer's name instead of yours.
- No plan for credit notes, rejections or retries.
- Tax categories hard-coded without a documented decision from your accountant.
- No sandbox testing phase in the timeline.
- A quote that bundles ASP fees and development so you cannot compare either.