If your finance or IT team is standardising invoicing across UAE and Saudi entities, you have likely already discovered that “we are both on Peppol” does not mean “one build works for both.” PINT AE 1.0, the UAE national Peppol specification, looks similar to PINT SA on the surface but diverges in transmission model, mandatory fields, tax treatment, and archival rules. Getting these differences wrong leads to rejected invoices, delayed regulator reporting, and rework during rollout. This guide breaks down what PINT AE 1.0 actually requires, where it parts ways with the global Peppol baseline and with Saudi Arabia, and what those differences mean operationally.
PINT stands for Peppol International Invoice, a template developed by OpenPeppol to help national authorities publish interoperable invoice specifications on top of the global Peppol BIS Billing 3.0 model. PINT AE 1.0 is the UAE customisation of that template, jointly shaped by the Ministry of Finance and the Federal Tax Authority (FTA) to reflect local VAT rules, the UAE data dictionary, and the country’s decentralised Continuous Transaction Control and Exchange (DCTCE) model.
In practical terms, PINT AE defines the XML structure, mandatory and conditional fields, code lists, and business rules every invoice must follow before an Accredited Service Provider (ASP) will transmit it across the Peppol network. It is built on UBL 2.1, uses standard Peppol identifiers, and applies UAE specific extensions for VAT categories, reverse charge codes, and bilingual invoice presentation. A PDF, scanned copy, or spreadsheet export does not qualify. If the document is not structured to the PINT AE schema and validated by an ASP, the FTA does not recognise it as an e-invoice.
Global Peppol BIS Billing 3.0 was designed with European public procurement in mind. PINT AE keeps the underlying Peppol infrastructure (AS4 messaging, four corner routing, participant IDs) and layers on several UAE specific requirements that standard Peppol implementations do not handle out of the box.
These additions make PINT AE more than a formatting profile. It is a compliance layer, and treating it as “Peppol with a UAE label” is one of the most common early planning errors we see. Teams that lift a European reference implementation without adjusting for these UAE specifics tend to discover the problem during ASP validation testing, where invoices are rejected against the FTA customisation ID rather than the EU BIS one.
Saudi Arabia and the UAE both use PINT derived specifications, but the transmission models are structurally different, and that difference cascades into every part of a build.
Saudi Arabia’s ZATCA framework runs a centralised clearance model. B2B standard invoices must be cleared by the Fatoora platform before they reach the buyer, and B2C simplified invoices are reported within 24 hours. Businesses integrate directly with the Fatoora API. Each invoice carries a UUID, a cryptographic stamp, a signed XML hash, and a TLV encoded QR code. Arabic is mandatory across the invoice, and the standard VAT rate is 15 percent.
The UAE takes a fundamentally different route through the DCTCE five corner model. Invoices do not pass through the FTA for pre-approval. They move from the supplier’s ASP to the buyer’s ASP over the Peppol network, with the ASP submitting the TDD to the FTA in parallel. Direct business to authority integration is not permitted. Every in scope UAE entity must appoint an accredited ASP. Digital signatures are applied by the ASP, not by the business. QR codes are not mandatory. The launch scope covers e-invoicing B2B B2G UAE transactions only, with B2C to follow later under a separate mechanism.
The consequence for multi entity groups is significant. A system tuned for ZATCA clearance cannot be repurposed for UAE Peppol exchange by editing a few field mappings. The connection layer, signing responsibility, validation rules, and reporting flow all sit in different places. Forcing a single build across both jurisdictions without recognising these structural differences leads to failed submissions and duplicated remediation later.
For finance, compliance, and IT leaders, the practical takeaway is that PINT AE 1.0 shapes decisions well beyond the invoicing team. Your ERP configuration, master data quality (TRNs, legal names, addresses, item codes, tax categories), ASP shortlist, integration pattern, and multi entity operating model all need to be reviewed against the specification before a technical path is locked in.
Our advisory work with UAE finance teams focuses on exactly this gap. That means mapping current invoice output against the PINT AE data dictionary, identifying where ERP fields fall short of the schema, coordinating with shortlisted ASPs on validation and end to end testing, and building the internal procedures that keep the business audit ready once the mandate takes effect. For groups with Saudi, Omani, or Bahraini entities, we design the compliance architecture so each jurisdiction is served by the right model rather than a forced single build. In practice, that often means separating the invoice generation layer from the transmission layer so the same ERP can feed a ZATCA clearance flow for Riyadh and a PINT AE ASP flow for Dubai without duplicating master data or reconciliation effort.
PINT AE 1.0 is not a cosmetic version of global Peppol, and it is not interchangeable with PINT SA. It embeds UAE specific VAT logic, a decentralised five corner exchange model, mandatory ASP intermediation, bilingual presentation expectations, and a distinct regulator reporting flow. Recognising these differences early prevents rework later. If you are scoping a UAE rollout or reconciling it with existing GCC compliance builds, a specification led readiness review is the fastest way to turn regulatory complexity into a defensible implementation plan. Talk to our UAE e-invoicing advisory team to get started.
PINT AE 1.0 is the UAE national Peppol Invoice Specification, developed by the Ministry of Finance and the Federal Tax Authority as a customisation of the global PINT template. It defines the XML structure, mandatory fields, code lists, and business rules every UAE e-invoice must follow before an Accredited Service Provider transmits it across the Peppol network. It is built on the UBL 2.1 standard.
PINT AE is based on Peppol BIS Billing 3.0 but is not identical. It applies UAE specific VAT categories, the UAE 15 digit TRN format, AED currency for VAT fields, bilingual Arabic and English presentation expectations, and a seven year archival rule. It also requires a Tax Data Document to be transmitted to the FTA in near real time, which the standard Peppol implementation does not include.
Not by simply reconfiguring one system. Saudi Arabia runs a centralised ZATCA clearance model with direct authority integration, while the UAE uses a decentralised five corner Peppol exchange routed through Accredited Service Providers. Signing, validation, and reporting logic sit in different places. Most groups need a compliance architecture that applies ZATCA rules for Saudi entities and PINT AE rules for UAE entities, rather than one forced build serving both.
Not at launch. The UAE mandate begins with business to business and business to government transactions under the PINT AE framework. Business to consumer invoicing is deliberately excluded in the initial phase and is expected to be introduced later under a separate mechanism, closer to real time transaction reporting. Businesses should still plan their systems and master data with future B2C inclusion in mind.
No. Under the UAE five corner model, digital signatures are applied by the supplier’s Accredited Service Provider rather than by the business directly. Your responsibility is to produce a valid PINT AE XML invoice and hand it to your ASP through a supported integration. The ASP validates the document, signs it, submits the Tax Data Document to the FTA, and routes the invoice to the buyer’s ASP.
