Frequently Asked Questions

UAE e-invoicing comes with a lot of vocabulary. Here is what the terms actually mean.

The parties and the network

FTA — the Federal Tax Authority of the United Arab Emirates, which receives the reported invoice data.

MoF — the UAE Ministry of Finance, which issues the Electronic Invoicing Guidelines and the Data Dictionary.

ASP — Accredited Service Provider. A party accredited by the UAE authorities to operate an access point and report invoices to the FTA. You appoint one; you cannot join the network directly.

Access point — the gateway through which electronic invoices enter and leave the network, operated by your service provider.

Peppol — the international network standard the UAE has adopted for exchanging electronic business documents.

DCTCE — Decentralised Continuous Transaction Control and Exchange, the five-corner model the UAE uses. Invoices flow from seller to seller's provider to buyer's provider to buyer, with a parallel report to the FTA.

Identifiers

TRN — Tax Registration Number, the 15-digit UAE VAT registration number.

Participant identifier — your address on the Peppol network. In the UAE it takes the form 0235:<TRN>, where 0235 identifies the UAE tax identification scheme.

Predefined receiver — a fixed participant identifier issued by the authorities for transactions with no reachable counterparty, so the invoice is reported to the FTA instead of delivered.

The format

PINT AE — the Peppol International Invoice model for the United Arab Emirates, the invoice specification the UAE has adopted. Declared on every document as urn:peppol:pint:billing-1@ae-1.

UBL 2.1 — Universal Business Language, the XML format that carries the invoice.

Business term — a named data element in the standard, identified as IBT-nnn for international terms or BTAE-nn for UAE-specific ones.

Business group — a container for related business terms, identified as IBG-nn.

Cardinality — how many times an element may appear. 1..1 means exactly once, 0..1 at most once, 1..n at least once, 0..n any number of times including none.

Schematron — the automated rule set applied to every document. A document that fails is rejected with a rule reference.

Tax concepts

Tax category code — the VAT classification of a supply: S standard-rated, Z zero-rated, E exempt, O out of scope, AE reverse charge.

Transaction type code — a UAE-specific code identifying the nature of the transaction, for example a domestic supply or an export.

Deemed supply — a supply treated as taxable although no consideration is received: gifts above the threshold, private use of business assets and similar.

Reverse charge — an arrangement where the buyer, not the seller, accounts for the VAT.

Official sources

The UAE Electronic Invoicing Guidelines are published by the Ministry of Finance, and the PINT AE specification by OpenPeppol. Both are versioned and revised by their issuing authorities, so always check the current release.

Work through this in order. The items near the top have lead times measured in weeks, not days.

1. Registration

• Accredited Service Provider appointed and contracted
• Company registered on the network, producing your participant ID (0235:<TRN>)
• Your mandatory start date under the UAE roll-out plan confirmed

2. Company profile

• Registered legal name, full street address, city, emirate and country — with no placeholder values, because these appear on the legal invoice
• 15-digit TRN
• Trade licence number, registration type, and the name of the issuing authority
• Bank account details for the account shown on invoices

3. Tax configuration

• Domestic standard rate set to 5%
• Zero-rated and exempt supplies on separate posting groups
• Every posting group combination mapped to its tax category (S, Z, E, O or AE)
• Reason code and wording for every exempt and out-of-scope category
• Mapping reviewed and signed off by your tax advisor

4. Customer master data

• Participant ID for every customer invoiced electronically
• TRN for every VAT-registered customer
• Trade licence number, registration type and issuing authority
• Street, city, emirate and country on every customer
• Each customer classified — domestic, export, free zone, consumer, or not yet on the network

Expect this to be a data-collection exercise. It is usually the longest task on the list, and the one that determines your go-live date.

5. Item and document master data

• International standard code (UN/ECE Rec 20) on every unit of measure in use
• A meaningful description on every item and G/L account used on sales lines
• Country of origin on exported items
• Unique, gapless invoice numbering that is never reset
• Credit reasons aligned to the approved UAE list
• Daily exchange rates if you invoice in foreign currency

