UAE E-Invoicing on 1 July 2027: Getting an In-House ERP Ready for Peppol

From 1 January 2027, UAE businesses with annual revenue of AED 50,000,000 or more must issue and receive their B2B and B2G invoices as structured XML, sent through an Accredited Service Provider over the Peppol network. Everyone below that threshold follows on 1 July 2027, and has to appoint a provider by 31 March 2027. Government entities go live on 1 October 2027.

From your go-live date, the tax invoice is the XML. The PDF your system emails today is still needed only alongside it, for customers who are not on the network yet.

If your invoices come out of Zoho, Tally, Wafeq or a similar packaged product, most of this is your vendor's job. All three are themselves on the Ministry of Finance list of accredited providers. Your work is choosing a provider, onboarding through EmaraTax and cleaning up customer data.

This article is for companies whose invoices come from a system they own: a home-grown ERP, an installation customised past the point of upgrades, an in-house billing engine. Nobody ships the connector for those. The UAE Electronic Invoicing Guidelines say as much: businesses must "complete any customisations to in-house systems and begin testing the transmission of invoice data".

The Dates

The phases are set by Ministerial Decision No. 244 of 2025, as amended:

The first row originally said 31 July 2026. Ministerial Decision No. 66 of 2026 moved it to 30 October 2026 and left the go-live date alone. The table in the guidelines still prints the old date, so read the two together.

Voluntary implementation has been open to everyone since 1 July 2026, which matters for the plan below.

What Is in Scope

E-invoicing applies to any person doing business in the UAE, regardless of VAT registration. A business that is not VAT-registered issues electronic commercial invoices rather than tax invoices, through the same network.

B2B, B2G, G2B and G2G transactions are in. Supplies to consumers are out until the Minister decides otherwise, and a business that only sells to consumers is not subject to the system at all for now. There are narrow exclusions for sovereign government activity, airline passenger tickets and VAT-exempt financial services.

If you run a VAT group, one concession matters: transactions between members of the same group get a 24-month grace period starting 1 January 2027. Each member still onboards separately under its own TIN, and invoices to outside parties are in scope from the normal date.

The Five-Corner Model, Seen From Your ERP

The UAE uses a five-corner model:

1. Corner 1: you, the supplier.
2. Corner 2: your Accredited Service Provider (ASP).
3. Corner 3: your buyer's ASP.
4. Corner 4: your buyer.
5. Corner 5: the Federal Tax Authority.

Your system talks to one party: your ASP. You send invoice data in a format you have agreed with them. The ASP validates it, converts it to the UAE XML if needed, delivers it to the buyer's ASP and, in parallel, reports the tax data to the FTA. The buyer's ASP validates what it received and reports it too. Confirmations flow back along the chain to you.

That reporting uses a separate Peppol document, the UAE Tax Data Document, which the Peppol specification describes as "used by both invoice issuer and invoice receiver to report an invoice". Your ASP builds it. You build the handling of what comes back: confirmation that the buyer's side accepted the invoice, confirmation that the FTA received the tax data, and failures for either.

The ASP handles transport, encryption, participant lookup and the UUID that uniquely identifies each invoice. You remain responsible for calculating every value on the invoice and for collecting your buyer's Peppol identifier. Your provider validates the invoice. It does not correct it.

You appoint exactly one ASP, for both sending and receiving.

What Your System Has to Produce

The format

The UAE uses Peppol PINT-AE: UBL XML, with a billing specification and a separate self-billing one (both at version 1.0.4 at the time of writing). There is no QR code. You cannot add fields of your own; anything industry-specific is agreed with your ASP.

The fields legacy systems usually lack

The Ministry publishes a list of mandatory fields: 51 for an electronic tax invoice. These are the ones that usually need work:

• Electronic addresses for both parties. Your endpoint is 0235 plus your 10-digit TIN, which is the first 10 digits of your TRN. Your buyer's follows the same pattern, which means a new field on every customer record and someone to collect the values. There are predefined endpoints for edge cases: 0235:9900000098 when the buyer is not yet on the system, 0235:9900000099 for an export buyer with no Peppol ID, 0235:9900000097 for deemed supplies.
• Seller legal registration. The registration number plus its type, from a fixed set: TL (trade licence), EID (Emirates ID), PAS (passport) or CD (Cabinet Decision). On a commercial invoice the buyer's registration is mandatory too.
• Structured addresses, including the country subdivision (the emirate), for seller and buyer.
• Payment terms as data. A payment due date and a payment means code on every invoice.
• Coded units and full price data on every line. A unit of measure code, gross price, net price and price base quantity. Units stored as free text ("pcs", "box of 12") need a mapping table.
• Tax category per line, plus a breakdown per category: standard rate, exempt, out of scope, reverse charge, zero rated or margin scheme. Domestic reverse charge invoices also carry a narrative and the type of goods.
• AED amounts, always. The VAT amount and the amount payable for each line, in AED, whatever the invoice currency. A foreign-currency invoice also needs the tax accounting currency and its total with VAT in AED, at the Central Bank rate.
• Transaction type flags. Eight positions, each 1 or 0: free zone, deemed supply, margin scheme, summary invoice, continuous supply, disclosed agent billing, e-commerce, exports. Several can be set on one invoice, and each one set brings its own requirements. A free zone customer, for example, also needs beneficiary details.

