How to scope an RFP for UAE e-Invoicing: A CFO’s guide

Most UAE e-invoicing RFPs score vendors on the same three things, feature parity, MD No. 64 accreditation, and reference clients, and because every FTA-accredited ASP meets all three by definition, selection collapses onto commercials and the cheapest licence usually wins.

A year after go-live, the same problems keep appearing across the same projects: transmission runs from the statutory deadline but the D365 or SAP integration has slipped two quarters behind it, supplier onboarding is still being processed in batches months after the cutover date, and reporting comes out of Excel because the platform never had an operating UI to begin with.

Cybersecurity incidents on the ASP side surface as audit findings against the customer, and data-residency exposure shows up during the first internal audit when the ASP cannot evidence where transmission data is stored or who holds administrative access to it.

The pattern is consistent enough to point back to the document that should have prevented it: the RFP. The platform selected through that RFP fixes the compliance architecture, supplier experience, and AP operating model for the next five to fifteen years, and most UAE e-invoicing RFPs are still being drafted from generic procurement templates.

Those templates are never calibrated against the specifics of MD No. 243, MD No. 244, MD No. 64, Cabinet Decision No. 106, the UAE e-Invoicing Guidelines V1.0, the Tax Group structure, Free Zone scenarios, or PINT-AE field validation, and the gaps show up later as cost overruns and post-go-live remediation work.

The Ministry of Finance has published its own Considerations for Selecting an Accredited Service Provider (V1.0, February 2026), which covers ASP experience, integration, security, and pricing at a high level.

This guide extends that document with the operational and contractual detail UAE CFOs should put in the RFP itself, the criteria that separate platforms that pass procurement from platforms that work in production.

Five legal and technical instruments define the UAE e-invoicing mandate, every ASP shortlisting itself for your RFP will have read all of them, and compliance with the stack is therefore the baseline every shortlisted vendor meets, none of it functions as a point of differentiation between vendors.

Ministerial Decision No. 243/2025 sets the scope of the mandate, the appointment-of-ASP obligation, and the exclusion list (Government sovereign-capacity transactions, international passenger transport by Airlines, exempt or zero-rated financial services, and certain other categories).

Ministerial Decision No. 244/2025 sets the rollout phases: Enterprises with annual revenue at or above AED 50 million must appoint an ASP by 31 July 2026 and go live by 1 January 2027, enterprises below AED 50 million must appoint by 31 March 2027 and go live by 1 July 2027, and government entities go live by 1 October 2027.

Ministerial Decision No. 64/2025 governs ASP eligibility and accreditation, including PEPPOL certification, ISO 22301 (business continuity), ISO/IEC 27001 (information security), AED 2.5 million professional indemnity insurance, and a two-year accreditation validity with renewal.

Cabinet Decision No. 106/2025 sets the penalty schedule for non-compliance.

The UAE Electronic Invoicing Guidelines V1.0 (February 2026) is the technical companion document, and Section 10 in particular defines the six invoice categories and eight scenarios that ASPs must support.

If a vendor cannot evidence current MD No. 64 accreditation, they should not be in the shortlist at all. Once accreditation is verified, the rest of the RFP needs to test the things accreditation does not measure: security controls beyond the ISO 27001 certificate, operational fit against existing AP workflows, integration depth on your specific ERP release, and post-go-live support across multiple entities. Those are the criteria that determine whether the platform passes UAT or stalls in production.

Six recurring failure modes explain why platforms pass procurement and stall after go-live. They are the patterns visible across UAE engagements that have already gone through implementation, and generic RFP templates do not test for any of them.

Hosting, security, and data residency assumed from accreditation

The FTA does not mandate local data hosting and MD No. 64 does not impose enterprise-grade cybersecurity controls on accredited ASPs beyond the ISO/IEC 27001 baseline, which means two ASPs holding identical accreditation can have very different answers on where data lives, how it is backed up, what the disaster-recovery posture looks like, and which legal entity operates the underlying infrastructure.

The exposure surfaces in two ways post go-live: cybersecurity incidents on the ASP side trigger audit findings or breach disclosures that the customer has to manage, and data-residency questions come up during the first internal audit when the ASP cannot evidence where transmission data is stored or who holds administrative access to the environment.

The RFP needs to ask explicitly where data is hosted, which legal entity operates the infrastructure, what the SOC 2 or ISO 27001 posture covers in detail, and how MOF and FTA audit access is structured, because treating MOF accreditation as a substitute for an internal security assessment is the most common reason platforms with valid certificates fail post-implementation security reviews.

Compliance without operational fit