6. People and operations

• Every user who posts sales documents holds the correct ERP licence
• A named person in finance owns the daily exception check
• Archive retention period agreed with your tax advisor
• End-to-end test completed and signed off before live cutover

7. Cutover

• Production credentials configured separately from test
• Go-live date agreed
• Treatment of pre-go-live invoices confirmed in writing — normally no retrospective transmission

InvoiceNet is the e-invoicing platform built by Citytech Software DMCC. Citytech is an Accredited Service Provider (ASP) approved by the UAE Ministry of Finance and certified on the Peppol network.

That combination matters, because UAE e-invoicing is two problems rather than one:

• The platform — producing invoices in the PINT AE format, validating them against the UAE rules, exchanging them over Peppol and reporting to the FTA.
• The implementation — connecting it to your ERP, cleaning up customer and item master data, mapping your VAT posting groups to the right tax categories, and getting you through pilot to go-live.

Most compliance projects run into trouble on the second, not the first. Citytech brings over a decade of ERP and integration delivery across the UAE and wider GCC, so both halves come from one team.

Who it is for

Businesses of any size that need to comply with the UAE e-invoicing mandate. It works standalone for companies that want to start quickly, or integrated with an existing ERP — Dynamics 365 Business Central and Finance & Operations, SAP, Oracle and others.

How you can engage us

You can take the platform on its own, the implementation on its own, or both together. Talk to us about which fits your situation.

You can request a demo or contact support via the Contact Sales or Support links in the footer. Our onboarding team provides guided demos and can arrange implementation assistance.

Connecting your ERP

Connectors are available for common ERPs. Raise a ticket with your ERP name and version and we will confirm the options for your setup. Where no connector exists, the REST API provides the same capability.

Generating an API key

API keys are managed in Settings → API Keys. Generate a separate key for each system that connects, so one can be revoked without disrupting the others.

The key is shown once, at creation. Store it in your organisation's secrets manager immediately — it cannot be retrieved later.

Using it safely

Every request carries the key. Never put it in a URL, a client-side script, a source-code repository, or a support ticket.

Keep environments separate

Sandbox and production use separate keys. Documents sent with a sandbox key are never reported to the FTA and do not count toward your plan. Never share one key between environments — it is the fastest route to accidentally reporting test data as real.

Rotation

Rotate keys on a schedule, and immediately if one may have been exposed. The safe order is: generate the new key, update the consuming system, confirm it works, then revoke the old one.

If a key is exposed

1. Revoke it immediately in Settings.
2. Generate a replacement and update the consuming system.
3. Review the audit log for activity you do not recognise.
4. Raise a ticket so we can help you check.

Yes, and the distinction matters.

InvoiceNet exchanges documents over the Peppol network using AS4, and produces invoices in PINT AE — the UAE's own Peppol invoice specification, declared on every document as urn:peppol:pint:billing-1@ae-1.

Why PINT AE and not just Peppol BIS

PINT AE builds on Peppol BIS Billing 3.0 but adds the UAE-specific data elements, code lists and business rules the FTA requires. A platform that produces generic BIS Billing 3.0 invoices is not UAE-compliant — the documents will fail validation on the UAE rules.

If you are comparing providers, this is worth asking about directly.

What we handle

• Transmission over the network as your Accredited Service Provider
• Automatic retries on transient failures
• Delivery and reporting status for every document
• FTA reporting as part of transmission
• Inbound documents from suppliers who are already live

Citytech Software DMCC is an Accredited Service Provider approved by the UAE Ministry of Finance and certified on the Peppol network, so you connect once and reach any participant.

You can integrate using our REST API or via one of our pre-built ERP connectors (SAP, Dynamics, Oracle). For most customers, we provide a step-by-step integration guide and a sandbox environment to test end-to-end. Contact our onboarding team for a tailored integration plan.

We offer subscription-based plans with tiered document allowances and optional add-ons (ERP connectors, priority support). Billing is monthly by default and invoices are available in your dashboard. Contact sales for annual pricing or volume discounts.