One rule deserves its own test case: rounding applies at the invoice total, to two decimals, not at line or tax category level. If your billing code rounds each line or each VAT rate, test it against real invoices before your provider does.

HSN commodity codes are optional for now, with a mandatory date still to be announced. If you sell goods, add them while the item master is open anyway.

Credit notes, advances and retentions

• An invoice with a negative total is not allowed. A credit has to be issued as an electronic credit note, and that includes a summary invoice that nets to a credit.
• One credit note may reference several earlier invoices, and may cover only part of one. Volume discounts go through credit notes with the matching reason code.
• There is no category for provisional invoices. Every provisional invoice is a full electronic invoice, adjusted later by a credit note or an additional invoice.
• Advance payments get a tax invoice when received. The final invoice covers only the remaining balance and references the advance invoice.
• Retentions can be handled by invoicing net of the retention, then issuing a separate invoice when the retained amount falls due.

Inbound, which everyone forgets

The same ASP receives your supplier invoices. From go-live, those arrive as XML and have to land in accounts payable. That is often the larger half of the work, because it touches purchase matching and approvals rather than a single document template.

Your large suppliers go live on 1 January 2027 and will ask for your identifier. Until you are live, they send to the predefined endpoint and give you a regular tax invoice as well, so nothing breaks on your side.

Working With an Accredited Service Provider

The Ministry's list showed 60 accredited providers on 2 October 2026. Onboarding is started by you, not the provider: your EmaraTax account admin opens the e-invoicing section, selects the provider and is passed to its portal. Sign the contract first, and check that your company details in EmaraTax are current.

For a custom system, the questions that decide the project are technical:

1. What does it accept? Its own API payload, a file exchange, or PINT-AE XML you generate yourself. Its own format is less work today; your own PINT-AE lets you change provider without rebuilding the mapping.
2. How do confirmations come back? Webhook, polling, file? Both kinds belong on the invoice record, with the UUID the ASP assigns.
3. What happens on a retry? Timeouts happen. Resending an invoice must not create a second one, so agree how duplicates are detected and keep your own transmission log as the record of what was sent.
4. Is there a sandbox where you can test rejections, not just the happy path?
5. How do inbound invoices reach you? And what happens while your side is down?
6. Will it archive for you? It can, by contract, but the retention obligation stays with you. Records may sit outside the UAE as long as they can be produced to the FTA complete and readable.

The guidelines list what testing should cover: sending invoice data to the ASP, delivery to the buyer, the exchange confirmation, receipt of a supplier's invoice, the ASP reporting to the FTA, and the reporting confirmation. Test the failure path of each, not only the success.

The Penalties

Cabinet Decision No. 106 of 2025 sets them:

• Failing to implement the system, including failing to appoint a provider on time: AED 5,000 per month or part of a month.
• Failing to issue and transmit an electronic invoice, or an electronic credit note: AED 100 each, capped at AED 5,000 per calendar month.
• Failing to notify the FTA of a system failure, or to tell your ASP about changes to your registered data: AED 1,000 per day.

None of these apply to invoices issued voluntarily before your mandatory date.

A Nine-Month Plan to 1 July 2027

As of early October 2026, a company below the threshold has nine months. That is enough for a custom system if the work starts now.

1. October to November 2026: gap analysis. Export a year of invoices and credit notes, classify them by category, scenario, tax category and currency, and write down where every mandatory field will come from.
2. November to December 2026: choose a provider. Shortlist on the technical questions above, sign, and get sandbox access. 31 March 2027 is the last date, not the target.
3. December 2026 to February 2027: build. Master data changes and the collection of customer identifiers, the mapping, validation before sending, confirmation handling, a failure queue someone owns, and inbound processing.
4. February to March 2027: onboard through EmaraTax, ending with your participant identifier. Finish well before 31 March.
5. April to May 2027: end-to-end testing with the provider: all six steps, failures and credit notes included.
6. May to June 2027: go live voluntarily. Penalties do not apply to voluntary invoices, so this is the cheapest place to find the last problems. Agree the sequencing with your provider.
7. 1 July 2027: mandatory. Keep the failure queue staffed through the first VAT return.

If you are in the large cohort and have not started, you have until 30 October 2026 to appoint a provider and under three months to go live. The same steps apply, compressed into weeks, and the provider's own input format is probably the faster route.

What Could Still Move

Dates have shifted once already, the guidelines are at version 1.1, and PINT-AE versions change, with providers bound to use the latest. Keep the mapping in one module, behind your own interface, so a specification update does not touch the invoicing code. HSN codes will become mandatory at some point, and B2C stays out only until a further decision.

None of that is a reason to wait. The decisions are in force and the penalty table is published.

Where to Get Help

We build the connection between the system that produces your invoices and the provider that sends them: the data mapping, master data changes, validation, confirmation and retry handling, and inbound processing into accounts payable. Our e-invoicing integration service describes how that work runs, and if the mandate lands in the middle of a system replacement, see ERP modernization.

If your invoices come from a system nobody sells a connector for, write to office@c9group.dev.