UAE E-INCOICING · SAP & ORACLE
Multi-Entity & Multi-Currency eInvoicing in the UAE
Multi-entity and multi-currency eInvoicing are different problems. Each in-scope Person must appoint one ASP for sending and receiving eInvoices, while a corporate group may need to onboard several separate legal entities. Foreign-currency invoices are permitted, but the UAE PINT AE data model requires the correct invoice currency and UAE tax-currency information where applicable.
reading time: 14 min
SOURCES: MOF, FTA OFFICIAL PUBLICATIONS
october 2026
aiverix research
For a single UAE company using one accounting system, eInvoicing can look like a straightforward integration project. For a group with several legal entities, multiple ERPs and invoices in AED, USD, EUR, SAR or other currencies, the implementation becomes a governance problem as much as a technical one. The objective is not simply to "switch on" Peppol. The group must know which legal entity is issuing each invoice, which system owns the source data, which ASP relationship applies to that entity, and how currency and tax values are represented in the structured invoice.
Multi-entity and multi-currency are two separate design questions
Multi-entity eInvoicing concerns legal identity: which company is the seller or buyer, which registration and tax identifiers belong on the document, and which onboarding record connects that Person to the UAE eInvoicing network. Multi-currency eInvoicing concerns monetary representation: the document currency, the tax accounting currency and the AED-denominated tax values required by the UAE specification when the invoice is issued in a foreign currency.
Treating both as a single "international invoicing" feature is risky. A platform can support many currencies but still lack clean per-entity onboarding, access control or reconciliation. Conversely, a platform may support many UAE entities but handle foreign-currency tax fields poorly. Both capabilities need to be tested independently.
Treating both as a single "international invoicing" feature is risky. A platform can support many currencies but still lack clean per-entity onboarding, access control or reconciliation. Conversely, a platform may support many UAE entities but handle foreign-currency tax fields poorly. Both capabilities need to be tested independently.
One ASP per Person: what this means for a corporate group
The Ministry of Finance guidance states that a Person within the scope of Electronic Invoicing must appoint only one ASP for both sending and receiving electronic invoices. A group, however, can contain several separate Persons. In practice, the implementation should therefore be mapped at legal-entity level rather than only at brand or group level.
A UAE business cannot appoint one ASP for outgoing invoices and another ASP for incoming invoices. The same in-scope Person appoints one ASP for both directions. A corporate group may still have multiple legal entities that require separate onboarding and identifiers.
A UAE business cannot appoint one ASP for outgoing invoices and another ASP for incoming invoices. The same in-scope Person appoints one ASP for both directions. A corporate group may still have multiple legal entities that require separate onboarding and identifiers.
Build an entity matrix before you design the integration
For each UAE entity, record at least the following before implementation:
-
Point 1
Legal entity name and legal registration identifier. -
Point 2
Tax registration status and relevant tax identifiers. -
Point 3
Revenue band and applicable implementation phase. -
Point 4
Primary ERP, accounting or billing system that creates the invoice. -
Point 5
Accounts receivable and accounts payable owners. -
Point 6
Expected invoice volumes and peak periods. -
Point 7
Currencies used for customer and supplier transactions. -
Point 8
Special transaction patterns such as exports, free-zone transactions, continuous supplies or intra-group flows. -
Point 9
Target ASP onboarding status and internal owner for the relationship.
This matrix becomes the control layer for the programme. It also prevents a common implementation failure: building one technical connector and assuming every subsidiary can be treated identically even though identifiers, transaction types, tax profiles and go-live obligations differ.
How foreign-currency invoices work under PINT AE
The UAE mandatory-field model includes an invoice currency code, and the PINT AE specification supports a separate tax accounting currency. When the invoice currency is not AED and the tax accounting currency is AED, the structured invoice must carry the required AED tax values and related UAE-specific totals. The currency codes use ISO 4217 conventions.
UAE eInvoicing does not require every commercial invoice to be issued in AED. Foreign-currency invoices can be represented in PINT AE, but the tax information that must be reported in AED has to be populated correctly.
UAE eInvoicing does not require every commercial invoice to be issued in AED. Foreign-currency invoices can be represented in PINT AE, but the tax information that must be reported in AED has to be populated correctly.
What the platform should validate
-
The document currency is explicitly populated and matches the commercial invoice.
-
AED tax-accounting fields are generated when required by the PINT AE rules.
-
Exchange-rate inputs are controlled, traceable and consistent with the tax treatment used by the business.
-
Rounding rules do not create differences between ERP totals, structured invoice totals and accounting records.
-
Credit notes preserve the correct currency relationship to the original invoice.
-
The validation result is returned to finance in a form that can be reconciled to the source transaction.
Three common architecture patterns
What consolidated visibility should mean
Group-level visibility should not mean merging legally distinct entities into one undifferentiated dashboard. A useful control model allows finance teams to see the whole group while drilling down to the legal entity, invoice, source system, delivery status and FTA reporting status. Access should also be role-based so that local teams see the entities they manage while group finance can review consolidated exceptions and trends.
A practical implementation sequence
-
Step 1
Map every legal entity, source system and invoice flow before selecting the target architecture. -
Step 2
Determine the implementation phase and scope for each in-scope Person; do not use the group’s total revenue as a substitute for entity-level analysis without tax advice. -
Step 3
Choose the ASP and confirm how each legal entity will be onboarded and identified on the network. -
Step 4
Define a canonical invoice data model so different ERPs map consistently into PINT AE. -
Step 5
Test foreign-currency scenarios using real invoice patterns, not only AED test data. -
Step 6
Test credit notes, rejected invoices, corrected data and other exception flows. -
Step 7
Reconcile the source record, structured eInvoice, delivery status and tax-reporting status before go-live. -
Step 8
Set up group dashboards and entity-level ownership for ongoing monitoring and changes.
Where Aiverix fits before accreditation
Aiverix is preparing for UAE ASP accreditation. Its current product positioning focuses on a compliance layer that can connect to existing ERP and invoicing systems rather than forcing a finance-system replacement. For multi-entity content, the strongest positioning is therefore architectural: centralised visibility with per-entity configuration, multiple source-system connections and controlled PINT AE transformation. Until accreditation is granted, public copy must not describe Aiverix as an accredited ASP and should direct readers to the live Ministry of Finance register for current provider status.
Map Your Multi-Entity Rollout
Bring your legal-entity list, source systems, currencies and invoice volumes to Aiverix and use them to scope a practical rollout path.
FAQ: multi-entity and multi-currency UAE eInvoicing
For an in-scope Person, the Ministry of Finance guidance says one ASP must be appointed for both sending and receiving electronic invoices. A group may still contain several separate Persons, each with its own onboarding requirements.
Yes, a technology platform can provide group-level management for multiple entities, but each legal entity still needs the correct identifiers, onboarding and compliance configuration. The group dashboard should not erase entity-level accountability.
Yes. PINT AE supports an invoice currency code. When tax accounting is required in AED, the relevant AED tax values and totals must also be represented correctly in the structured invoice.
No. A group can use a shared ERP or several different systems. The eInvoicing design must reliably identify the legal entity and map each source transaction to the correct UAE eInvoicing configuration.
Test each legal entity, each major source system, each material currency and the exception flows that finance teams will actually encounter: rejected invoices, credit notes, corrections, unavailable counterparties and reconciliation differences.
No. UAE ASP accreditation is specific to the UAE framework. A provider may support several MENA markets, but its approval, technical rules and obligations must be assessed separately in each jurisdiction.