A platform can meet every MD No. 243 transmission requirement and still leave the AP team unable to process incoming invoices. Inbound invoices arrive through the network with no PO match, no contract reference, and no link to the supplier master record, and AP ends up reconciling by hand at month-end. The cause is straightforward: the ASP was tested on outbound compliance during procurement and never assessed against internal master data, purchase orders, contracts, or three-way matching rules.

Workflows that worked before, approval routing, exception handling, intercompany allocations, break the moment the inbound channel changes shape and the validation rules sit in a separate system.

The RFP has to require a documented impact analysis on existing AP workflows, approvals, and master-data validation as a contractual deliverable before signature, and the ASP should be able to produce sample SOP changes from a comparable UAE engagement when asked.

Back-end-only platforms with no operating UI

Most ASPs are back-end compliance pipes with no interface for the AP team, no dashboard for in-flight traffic, no audit logs visible to operations, and no flexibility for the different ways invoices are created and received in a real enterprise.

Non-mandated suppliers, international suppliers, and exempt categories then land outside the platform, AP ends up running two systems for the inbound channel that the mandate was supposed to consolidate, and as more suppliers come on board through the year the operational drag compounds while the team that was promised a unified inbound channel ends up managing parallel queues.

The RFP should require a single interface that handles mandated and non-mandated invoice flows in the same system, with dashboards, audit logs, and exception queues for AP, plus configurable validation rules for each invoice type so the operating team has one place to work.

Tax group complexity ignored

Each member of a UAE Tax Group carries its own TIN and its own PEPPOL Participant Identifier, formatted as 0235 followed by the 10-digit TIN. A Tax Group with multiple entities is therefore multiple separate onboarding workstreams: multiple Participant IDs, routing configurations, validation profiles, and UAT cycles before the group can transmit.

Intra-group transactions are also in scope from 1 January 2027, the UAE Electronic Invoicing Guidelines confirm that business transactions between members of the same VAT group fall within scope of electronic invoicing for at least 24 months from that date, which adds another layer of routing logic the platform has to handle.

RFPs that treat the group as a single integration miss this entirely, and the first sign of trouble is the implementation plan landing with one go-live date for the group instead of a sequenced plan per entity with defined fallback if any individual entity fails its UAT cycle. For groups spread across DIFC, Mainland, and ADGM, mapping UAE data compliance across multi-entity groups is a prerequisite to getting the RFP scope right.

TCO treated as a subscription fee

Most pricing schedules ask for the annual licence fee and stop there, which means implementation, per-entity onboarding after initial go-live, per-invoice volume charges, ERP integration build, regulatory-update charges, and exit fees never get compared across vendors on a like-for-like basis and the vendor with the cheapest licence often turns out to be the most expensive across a five-year hold.

The RFP must require each cost component priced separately with documented assumptions covering entity count, volume bands, ERP releases, and custom-field counts, because without those assumptions comparing two pricing schedules means comparing different quotes for different scopes.

No exit or portability clause

Data export format, migration support, exit fees, and the five-to-fifteen-year archive retention required under UAE tax law rarely appear in the RFP at all, which writes lock-in into the contract on terms the outgoing vendor will set in five years’ time.

The RFP should require a documented data export format covering both PINT-AE XML and PDF, defined exit-support hours included in the base contract, capped exit fees, and a documented migration-handoff procedure to a successor ASP.

The five-year archive obligation does not move with the platform, so the migration path needs to be defined in writing before signature, with the export format, exit-support hours, and capped fees all committed up front.

A live ASP rewires AP workflows, approvals, exception handling, and master-data validation across every entity it touches, and most RFP templates fold this category into a sub-question under integration or leave it out altogether.

Process impact is its own category of work and the RFP should treat it that way, with four specific areas documented before contract signature. Approval workflows have to handle invoices arriving via PINT-AE without a manual rekey step, and custom fields, project codes, and cost-centre logic all need to survive transmission and routing into the existing approval hierarchy.

Master-data validation has to run inbound invoices against the supplier master, PO records, and contract repository in near real time, because without it exception volumes spike at month-end and AP loses visibility into the backlog.

Exception handling needs documented routing paths, named escalation owners, and resolution SLAs covering both internal queues and the MOF or FTA escalation path when an invoice fails PINT-AE validation. Operating-procedure documentation has to be updated to reflect every change to the AP operating model, SOPs, training material, and audit-trail design all sit downstream of the platform decision.

The RFP should require the ASP to deliver a documented impact analysis covering all four areas before contract signature, supply sample SOP changes from a comparable UAE engagement, and name the change-management lead on the ASP side. Each of those three is a reasonable test of UAE delivery experience, and the RFP scoring should weight them accordingly.