A UAE Tax Invoice must carry 51 mandatory data elements under PINT AE. A commercial invoice needs 49 — the difference is the buyer's TRN block. The full standard defines 228 elements; the rest are conditional or optional. If any mandatory element is missing or malformed, the document fails validation and cannot be exchanged.

Invoice details — 9 fields

Specification identifier, business process type, invoice number, unique identifier (UUID), issue date, invoice type code, transaction type code, currency code, payment due date and payment means type code. The invoice number must be unique and never reused.

Seller details — 11 fields

Name, electronic address and scheme, legal registration identifier, registration type, authority name, TRN, tax scheme code, address line 1, city and emirate. The emirate is mandatory, and where a trade licence is the legal registration, the issuing authority must be named too.

Buyer details — 9 fields

Name, electronic address and scheme, TRN, tax scheme code, address line 1, city, emirate and country code. The buyer TRN is mandatory on a tax invoice to a VAT-registered buyer. Incomplete buyer addresses are the most common cause of rejection.

Document totals — 5 fields

Sum of line net amounts, total excluding tax, total tax amount, total including tax and amount due for payment. Calculated automatically from the posted document.

VAT breakdown — 4 fields

Taxable amount, tax amount, category code and category rate. One block per distinct category and rate combination.

Invoice line — 11 fields per line

Line identifier, quantity, unit of measure code, line net amount, item net price, item gross price, price base quantity, item tax category code, item tax rate, item name and item description. The unit of measure must be the international standard code (UN/ECE Recommendation 20), not an internal abbreviation, and item name and description are separate required fields.

AED line amounts — 2 fields

Line amount including VAT, and line VAT amount. Required whenever line-level VAT information is present.

What this means for your setup

Most validation failures trace back to master data rather than the invoice. Before go-live, confirm that every customer has a participant ID, TRN, trade licence, authority name, full address and emirate; that every unit of measure carries its international standard code; and that every item has a meaningful description.

Every electronic invoice carries a type code saying what kind of document it is, and a receiver address saying where it goes. Both have to be right for the document to be delivered or reported.

Document types

• Tax Invoice (380) — from a posted sales invoice. The standard document for a VAT-registered buyer; carries all 51 mandatory fields.
• Commercial Invoice (380) — where no VAT applies. 49 mandatory fields; the buyer TRN block is omitted.
• Credit Note (381) — from a posted credit memo. Must reference the original invoice and carry a reason code from the approved UAE list.
• Debit Note (383) — increases a previously issued invoice. Must reference the original.
• Prepayment Invoice (386) — the prepaid amount is deducted on the final invoice.
• Self-Billed Tax Invoice (389) — the buyer issues on the supplier's behalf; party roles are reversed.

Standard scenarios

Domestic supply to a registered buyer. Address the document to the buyer's own participant ID (0235:<buyer TRN>). The buyer must be registered on the network.

Government buyer. Handled exactly like a domestic business buyer.

Consumer. Individuals have no participant ID. Use 0235:9900000098; no buyer TRN is carried.

The three predefined FTA receivers

Some transactions have no counterparty to route to. Three fixed addresses exist for these, and documents sent to them are reported to the FTA rather than delivered. The status that comes back is reported, not delivered — both are successful outcomes.

• 0235:9900000097 — Deemed supply. Supplies without consideration, gifts above the threshold, private use of business assets. The value never varies by supplier.
• 0235:9900000098 — Buyer not yet on the network. The buyer has no participant ID because they have not onboarded. A conventional invoice must still be issued to them alongside.
• 0235:9900000099 — Exports. Where the overseas buyer has no participant ID. Also needs a complete delivery address with a non-UAE destination country.

Note that 0235:9900000098 is defined by the buyer's onboarding status, not by VAT scope. A supply that is genuinely out of scope or exempt is expressed through the tax category code, not the receiver address.

Tax treatment

Five category codes apply: S standard-rated, Z zero-rated, E exempt, O out of scope, AE reverse charge. Exempt and zero-rated supplies must sit on different VAT posting groups in your ERP — both are 0%, so sharing a posting group makes them impossible to report separately.

