Supplier
Owns source accuracy, tax treatment and party data. Sends invoice data to its appointed provider.
UAE architecture explainer · C1–C5
Five corners. Two enterprise sides. One governed transaction.
The UAE model separates business invoice exchange from tax-data reporting. Here is who acts, what moves and which evidence finance, tax and technology teams need to retain.
PINT AEStructured invoice content
Peppol exchangeProvider-to-provider delivery
TDD reportingTax data from both sides
MLS evidenceCorrelated processing status
The model at a glance
Exchange runs across. Reporting runs down.
The structured invoice moves from the supplier through provider infrastructure to the buyer. Tax Data Documents (TDDs) are reported to Corner 5, while Message Level Status (MLS) messages provide technical processing evidence. The paths are related, but they are not the same event.
Invoice exchangeTDD reportingMLS / confirmation
C1
Supplier
Creates invoice data and appoints a service provider.
→
C2
Supplier-side provider
Validates, converts where needed, sends and reports TDD.
→
C3
Buyer-side provider
Validates, delivers, returns status and reports on success.
→
C4
Buyer
Receives structured data into its agreed system.
C5
Tax authority / reporting corner
Receives required tax data and reporting status.
Conceptual architecture—not a live-service claim. Production operation depends on accredited providers, technical onboarding, certificates, authority access, testing and activation.
Corner by corner
Five roles, with clear control boundaries.
Corners describe roles in an exchange. They are not five software products, and C2 and C3 do not mean each business must procure two separate provider relationships.
Supplier-side provider
Validates and converts to UAE XML where needed, sends to C3, reports TDD and returns status.
Buyer-side provider
Validates, sends MLS, delivers to C4 and reports TDD on the successful path.
Buyer
Receives the document. Matching, commercial approval and payment remain buyer processes.
Reporting corner
Receives required tax data and status, distinct from business-document delivery.
Official sequence, translated
The UAE flow in ten operational steps.
This register preserves the public Ministry of Finance sequence in implementation language. Use the step numbers as a shared reference for process design, controls and test evidence.
C1 submits invoice data to C2
The supplier sends data in the mutually agreed source format.
C2 validates and converts
C2 checks the data and converts it to UAE standard invoice XML where necessary.
C2 transmits the XML to C3
The structured invoice moves across the provider network.
C2 reports TDD to C5 in parallel
Supplier-side tax reporting is not deferred until buyer delivery completes.
C3 validates and sends MLS to C2
The buyer-side provider communicates message-level processing status.
C3 delivers the invoice to C4
The buyer receives it in the format agreed with its provider.
C3 follows the success or failure branch
The validation outcome determines whether buyer-side tax reporting proceeds.
Successful validation
C3 reports its TDD to C5.
C3 reports its TDD to C5.
Failed validation
C3 sends a negative MLS to C2 and C5; no C3 TDD is sent on this path.
C3 sends a negative MLS to C2 and C5; no C3 TDD is sent on this path.
C5 returns reporting MLS to C2
After successful TDD reporting, C5 sends status to the supplier side.
C2 forwards both statuses to C1
The supplier receives the C3 exchange MLS and C5 reporting MLS.
C3 forwards C5 status to C4
The buyer receives relevant reporting status through its provider.
A common procurement question
One appointed provider relationship—not two separate ASP purchases.
C2 and C3 are transaction-side roles. A business may be the supplier on one invoice and the buyer on another. Its appointed provider relationship should support both outbound and inbound flows for that End User, subject to service scope and accreditation.
Two providers appear in a single exchange because two businesses may appoint different providers—not because each business must buy separate “sending” and “receiving” ASPs.
Your role changes with the transaction
When you sell
You are C1; your provider is C2.
You are C1; your provider is C2.
→
Your customer
Is C4 through its C3 provider.
Is C4 through its C3 provider.
When you buy
You are C4; your provider is C3.
You are C4; your provider is C3.
←
Your supplier
Is C1 through its C2 provider.
Is C1 through its C2 provider.
Operational design
Build one evidence chain across every hand-off.
Finance, tax and operations need to reconstruct what was issued, exchanged, reported, delivered and acknowledged—without reconciling disconnected portals.
ERP ID, company, tax registration, buyer identity, issue time and business state.
Validated Invoice, Credit Note or supported Self-Billing payload and ruleset version.
Sender, receiver, document type, transport IDs, timestamps and correlation keys.
Processing status, negative outcomes and delivery evidence tied to the transaction.
Reported tax data, response status and controlled resubmission history.
Buyer receipt, exception owner, reconciliation state and archive access.
Where Invocor fits
Prepared for the provider role, with the regulatory boundary stated plainly.
Invocor is being designed to support provider-side capabilities at C2 or C3, depending on whether the appointing End User is sending or receiving in a given transaction.
- Participant onboarding and identifier governance
- PINT AE validation and controlled transformation
- Peppol exchange and correlated message status
- TDD/TDS orchestration and reconciliation
- Exception operations, evidence and archive controls
Questions teams ask
Five-corner model FAQ
Do we need one ASP for sending and another for receiving?
No. C2 and C3 are roles. One appointed provider relationship should support an End User's sending and receiving obligations, subject to scope and regulatory status.
Does an MLS mean the buyer approved payment?
No. MLS is technical processing evidence. Buyer approval, matching, dispute and payment remain separate business processes.
What happens when C3 validation fails?
C3 sends a negative MLS to C2 and C5, and does not send the C3 TDD on that failed-validation path.
Can the ERP continue to produce a PDF?
A PDF can remain a human-readable representation, but it is not the structured exchange payload. C2 converts agreed source data to UAE standard XML where necessary.
Is C5 in the invoice delivery path?
No. C2-to-C3-to-C4 carries the business document; required tax data and status use the C5 reporting path.
Primary references
Built against the published model.
- UAE Ministry of Finance — Electronic Invoicing portal
- OpenPeppol — Message Level Status specification
- OpenPeppol — PINT AE documentation
This page is an implementation explainer, not legal or tax advice. Confirm final obligations against current official publications.
Turn the model into a rollout plan.
Map systems, entities, data, evidence and accreditation dependencies before build decisions harden.