ERP integration is where UAE e-invoicing timelines slip, and the question RFPs usually ask is too broad to expose which vendor has actually done the work. “Does your platform integrate with our ERP?” can be answered honestly by a generic API connector, by a middleware layer that needs three months of custom development, or by a native connector that ships out of the box, and the RFP scoring treats all three answers as a yes.

The question reveals nothing about the specific ERP release, the approval hierarchies, the custom fields, the intercompany flows, or who owns the integration build on either side.

The RFP should ask for five specific things in this section:

• Native connectors on the exact ERP release in use, D365, SAP, Oracle, preserving custom fields, approval hierarchies, and tax codes without a separate transformation layer.
• A clear answer on who builds the integration end-to-end and what the ASP delivers out of the box on day one.
• A documented impact analysis on existing AP workflows, approvals, and master-data validation as part of the integration deliverable.
• Defined handling of in-flight invoices, intercompany flows, and existing integrations at cutover so nothing gets stranded between the old and new state.
• Both online and offline reporting modes supported in the same connector so transmission survives network outages.

ERP build cost should appear as a separate line item with the assumption-set behind that price documented, number of custom fields, number of approval levels, number of intercompany flows, number of master-data feeds. A vendor that quotes a single integration figure without those assumptions is quoting on a scope it has not yet seen, and the variance between the quoted price and the final invoice will show up after the contract is signed.

Most AP platform RFP templates were built for global procurement and carry none of the UAE mandate’s specifics, and six criteria separate vendors who have actually delivered in the UAE from those presenting a global template against a local brief.

Data hosting and sovereignty

The RFP needs to ask where data lives, which legal entity operates the infrastructure, and how MOF and FTA receive audit access when a transmission anomaly is investigated.

UAE-domiciled hosting is the safest answer for regulated tenants, particularly in DIFC, ADGM, and Free Zone contexts where data residency is part of the licence conditions. Offshore hosting is acceptable when the ASP can document the sovereignty controls applied and the audit-access path in detail, and the RFP should require documentary evidence on both points beyond a narrative response.

PINT-AE and Arabic handling

PINT-AE is the UAE billing specification, and Arabic handling has to cover field-level validation, right-to-left rendering, and bilingual archival across the ERP, the supplier portal, and the PDF rendering. A sample Arabic invoice from a live UAE deployment is a reasonable evidence requirement, and most vendors with real UAE implementations can produce one within a day.

Tax Groups and Free Zones

Each Tax Group member carries its own TIN and PEPPOL Participant ID formatted as 0235 followed by the 10-digit TIN, and Free Zone entities follow specific scenario rules under the UAE e-Invoicing Guidelines, when the customer is a Free Zone entity, the electronic invoice must include the “beneficiary” details in addition to the customer.

Entity-level routing and validation has to be configurable without custom development for every new entity onboarded, because groups add and dissolve UAE entities as a routine part of the operating model, and a per-entity custom-development cycle does not scale to that pattern.

Invoice categories and scenarios

The UAE Electronic Invoicing Guidelines V1.0 (Section 10) defines six categories of Electronic Invoices: Electronic Tax Invoice, Electronic Tax Credit Note, Commercial Invoice, Electronic Credit Note, Self-billed electronic Tax Invoice, and Self-billed electronic Tax Credit Note.

These categories are defined alongside eight scenarios with specific mandatory-field requirements covering Free Zone, Deemed Supply, Margin Scheme, Summary Invoice, Continuous Supply, Agent, E-commerce, and Exports transactions.

Every category and scenario relevant to your operating model should be tested in the ASP environment against PINT-AE mandatory fields before shortlisting, and the RFP should require the ASP to provide a UAT script covering each one with documented evidence of validation against the published schema.

Post-implementation entity onboarding

Adding, acquiring, or dissolving UAE entities is a routine part of corporate operations, and the RFP should ask for the pricing, lead time, and configuration process for onboarding a new entity after initial go-live. A fixed-price tier with a defined lead time means the vendor has productised the work, while a “subject to scoping” response means every new entity onboarding will be a fresh negotiation on terms that get worse once the platform is embedded.

Regulatory-update SLA

MD No. 64 accreditation is granted for two years and must be renewed. MOF and FTA schema revisions are continuous, the Mandatory Fields and Guidelines documents have already been updated since initial publication.

The RFP should require the ASP to publish its renewal cadence, document its track record on prior schema updates, and commit to a fixed turnaround SLA on every regulatory schema update, typically 30 to 60 days from FTA publication.