Specialised scenarios

Free zone supplies, summary invoices, continuous supply, foreign-currency invoices, margin scheme, agent billing and e-commerce supplies each have additional requirements. Raise a ticket if any of these apply to your business and we will confirm the configuration with you.

Every document is checked automatically by the network before it is accepted. A document that fails is returned with the reason. Below are the rules that cause rejections most often, and what to do about each.

Rules confirmed in live UAE testing

Missing legal registration authority. When a trade licence is used as the legal registration identifier, the name of the issuing authority must also be stated — for both seller and buyer. Populate the authority name on your company profile and on each customer record.

Free-text credit note reason. A credit note must carry a reason code from the approved UAE list. Free text is rejected. Map your reason codes to the approved list.

Line pricing structure. Every line must carry a gross price alongside the net price, even where no discount applies. Handled automatically by the platform.

Incomplete export details. An export must carry a complete delivery address whose country is not the UAE, plus a matching transaction type code. Check the ship-to address is complete on the document.

Invalid VAT rate. The rate must be valid for the tax category used. A domestic standard-rated supply at anything other than 5% is rejected. Check your VAT posting setup.

Payment method inconsistency. A credit transfer payment method must be accompanied by a payee account. Handled automatically based on whether bank details are configured.

Structural requirements

• Mandatory completeness — all 51 mandatory elements present and correctly formatted.
• Invoice number uniqueness — unique to the seller, never reused.
• Totals consistency — line totals, VAT breakdown and document totals must reconcile exactly.
• Unit of measure validity — codes must come from the international standard list.
• Date and amount formats — prescribed formats and decimal precision.
• Exemption reasoning — exempt and out-of-scope categories must carry a reason code and wording.

Operational causes

Buyer not registered. A document addressed to a participant ID that is not registered will not be delivered. Check the buyer before sending; if they are not on the network yet, use the predefined receiver for buyers who have not onboarded.

Duplicate transmission. The same document cannot be sent twice. A retry is recognised and reconciled rather than re-sent, so retrying is always safe.

What to do when a document is rejected

1. Open the document and read the rejection reason in full — it names the rule that failed.
2. Correct the underlying data. In most cases this is master data, not the invoice.
3. Re-send. The platform will not create a duplicate.

If the reason is unclear, raise a ticket with the document number and the full rejection text.

Prevention

Rejection happens after the invoice has been posted, at which point it is already a legal document and a correction means a credit note. Use the pre-posting validation check to catch missing data before that point, and keep a named person in finance responsible for the daily exception list.

An electronic invoice cannot be edited or withdrawn once it has been transmitted. It has been delivered to the buyer and reported to the FTA. Corrections are made by issuing a credit note or a debit note.

Credit note (type 381)

Reduces or cancels a previously issued invoice. Two requirements matter:

• It must reference the original invoice. Set the applies-to document so the link is carried through to the electronic document.
• It must carry a reason code from the approved UAE list. Free text is rejected — the code has to come from the list.

Debit note (type 383)

Increases the amount of a previously issued invoice. It must also reference the original invoice.

Which one to use

• Invoice cancelled entirely — credit note for the full amount
• Price or quantity overstated — credit note for the difference
• Price or quantity understated — debit note for the difference
• Wrong customer — credit note in full, then a fresh invoice to the correct customer
• Wrong VAT treatment — credit note in full, then a fresh invoice with the correct treatment

Common mistakes

No reference to the original. The correction is not linked to what it corrects, and will be queried.

Free-text reason. Rejected. This one surprises finance teams, because writing a sentence explaining the credit is what they have always done. Use a code from the approved list.

Trying to edit and re-send the original. Not possible. The original has already been reported.

Yes. InvoiceNet is the e-invoicing platform of Citytech Software DMCC, an Accredited Service Provider (ASP) approved by the UAE Ministry of Finance and certified on the Peppol network.

In practice that means:

