UAE eInvoicing does not require every ERP to connect directly to the Federal Tax Authority (FTA). The official model is deliberately different: a business connects its invoicing systems to one UAE Accredited Service Provider (ASP) for both sending and receiving Electronic Invoices, while the ASP participates in the Peppol-based exchange and performs the required Tax Data reporting to Corner 5.
That distinction should shape the architecture from the beginning.
For an enterprise running SAP, Oracle, Microsoft Dynamics, a custom billing platform, or several systems at the same time, the core design question is not “How do I connect my ERP to the FTA?” It is:
How do I reliably extract the required invoice data, validate it, exchange it with my ASP, process confirmations, receive inbound invoices, and preserve an auditable record?
If you are new to the model, read The Dawn of E-Invoicing in the UAE first. For the underlying legal and scope baseline, refer to UAE eInvoicing Regulatory Baseline.
Quick answer
A practical enterprise architecture normally has five internal responsibilities:
The official external flow remains:
The Ministry’s current published process states that Corner 2 reports the Tax Data Document (TDD) to Corner 5 in parallel with invoice exchange. After successful validation, Corner 3 also reports the TDD to Corner 5. Corner 5 returns Message Level Status (MLS) confirmations to the relevant ASPs.
Official reference: UAE Ministry of Finance — eInvoicing
What the regulation actually requires from the ERP side
The Ministry does not prescribe that every business must expose a particular REST API, install a particular middleware product, or make the ERP itself generate final PINT-AE XML.
The official guidance is intentionally more flexible.
It states that:
- Corner 1 submits Electronic Invoice data to Corner 2 in a format agreed with the ASP.
- Corner 2 validates that data.
- If Corner 1 sent a different agreed format, Corner 2 converts it to the UAE standard Electronic Invoice XML.
- Corner 2 transmits the XML Electronic Invoice to Corner 3.
- Corner 3 delivers the invoice to Corner 4 in a format agreed between the Buyer and its ASP.
That creates an important architecture choice.
All three can be valid enterprise patterns. The right choice depends on the source-system landscape, the ASP contract, where data-governance rules should live, and how much regulatory transformation the organization wants to own.
A useful principle
Keep business meaning close to the source. Keep network-specific responsibilities close to the ASP.
For example:
- the ERP should know the invoice number, tax treatment, quantity, UoM, buyer, seller and commercial totals;
- the enterprise may derive the correct UAE transaction scenario before sending;
- the ASP performs its official validation, Peppol routing, UUID generation, secure transmission and TDD reporting responsibilities.
The exact boundary should be documented in the interface contract.
The ERP-neutral reference architecture
A scalable architecture can be understood as layers rather than products.
This architecture works whether the source is SAP, Oracle, Microsoft Dynamics or a custom application because the UAE requirement is about the quality and exchange of invoice data, not the brand of the ERP.
Architecture patterns for different ERP landscapes
The internal pattern should match the number and diversity of source systems.
Pattern 1 — Direct ERP-to-ASP
Best suited when one ERP is the dominant invoicing system and the ASP supports a clean interface contract.
Advantages
- fewer moving parts;
- clearer ownership;
- easier operational tracing;
- lower integration overhead.
Watch-outs
- regulatory mapping can become tightly coupled to one ERP;
- every ERP upgrade may affect the eInvoicing interface;
- inbound AP integration still needs to be designed;
- adding a second ERP can lead to duplicated logic.
Pattern 2 — Integration hub between ERP and ASP
Useful when the enterprise already has middleware or several transactional systems.
The hub can centralize:
- canonical invoice structure;
- code conversions;
- routing;
- retries;
- duplicate prevention;
- monitoring;
- status normalization;
- inbound/outbound orchestration.
This is an enterprise architecture recommendation, not a Ministry requirement.
Pattern 3 — Multi-ERP canonical invoice layer
Useful for groups with several ERP families, acquired businesses, legacy billing platforms or industry systems.
The canonical model should not become a home-grown replacement for PINT-AE. Its purpose is to normalize internal business data, while the final external Electronic Invoice still needs to comply with the current UAE specification.
Architecture helper: choose the internal pattern
The selector below is an implementation aid, not a legal rule.
Outbound architecture: Accounts Receivable and billing
The outbound flow starts in the source business system, not in the Peppol network.
The detailed data required in the source payload is covered in UAE eInvoicing Data Mapping: Mandatory, Optional Fields and XML Structure.
Inbound architecture is not optional
Many projects start with Accounts Receivable because issuing invoices gets most of the attention. The UAE model also requires a Person in scope to appoint one ASP for both sending and receiving Electronic Invoices.
That makes Accounts Payable part of the architecture from day one.
The official guidance allows Corner 3 and Corner 4 to agree the delivery format.
That means an enterprise can design inbound processing around its AP capabilities, but the design still needs to preserve the integrity of the received Electronic Invoice and the associated status/reporting evidence.
Inbound design questions
- Which system receives supplier invoice data?
- Is an invoice automation platform involved before ERP posting?
- How is the original Electronic Invoice retained?
- How are supplier identifiers and purchase-order references matched?
- How are duplicates prevented?
- How is a failed inbound validation surfaced to AP?
- How are Corner 5 reporting confirmations linked to the received document?
Do not wait until UAT to answer these questions.
Where should PINT-AE transformation happen?
There is no single mandatory answer for the C1-to-C2 interface.
The official rule is that Corner 2 converts the data into UAE-standard XML if it receives a different agreed format from Corner 1.
That creates three realistic ownership models:
| Transformation owner | What the enterprise sends | Benefits | Main consideration |
|---|---|---|---|
| ERP | PINT-AE XML | Compliance logic close to source document | ERP must track PINT-AE changes and validation rules |
| Integration layer | Canonical ERP data → PINT-AE | Central mapping across several systems | Middleware becomes compliance-sensitive |
| ASP | Agreed structured source format | ASP owns final PINT-AE transformation | Strong interface contract and mapping transparency are essential |
What should stay inside the enterprise?
Even if the ASP performs final XML transformation, the enterprise should still own the meaning of its data.
The ASP should not be expected to decide:
- whether the transaction is Free Zone or Continuous Supply;
- whether the buyer is the correct legal entity;
- which internal tax treatment should apply;
- whether a PO or contract reference belongs to a specific transaction;
- whether the ERP totals are commercially correct.
Those are business-data decisions.
The ASP can validate and transform them, but the organization remains responsible for the compliance obligation.
Do not hard-code one PINT-AE version forever
As of this article, OpenPeppol’s UAE documentation publishes PINT-AE Billing version 1.0.4, with a release date of 29 July 2026. The UAE Tax Data Document specification is also published as version 1.0.4.
Version changes can include:
- semantic model corrections;
- code-list changes;
- Schematron rule corrections;
- validation-message changes;
- new or corrected samples.
The architecture should therefore treat the specification as a versioned dependency.
Official reference: OpenPeppol — UAE electronic document specifications
Status architecture: one “Sent” flag is not enough
The official model has more than one confirmation path.
For an outbound invoice, the enterprise may need operational visibility across:
These labels are an implementation view, not a new official status vocabulary. The official message mechanism is MLS; the ERP status model should preserve the meaning of those confirmations without inventing a false single “accepted” state.
Why this matters
A document can be:
- created successfully in the ERP;
- accepted by the enterprise integration layer;
- sent to the ASP;
- validated by Corner 2;
- exchanged to Corner 3;
- reported to Corner 5;
- and still require separate operational handling depending on the confirmations received.
Design statuses around events and evidence, not only around whether an API call returned HTTP 200.
Security: what is explicitly assigned by the UAE guidance?
The UAE Guidelines assign secure transmission using encryption to the ASP.
They also state that suppliers and buyers are responsible for agreeing their business-specific data-security requirements with the ASP.
The Ministry’s ASP accreditation requirements go further and include evidence around:
- data encryption at rest and in transit;
- multi-factor authentication;
- regular security monitoring;
- ISO/IEC 27001;
- ISO 22301 business continuity;
- ongoing support and maintenance;
- technical environment design.
Official reference: Ministry of Finance — Accreditation of eInvoicing Service Providers
Enterprise security design should still cover
These are architecture controls. The exact mechanism should be agreed with the ASP and aligned with the organization’s security policies.
Archiving: where should the Electronic Invoice be stored?
The UAE guidance does not mandate that compliant storage must sit in a particular corner or system layer.
The Person remains legally responsible for retaining Electronic Invoices, Electronic Credit Notes and associated data. Storage can be delegated to an ASP contractually, but that does not transfer the legal obligation.
The Guidelines also clarify that compliant infrastructure may be located inside or outside the UAE, provided that:
- the required retention period is met;
- integrity and security are preserved;
- records can be made available to the FTA upon request;
- records can be reproduced completely and readably.
This creates several legitimate enterprise options:
| Storage pattern | Possible use | Key control |
|---|---|---|
| ERP / content repository | Keep the compliance record close to accounting | Ensure original structured document and statuses are preserved |
| Enterprise archive | Central retention across multiple ERPs | Maintain reliable document-to-accounting linkage |
| ASP storage service | Outsourced storage under contract | Person still owns the legal retention obligation |
| Hybrid | ERP reference + enterprise/ASP archive | Define authoritative copy and retrieval process |
The ASP also has a separate obligation to retain transactional logs and technical traceability, including end-to-end transaction identifiers, transmission statuses and routing information. Those technical logs are distinct from the business document retention obligation of the Person.
Reliability and failure handling
A production architecture needs to assume that systems can fail.
The official Guidelines explicitly address service disruptions and delayed invoices. ASPs must notify relevant stakeholders of disruptions and exchange/report pending Electronic Invoices after service resumes.
From an enterprise architecture perspective, that means the ERP-to-ASP interface should support:
- durable queueing or recoverable handoff;
- duplicate protection;
- correlation identifiers;
- controlled retry;
- replay after recovery;
- reconciliation of pending documents;
- visibility of delayed exchange/reporting;
- clear ownership of rejected or incomplete invoices.
What should be validated before the ASP call?
The ASP validates the Electronic Invoice, but an enterprise should catch avoidable defects earlier.
Master data
- Seller TIN/TRN and legal identity
- Buyer electronic address / participant data
- Seller and Buyer address completeness
- legal registration identifiers
- tax-category master data
Transaction data
- invoice number and date
- document type
- transaction scenario
- currency
- line quantities and UoM
- tax rate/category
- line and document totals
- required references
Arithmetic
- line extension totals
- allowances and charges
- tax subtotals
- tax-inclusive/exclusive totals
- amount due
- required AED amounts for applicable currency scenarios
Interface
- mandatory fields present
- controlled-code values valid
- payload version supported
- duplicate not already in process
- correlation/reference identifiers populated
The earlier a defect is detected, the cheaper it is to correct.
ERP categories: what changes and what does not
The compliance target is the same, but the integration strategy can differ.
| ERP landscape | Typical architecture consideration | What does not change |
|---|---|---|
| SAP enterprise landscape | Decide whether mapping sits in SAP, integration layer or ASP boundary | UAE scope, data requirements and ASP model |
| Oracle enterprise landscape | Align invoice extraction and AP/AR integration with the ASP contract | PINT-AE external compliance target |
| Microsoft Dynamics landscape | Decide whether one or several company instances feed the ASP directly or through a hub | One ASP for sending and receiving per Person in scope |
| Custom / industry billing | Build a governed structured invoice dataset before external transmission | Corner 2/C3/C5 official roles |
| Multi-ERP group | Normalize legal-entity and invoice data across systems | Each in-scope Person still needs correct participant identity and compliance |
This article deliberately does not claim a specific vendor connector is mandatory or officially endorsed. Vendor-specific implementation should be checked against the relevant product’s current official documentation and the selected ASP’s certified interface.
Testing should prove the entire chain, not only connectivity
The Ministry readiness checklist explicitly asks whether:
- ERP/accounting applications can generate the necessary data points;
- integrations with the ASP can send and receive invoice data;
- Electronic Invoice exchange and reporting have been tested;
- a governance model exists for resolving errors.
A useful end-to-end test matrix includes:
A successful API handshake is not an end-to-end eInvoicing test.
Architecture decisions to settle before build starts
Use the following checklist in the architecture workshop.
Source systems
- Which applications create outbound invoices?
- Which applications receive/post inbound invoices?
- Are there separate billing systems by business unit?
- Which system is authoritative for seller/buyer master data?
Mapping
- Does the ERP produce PINT-AE or an agreed ASP format?
- Where are code conversions maintained?
- Where is the eight-position transaction type code derived?
- Who owns PINT-AE version changes?
ASP interface
- What payload format is accepted from C1?
- What format will be delivered to C4?
- How are MLS confirmations returned?
- How are correlation IDs and retries handled?
- How are test and production environments separated?
Operations
- Which team monitors failed exchange?
- Which team owns business-data correction?
- How are pending TDD/reporting statuses reconciled?
- How are service disruptions escalated?
- How are delayed transactions replayed?
Security and retention
- How is enterprise-to-ASP authentication managed?
- Which data is encrypted and where?
- Where is the authoritative structured invoice stored?
- How is the statutory retention period applied?
- Can Finance/Tax retrieve a complete record without engineering support?
Common architecture mistakes
Designing a direct ERP-to-FTA interface
The official UAE flow goes through the appointed ASP. Corner 2 and Corner 3 report TDD to Corner 5; the enterprise does not bypass that operating model.
Wiring the ASP directly to the FTA Central Data Platform
Corner 2 and Corner 3 report to Corner 5. The Central Data Platform is internal to the FTA/Corner 5 environment and should not be represented as a direct ASP integration endpoint.
Building outbound only
The appointed ASP supports both sending and receiving Electronic Invoices. Accounts Payable must be part of the architecture.
Forcing PINT-AE generation into every source ERP
The official model allows Corner 1 to send an agreed format to Corner 2, which can perform the UAE XML conversion. Decide the transformation boundary deliberately.
Assuming the ASP can repair weak source data
The ASP can validate and transform; it cannot reliably determine the business meaning of incomplete master data, wrong tax logic or incorrect commercial totals.
Treating “Sent” as the final compliance status
Exchange and reporting confirmations are separate events. Preserve the official MLS meaning in the operational status model.
Hard-coding a PINT version
PINT-AE is versioned. Build controlled upgrade and regression-testing capability.
Treating storage delegation as transfer of legal responsibility
An ASP may store documents under contract, but the Person remains responsible for compliance with retention requirements.
Three actions for implementation teams
1. Agree the ERP-to-ASP contract before coding
Document the input format, mandatory data, PINT-AE ownership, validation boundary, inbound format, statuses, correlation IDs, retries, security, versioning and support model.
2. Design inbound and outbound together
Treat AR and AP as two sides of the same eInvoicing operating model. This avoids a late redesign when Corner 4 receiving requirements surface.
3. Keep the compliance layer observable
Make it possible to answer, for every Electronic Invoice: what the source document was, what was sent to the ASP, what validation occurred, whether it was exchanged, whether TDD reporting succeeded, what MLS was received, and where the retained record is stored.
Frequently asked questions
Does the ERP connect directly to the FTA for UAE eInvoicing?
No. The official model requires Electronic Invoice exchange through UAE Accredited Service Providers. Corner 2 and Corner 3 report the required TDD to Corner 5.
Does the ERP have to create PINT-AE XML itself?
Not necessarily. The official process permits Corner 1 to submit invoice data to Corner 2 in an agreed format. If that is not already UAE-standard XML, Corner 2 converts it to the required XML before exchange with Corner 3.
Is an API mandatory between ERP and ASP?
The Ministry guidance does not mandate one specific API style or middleware technology. The business and ASP agree how invoice data will be transmitted, and the integration must support the required exchange, reporting and operational controls.
Can a company use separate ASPs for Accounts Receivable and Accounts Payable?
The current Guidelines state that a Person within scope must appoint one ASP for both sending and receiving Electronic Invoices.
Who generates the UUID?
The UAE Guidelines assign generation of a UUID for each Electronic Invoice to the ASP.
Who is responsible for secure transmission?
The Guidelines assign secure transmission using encryption to the ASP. Suppliers and buyers are responsible for agreeing business-specific data-security requirements with the ASP.
Can the Electronic Invoice archive be outside the UAE?
The June 2026 Guidelines clarify that storage infrastructure may be inside or outside the UAE if the required integrity, security, retention, retrieval and FTA-accessibility conditions are met.
Is the FTA Central Data Platform directly accessible by the ERP or ASP?
The official architecture presents the Central Data Platform inside the Ministry/FTA Corner 5 environment. Corner 2 and Corner 3 report to Corner 5; the Central Data Platform should not be treated as a direct enterprise or ASP integration endpoint.
Official references
- UAE Ministry of Finance — eInvoicing
- UAE Electronic Invoicing Guidelines V1.1 — 01 June 2026
- UAE Ministry of Finance — Accredited Service Providers
- UAE Ministry of Finance — Accreditation of eInvoicing Service Providers
- OpenPeppol — United Arab Emirates electronic document specifications
- OpenPeppol — PINT-AE Billing
- OpenPeppol — UAE Tax Data Document
Disclaimer: this article is to provide you the general info for your business specific requirements, get the advise from your appointed legal advisor.
Continue your trail
You now have the E-Invoicing context.
Save this guide, continue to the next concept or return to the Knowledge Library with your context intact.
E-Invoicing
7 resources in this area.
Practical SAP notes, structured for review, reuse and long-term maintenance.