Overview
The United Arab Emirates is moving e-invoicing onto a Peppol-based five-corner model, in which accredited service providers sit between trading partners and the Federal Tax Authority. Nama ERP sends electronic invoices to the FTA through Orchida osTax, an Accredited Service Provider (ASP) in that model.
The system sends each invoice to Orchida, which validates it, reports the tax data to the Federal Tax Authority, and routes the document to the buyer over the Peppol network. From your side it is one action inside the ERP; the network mechanics are handled downstream.
Features
Submission and status tracking
Invoices are collected into a Tax Authority Submission Document and sent in a single step. Each line is then marked Sent when Orchida accepts it for processing, or Not Valid Sent with the rejection details attached.
Because clearance through the network is not instantaneous, the system can re-query
Orchida for the final outcome and update each line automatically with the authority
status — valid, invalid, or still pending.
Tax categories aligned to the standard
Tax codes follow the UN/EDIFACT 5305 aligned tax category codes, covering the standard 5% rate, zero-rated, exempt, out-of-scope and reverse-charge treatments — so the tax position on each line is expressed in the vocabulary the network expects rather than in a local approximation of it.
The reference data the network requires
Peppol is strict about identifiers, and Nama ERP holds the required fields against the records they belong to rather than in a side spreadsheet:
- Customers carry their Tax Registration Number, Peppol endpoint ID, agency details, and a structured address including the emirate.
- Units of measure carry their UN/ECE Recommendation 20 codes.
- Currency is configured with its authority code.
Because this data lives on the customer and item records, it is entered once and reused on every invoice, instead of being re-keyed per submission.
Supported documents
Invoices and credit notes are supported. Debit notes are not currently supported on the UAE integration. The window allowed for sending an invoice after its value date defaults to 14 days and is configurable.
Availability
The UAE integration is available and documented, and both staging and production taxpayer configurations are supported so you can validate against the sandbox before going live. This is a newer integration than our Saudi and Egyptian ones and its documentation is still being extended — if you are planning a UAE rollout, talk to us about the specifics of your scenario and we will tell you plainly what is covered today.
Setup requires an account on the Orchida osTax platform, from which you obtain the API key and company ID used to connect. The configuration procedure is published in our documentation.
Good question — already answered
Why is a service provider involved at all? In Saudi Arabia we submit directly.
Because the two countries chose different architectures. Saudi Arabia runs a clearance model where the invoice goes to the Authority. The UAE runs a Peppol-based five-corner model, in which accredited service providers sit between trading partners: your provider validates the invoice, reports the tax data to the Federal Tax Authority, and delivers the document to the buyer over the network. Nama ERP connects through Orchida osTax.
Which documents are supported?
Invoices and credit notes. Debit notes are not currently supported on the UAE integration, unlike the Saudi one — worth knowing before a rollout if your business relies on them, and worth raising with us so we can tell you where it stands.
Do we get an immediate answer on whether an invoice was accepted?
Not always, and the system is built for that. An invoice is marked sent once Orchida accepts it for processing; because clearance across the network is not instantaneous, Nama re-queries for the final outcome and updates each line with the authority status — valid, invalid, or still pending — rather than assuming acceptance.
What do we need to hold against each customer?
Peppol is strict about identifiers: a customer needs their tax registration number, their Peppol endpoint ID, the agency details, and a structured address including the emirate. Units of measure need their UN/ECE Recommendation 20 codes. All of it lives on the customer and item records, so it is entered once rather than assembled per submission — which is the difference between a clean rollout and a slow one.
Can we validate against a sandbox first?
Yes. Both staging and production taxpayer configurations are supported, so a UAE rollout is tested end to end before anything reaches the Federal Tax Authority. This is a newer integration than our Saudi and Egyptian ones, so if you are planning a UAE deployment, talk to us about your specific scenarios and we will tell you plainly what is covered today.
