A UAE case study: how a PINT-AE invoice moves from C2 to C3 and Corner 5
Most conversations about Peppol e-invoicing in the UAE focus on the visible steps: extracting data from the ERP, mapping required fields, applying business rules and generating a compliant PINT-AE XML invoice. Creating the XML, though, is only the beginning.
Before the invoice reaches the buyer, the sending Accredited Service Provider (ASP) still has to work out several things:
- where the invoice should go
- whether the recipient can receive it
- how to package it
- how to authenticate the receiving Access Point
- how to secure the transmission
- how the outcome is reported back
This guide follows a Peppol e-invoice step by step through the UAE 5-corner model. It covers dynamic discovery (SML and SMP), the SBDH envelope, AS4 messaging, PKI security, Message Level Status (MLS) and the parallel Tax Data Document (TDD) reporting path to the Ministry of Finance.
New to the mandate? Start with our UAE e-invoicing overview for deadlines, scope and ASP requirements.
How Peppol works in the UAE: the 5-corner model
In the UAE, the ASP handles more than the commercial exchange of an invoice. The architecture supports two related flows:
- Commercial exchange: the e-invoice moves between seller and buyer through their service providers.
- Regulatory reporting: tax data moves in parallel through the UAE e-invoicing framework.
Under the Ministry of Finance model, the seller's ASP at Corner 2 (C2) validates the e-invoice and transmits it to the buyer's ASP at Corner 3 (C3). At the same time, C2 reports a Tax Data Document (TDD) to Corner 5 (C5). C3 then runs its own validation and sends a Message Level Status (MLS) back to C2. After successful validation, C3 also reports the relevant TDD through the regulatory path.
A lot happens between "XML generated" and "invoice delivered."
Step 1: The XML is the payload, not the network
Assume C2 has already created and validated a compliant PINT-AE invoice. The business document is ready, but C2 still doesn't know how to deliver it. Before transmission, the sending ASP must answer these questions:
- Where is the buyer registered?
- Which service provider receives invoices for that buyer?
- Does that receiver support this document type and business process?
- Which network endpoint should the invoice go to?
- Which certificate should be used to secure the message?
This is the job of Peppol's discovery infrastructure.
Step 2: Dynamic discovery with SML and SMP
A sending Access Point doesn't need a static directory of every other Access Point, and it doesn't need a separate point-to-point connection with each trading partner. Peppol uses dynamic discovery to work out where a document should go and whether the recipient can receive it.
SML: locate the participant's metadata
C2 uses the buyer's Peppol Participant Identifier to query the Service Metadata Locator (SML). The SML does not hold the buyer's receiving capabilities. It points C2 to the right Service Metadata Publisher (SMP).
SMP: confirm how the participant can receive
C2 then queries the SMP for the buyer's published capabilities. The SMP confirms whether the participant supports the document type and business process. It also supplies the receiving Access Point's endpoint and certificate information.
Discovery answers a chain of questions in order:
Who is the recipient? → Where is their metadata? → Can they receive this document and process? → Where should it be sent? → How can the receiving Access Point be addressed securely?
C2 starts with "I have an invoice addressed to this Peppol participant." It ends with "This participant supports this document, through this Access Point, at this endpoint, with this certificate."
Peppol routing is therefore based on participant identity and published capabilities, not on knowing another provider's URL. This is what lets an Access Point exchange documents across the whole network without building a custom integration with every other provider.
[Image alt text: "Peppol dynamic discovery flow from the sending Access Point through SML and SMP to the receiving Access Point"]
Step 3: Wrapping the invoice in the SBDH envelope
With the route resolved, C2 prepares the invoice for transmission. The PINT-AE invoice is not sent as a standalone XML file. It goes inside a Standard Business Document (SBD), which pairs a Standard Business Document Header (SBDH) with the invoice.
The SBDH carries the metadata needed while the message is in transit: sender, receiver, document type, business process and an identifier for the envelope itself.
PINT-AE describes the invoice. SBDH describes the business message carrying that invoice.
This separation lets the Peppol delivery infrastructure route the message without reading the invoice content.
A UAE-specific consistency check: the sender and receiver Participant Identifiers in the SBDH must match the relevant EndpointIDs in the PINT-AE document. The envelope and the invoice inside it cannot name different trading parties.
The SBDH also carries the InstanceIdentifier, a message-level ID used for traceability. A later Message Level Status can reference it, so the status can be matched to the transmission it relates to.
Step 4: Building the Peppol AS4 message
C2 now prepares the message for transport to C3 using AS4, the messaging protocol based on the OASIS ebMS 3.0 standard. Peppol Access Points use AS4 to exchange documents securely and reliably.
The transmission has four layers, from outermost to innermost:
HTTPS/TLS connection → AS4/ebMS messaging → WS-Security → payload (SBDH + PINT-AE)
AS4 is not the invoice format. PINT-AE remains the business document, and AS4 is the framework that transports it between Access Points.
Inside the AS4 message, the eb:Messaging structure carries:
- the message identifier
- the sending and receiving parties
- service, action and conversation information
- references to the payload
The SBDH and PINT-AE invoice travel as a MIME attachment.
The steps connect to each other. Data retrieved from the SMP feeds the AS4 message:
- The published process identifier and document type form the AS4 Service and Action.
- The SMP endpoint is the delivery address.
- The receiving Access Point's certificate is used for message security.
Step 5: Peppol security with PKI, digital signatures and encryption
A common misconception is that HTTPS alone secures the transaction. Peppol actually uses layered security:
- TLS protects the network connection between the two Access Points.
- WS-Security with Peppol PKI protects the AS4 message itself.
Signing and encryption do different jobs:
| Control | Question it answers |
|---|---|
| Digital signature | Who sent this, and has it been altered? |
| Encryption | Can anyone other than the intended receiver read it? |
The sending Access Point signs the message with its Peppol credentials. It encrypts the message using the receiving Access Point's certificate, which it obtained from the SMP. OpenPeppol's operational guidance confirms that the signing certificate identifies the sending Service Provider.
This creates a trust boundary. The receiving Access Point should do more than check that a signature is mathematically valid. It must also confirm that the certificate belongs to a trusted Peppol participant in the relevant trust framework.
Step 6: What happens when C3 receives the invoice
At the buyer's Access Point, processing passes through a series of gates:
- Transport and security. C3 processes the AS4 message, validates the security controls, decrypts the message and verifies the signature.
- Addressing. C3 checks that the message is addressed to a participant and service it supports.
- Business validation. C3 extracts and validates the SBDH, recovers the PINT-AE invoice, validates it against the document rules, and delivers it to the buyer.
AS4 delivery does not mean the invoice was accepted
An AS4 response only tells C2 about the transport exchange. It does not confirm that C3 validated the invoice, and it does not confirm that the invoice was posted in the buyer's ERP. These are separate events.
A mature e-invoicing platform should track each stage separately:
- business-document validation
- route discovery
- AS4 transmission
- AS4 acknowledgement
- receiving-side processing
- regulatory reporting
A single "Sent" status hides too much.
Step 7: Retries, duplicate detection and idempotency
Here is a common failure scenario:
- C2 sends an invoice.
- C3 receives it.
- The response back to C2 is lost because of a network interruption.
C2 now can't tell whether the invoice arrived. If it simply resends without controls, the buyer may receive the same document twice.
Production Access Points therefore need duplicate detection, transaction correlation and idempotent processing. Identifiers at the AS4, SBDH and business-document layers can be used to check whether a transmission has already taken effect. Peppol does not prescribe the storage mechanism or retry algorithm; those are implementation decisions. The underlying principle still holds:
A retry should never cause the same invoice to be processed twice.
Retry logic should also tell the difference between transient and deterministic failures:
- Transient failures, such as a temporary network interruption, may justify another attempt.
- Deterministic failures, such as an invalid document, an unsupported service or a trust failure, should not be retried indefinitely.
Step 8: Message Level Status (MLS) in the UAE
Even after AS4 transport succeeds, C2 still needs to know what happened when C3 processed the message. That is the role of Message Level Status (MLS). In the UAE, the Ministry of Finance requires C3 to send an MLS to C2 after validating the e-invoice.
MLS is not a simple API callback. It is a Peppol message in its own right. C3 becomes the sender: it builds the status message, routes it back to C2, and links it to the original transmission. The direction of the network temporarily reverses:
- C2 → C3: Invoice
- C3 → C2: MLS
Keeping transport acknowledgement separate from processing status matters a great deal in day-to-day operations.
Step 9: The UAE regulatory reporting path (C2 → C5)
While the commercial exchange is under way, C2 also creates a Tax Data Document (TDD) and reports it to Corner 5. This is a separate transaction from sending the invoice to C3.
- Commercial exchange: C2 → C3 → C4
- Regulatory reporting (in parallel): C2 → C5 → tax authority
Under the Ministry of Finance process, C2 reports its TDD in parallel with the commercial transmission. C3 reports a TDD after successful validation. If C3's validation fails, negative MLS reporting replaces the normal C3 TDD flow.
This is where the UAE model goes beyond electronic document exchange and becomes a continuous transaction controls (CTC) regime.
Why this matters when choosing a Peppol provider in the UAE
Generating the XML is not the e-invoicing network. Behind every compliant invoice is a delivery infrastructure responsible for:
- discovering the receiver and resolving its capabilities
- building the SBDH envelope and AS4 message
- establishing trust through PKI, and signing and encrypting the transmission
- handling transport responses and MLS outcomes
- preventing duplicate processing and managing retries
- reporting tax data through the parallel UAE pathway
Judging an e-invoicing platform only on whether it can produce a compliant XML file misses most of the engineering challenge. The better question is: what happens to that XML after it leaves the application layer?
If you're earlier in the journey, our guide on how to prepare for UAE e-invoicing covers process mapping, master data and building a realistic transition timeline.
Frequently asked questions
How does Peppol work in the UAE?
The UAE uses a Peppol-based 5-corner model. The seller's ASP (C2) sends the e-invoice to the buyer's ASP (C3) over the Peppol network. At the same time, tax data is reported to the tax authority side (C5) through a parallel regulatory path.
What is PINT-AE?
PINT-AE is the UAE specialisation of the Peppol International invoice format. It is the business document exchanged between Access Points in the UAE e-invoicing model.
What is the difference between SML and SMP in Peppol?
The SML tells a sending Access Point where a participant's metadata is published. The SMP holds that metadata: supported document types and processes, the receiving endpoint, and certificate details.
Does an AS4 acknowledgement mean the invoice was accepted?
No. AS4 confirms the transport exchange only. Business validation is confirmed separately through a Message Level Status (MLS) from the receiving ASP.
What is a Tax Data Document (TDD) in UAE e-invoicing?
A TDD is the tax data reported to Corner 5, the tax authority side. The seller's ASP reports it in parallel with the commercial invoice, and the buyer's ASP reports it after successful validation.
What is the UAE 5-corner model?
It extends Peppol's 4-corner exchange (supplier, supplier's ASP, buyer's ASP, buyer) with a fifth corner for regulatory reporting to the UAE tax authority.