• Invoices are generated in PINT AE, the UAE's Peppol invoice specification, as structured UBL 2.1 XML carrying all 51 mandatory data elements.
• Every document is validated against the UAE business rules before submission, so errors are caught while the invoice can still be corrected.
• Exchange and FTA reporting happen together as part of transmission.

How the reporting actually works

The UAE operates a five-corner model. Your invoice travels from you, to your Accredited Service Provider, to your customer's Accredited Service Provider, and on to your customer — while the Federal Tax Authority receives the reported data in parallel as the fifth corner.

You never submit anything to the FTA yourself. There is no separate upload, portal or filing step for the invoice.

A note for anyone familiar with Saudi Arabia

The UAE model has no QR code, cryptographic stamp or invoice hash requirement. Those are ZATCA requirements under the Saudi clearance model and do not apply in the UAE. A system built for one regime does not automatically satisfy the other.

We track Ministry of Finance and FTA policy changes and update the platform as the specification is revised.

The UAE has adopted a 5-corner model, formally a Decentralised Continuous Transaction Control and Exchange (DCTCE) framework built on the Peppol network. Invoices are exchanged through Accredited Service Providers rather than being sent directly to the tax authority.

The five corners

• Corner 1 — Supplier. Creates and issues the electronic invoice from their own system.
• Corner 2 — Supplier's ASP. Validates the invoice, transmits it onward, and shares the required tax data with the FTA.
• Corner 3 — Buyer's ASP. Receives and verifies the invoice before passing it on.
• Corner 4 — Buyer. Receives the compliant invoice into their finance or ERP system.
• Corner 5 — FTA. Receives invoice data from the ASPs for compliance monitoring and reporting.

What this means in practice

You never submit anything to the FTA yourself. Reporting happens automatically as part of transmission — there is no separate upload, portal or filing step for the invoice.

You cannot join the network directly. Every business in scope must appoint an Accredited Service Provider, which is the party authorised to operate an access point and report on your behalf.

The electronic invoice is the legal record, not the PDF. The structured XML is what is exchanged and reported; a PDF is a human-readable courtesy copy.

How it differs from Saudi Arabia

Saudi Arabia's ZATCA framework uses a clearance model with cryptographic stamps, QR codes and invoice hashing. The UAE uses decentralised exchange with no stamping requirement. A system built for one does not automatically satisfy the other.

The decentralised approach gives secure exchange, better transparency and near real-time tax compliance without routing every invoice through a central government gateway.

Yes — if you are in scope, appointing one is mandatory. You cannot connect to the UAE e-invoicing network directly.

What an ASP is

An Accredited Service Provider is an organisation approved by the UAE Ministry of Finance to operate an access point on the Peppol network and report invoice data to the Federal Tax Authority on your behalf.

Citytech Software DMCC, the company behind InvoiceNet, is an MoF-approved ASP certified on the Peppol network.

What your ASP does for you

• Registers you on the network and issues your participant identifier, in the form 0235:<your TRN>
• Validates every invoice against the UAE business rules before it is sent
• Transmits invoices to your customers' service providers
• Reports the required data to the FTA
• Receives inbound invoices from your suppliers
• Maintains the archive that forms your legal record

How to appoint one

Appointment is made through EmaraTax, the FTA's portal. You nominate your chosen provider there; the provider then completes registration and issues your participant identifier.

The appointment deadline is 30 October 2026. Because implementation typically takes up to six months, this is the date that really governs your project timeline — not your phase go-live date.

Choosing between providers

You can change provider later, but it means re-registering your participant identifier, so it is worth choosing on more than price. Questions worth asking:

• Do they produce PINT AE, or only generic Peppol BIS?
• Do they integrate with your ERP, or only offer an API?
• Will they help with master-data clean-up, which is usually the longest task?
• Is support based in the UAE and in your timezone?

We can walk you through the EmaraTax appointment as part of onboarding.

Security is a core focus. We use TLS in transit, AES-256 encryption at rest for sensitive data, role-based access controls and regular security audits. Access logs and audit trails are available for compliance.

API documentation and sandbox keys are available under the Developer section of your dashboard. You can also request sandbox credentials from support to test integrations before going live.