Adoption is the most common reason UAE e-invoicing implementations stall in production, and three workstreams need named owners and contractual SLAs before contract signature. Tax Group rollout sequencing is the first: a multi-entity Tax Group cannot go live in one weekend, and the plan needs to sequence the AED 50M+ entities first under MD No. 244, then smaller cohorts, with a defined fallback procedure if an individual entity fails its UAT cycle.

Supplier enablement is the second: suppliers across mainland, Free Zone, and branch entities each carry different validation rules, portal access has to be available in Arabic and English, and onboarding paths for international suppliers, exempt categories, and non-mandated suppliers all need to be documented separately.

Exception handling is the third: when an invoice fails PINT-AE validation at month-end, the resolution path needs to be documented before go-live with a named owner, an SLA for resolution, and the trigger conditions for FTA escalation.

The RFP should require all three written into the contract with named owners on both sides, a named change-management lead on the ASP side, a supplier onboarding plan with per-tier SLAs, and a documented exception-handling procedure with MOF and FTA escalation paths. Without contractual ownership on each, adoption work falls back onto the customer’s AP and IT teams in the months when they have the least capacity to absorb it.

What is the UAE e-invoicing mandate?

The UAE e-invoicing mandate requires Persons conducting Business in the State to issue, transmit, and report Electronic Invoices through Accredited Service Providers (ASPs) for in-scope Business Transactions. The mandate is governed by MD No. 243/2025 (scope), MD No. 244/2025 (rollout), MD No. 64/2025 (ASP accreditation), and Cabinet Decision No. 106/2025 (penalties), with technical detail in the UAE Electronic Invoicing Guidelines V1.0.

Who must comply, and when?

Rollout follows revenue cohorts under MD No. 244/2025: Persons with annual revenue at or above AED 50 million must appoint an ASP by 31 July 2026 and go live on 1 January 2027, Persons below AED 50 million must appoint by 31 March 2027 and go live on 1 July 2027, and Government Entities go live on 1 October 2027 with their own ASP appointment deadline of 31 March 2027. A pilot phase runs from 1 July 2026 with voluntary onboarding open to any taxpayer who wants to test transmission ahead of the mandatory cohort deadline.

What is PINT-AE?

PINT-AE is the UAE-specific PEPPOL International (PINT) billing specification, and it defines field-level validation, mandatory data elements, and the structure of every compliant invoice transmitted on the UAE network. Every accredited ASP must transmit in PINT-AE format, and the MoF Mandatory Fields specification (V1.0, Feb 2026) lists the required fields by category and scenario for use during ASP UAT and platform shortlisting.

What is the difference between MD 64 accreditation and ASP capability?

MD No. 64/2025 sets the minimum requirements for ASP accreditation — PEPPOL certification, ISO 22301, ISO/IEC 27001, AED 2.5 million professional indemnity insurance, and at least two years of e-invoicing experience. It does not measure data residency, ERP integration depth, operating UI, process fit, or commercial transparency. The MoF’s own Considerations for Selecting an ASP covers the next layer at a high level.

How does Tax Group structure affect platform selection?

Each Tax Group member carries its own TIN and its own PEPPOL Participant ID formatted 0235 + 10-digit TIN, which means a Tax Group of seven entities is seven separate onboarding workstreams that each need their own routing, validation, and UAT. Intra-group transactions are also in scope from 1 January 2027 for at least 24 months, so per-entity configuration must be possible without custom development and the rollout plan must sequence go-lives by entity with a defined fallback procedure when any individual entity fails its UAT cycle.

What happens if an ASP loses MD 64 accreditation?

MD No. 64 accreditation is granted for two years and must be renewed at the end of each cycle, and if an ASP fails renewal, transmission stops and the customer must migrate to an accredited successor while the regulatory clock keeps running on outbound invoices. Without a documented export format and migration procedure in the original contract, an accreditation lapse becomes an operational crisis with Cabinet Decision 106 penalty exposure attached for every day transmission is offline.

How long should a UAE e-invoicing implementation take?

For a single-entity go-live on a standard ERP release, 12 to 16 weeks is the typical implementation window from kickoff through to first transmission, and for multi-entity Tax Groups the realistic range is 6 to 9 months covering UAT and sequential go-lives across each Participant ID. Implementations that quote shorter than 12 weeks for a Tax Group rollout are usually under-scoping integration, supplier onboarding, or both, and the gap shows up as overruns in the second half of the project once the productised scope runs out.

Where can I learn more about UAE e-invoicing penalties?

Cabinet Decision No. 106/2025 sets the penalty schedule for non-compliance, and penalties begin from the cohort go-live date — 1 January 2027 for the AED 50M+ cohort, with daily and per-document penalties accruing from the moment transmission falls behind the requirement. Read more in our guide to UAE e-invoicing penalties and enforcement.