ASP Selection Advisory

An ASP is an entity certified by the Federal Tax Authority to sit in the invoice exchange chain between a taxpayer's ERP or accounting system and the buyer's own ASP, validating invoices against the PINT-AE data standard, exchanging them over the Peppol network, and reporting transaction data to the FTA. Under the UAE's decentralised Continuous Transaction Control model, taxpayers do not submit invoices to the FTA directly — every in-scope invoice must pass through an accredited ASP.

You should still evaluate the recommendation rather than accept it by default. ERP vendors often have a commercial partnership with a specific ASP, which can be a genuinely good fit, but the recommendation is rarely independent of that commercial relationship. An independent comparison against your actual volume, invoice-type mix, and pricing sensitivity confirms whether the vendor-recommended ASP is actually the best fit or simply the path of least resistance for the vendor.

Yes, and for groups with genuinely different ERPs, transaction volumes, or business lines across entities, using more than one ASP can be the right answer rather than forcing a single provider across an incompatible landscape. The decision should be made deliberately, weighing the operational simplicity of a single group-wide relationship against the better technical or commercial fit of entity-specific providers.

ASPs commonly price on a per-invoice basis, a tiered volume subscription, or a flat monthly/annual fee, sometimes with a minimum commitment. A per-invoice price that looks cheapest in isolation can be more expensive than a subscription model once your actual projected volume is applied, and vice versa. A fair comparison normalises every shortlisted ASP's pricing against your specific projected volume and invoice-type mix, not the provider's headline rate.

Where native connectivity does not exist, the options are typically a middleware or API layer built to bridge the ERP and the ASP, a manual or semi-manual data export/import process (which reintroduces the error risk the mandate is meant to eliminate), or selecting a different ASP with confirmed native connectivity. Confirming connectivity before contracting, rather than after, avoids discovering this gap during integration when switching providers is far more disruptive.

For a single-entity business with one ERP and a reasonably well-understood invoice profile, ASP selection typically takes three to four weeks from scoping to a documented recommendation. Groups with multiple entities, ERPs, or jurisdictions take longer, since each additional system requires its own connectivity and volume assessment before a responsible recommendation can be made.

No. PNPC's ASP Selection Advisory is an independent evaluation service. We do not resell ASP software, and our recommendation is based on the client's own weighted scoring criteria — technical fit, commercial terms, operational track record, and support quality — rather than any commercial arrangement with a provider.

Accreditation confirms an ASP meets the FTA's technical and security certification — it does not guarantee operational maturity. Worth checking specifically: how long the provider has been live with UAE taxpayers in production (versus sandbox or pilot only), typical validation-error resolution turnaround, Peppol delivery failure handling, uptime history, and whether the provider has genuine experience with your specific ERP and invoice-type mix rather than only similar-sounding platforms.

PINT-AE is the UAE's localisation of the Peppol International invoicing data standard — the structured data format every e-Invoicing-compliant invoice must conform to before it can be validated and exchanged. An ASP's ability to correctly map your ERP's invoice data into PINT-AE format, including UAE-specific fields such as VAT treatment and TRN details, is a core technical evaluation criterion, not a peripheral one.

Yes, but switching is more disruptive than getting the initial selection right, since it involves re-establishing technical connectivity, migrating any archived invoice data the ASP holds, and managing a transition period without disrupting live invoicing. Exit and data-portability terms should be reviewed in the original contract precisely so a future switch, if needed, is not unnecessarily difficult or costly.

After. An Impact Assessment first confirms whether, when, and to what extent the e-Invoicing mandate applies to your business, and surfaces the ERP, process, and data gaps that need addressing. ASP selection then proceeds with that scope and readiness picture already established, rather than selecting a provider before understanding what the business actually needs it to do.

The ASP handles invoice validation, exchange, and FTA reporting, but the underlying VAT treatment applied to each invoice — the rate, the exemption or zero-rating basis, the place-of-supply determination — is still the taxpayer's responsibility under Federal Decree-Law No. 8 of 2017. An ASP does not correct incorrect VAT treatment in your source data; it validates that the data is structurally complete and correctly formatted. A VAT Functional Gap Analysis alongside ASP selection confirms the underlying VAT data feeding the ASP is itself accurate.

At minimum, a finance lead who understands current invoicing volume and processes, and an IT contact who can speak to the ERP's technical configuration and respond to connectivity questions from shortlisted ASPs. For larger or multi-entity businesses, input from each affected entity's finance or operations lead is needed to accurately profile invoice volume and type across the group.

A written selection recommendation including the shortlisted ASPs evaluated, the weighted scoring matrix used, the commercial and technical comparison, and a clear rationale for the recommended provider — including why alternatives were not selected. This document is suitable for board or group finance approval and stands as a defensible record of the decision basis.

The core evaluation criteria — technical connectivity, commercial terms, operational track record, and support quality — are the same regardless of licensing jurisdiction, because the FTA's e-Invoicing mandate and ASP accreditation requirement apply uniformly across Mainland and Free Zone entities. A Free Zone entity's Qualifying Free Zone Person status affects how its income is taxed under Corporate Tax; it does not change whether the entity must connect to an accredited ASP. What can differ is the invoice-type and volume profile, which is a normal input into the selection, not a separate accreditation requirement.

Each entity is assessed on its own ERP, volume, and invoice-type profile, and we specifically check whether DIFC or ADGM-registered entities carry any additional centre-specific regulatory or data-handling requirement that should factor into the ASP choice for those entities. A single ASP can often still serve the whole group where the underlying technical and commercial fit supports it, but the decision should be made deliberately rather than assumed.

Worth asking directly: where the ASP hosts and processes invoice data, how long it retains data after the contract ends, what its data-deletion process looks like on exit, and what security certifications it holds. This matters more for businesses in regulated sectors or those handling commercially sensitive pricing and customer data, since every in-scope invoice passes through the ASP's systems for validation and exchange.

This is precisely why exit and data-portability terms should be reviewed in the ASP contract at selection stage, before you need them — a provider losing accreditation or ceasing operations would require migrating to a new accredited ASP, and how quickly and cleanly that can happen depends on the exit terms already in place and how easily your invoice archive can be extracted. Selecting an operationally mature provider with a solid UAE production track record is the practical risk mitigant during selection itself.

This is not standard practice for most businesses and adds meaningful cost and integration complexity, but for very high-volume or business-critical invoicing operations it is worth evaluating as part of the selection discussion. For most clients, the more practical mitigant is selecting a single ASP with a strong uptime and support track record and confirming the contract's service-level and exit terms are solid, rather than building and maintaining a second integration that may rarely be used.

PINT-AE, as the UAE's localisation of the Peppol data standard, is built to carry currency information as a structured data field, and an ASP's ability to correctly map your ERP's multi-currency invoicing — including any exchange rate convention your business applies — into that structure is part of the technical evaluation for businesses with material foreign-currency invoicing.

The exchange mechanism through the ASP and the Peppol network is the same regardless of the invoice recipient's nature, but government and free zone authority counterparties can have their own procurement or documentation expectations that sit alongside the e-Invoicing exchange itself. Where a business has material government or authority-facing invoicing, we factor that recipient profile into the invoice-type assessment during selection.

Self-billing means the buyer, rather than the seller, generates the invoice on the seller's behalf, which requires both parties' systems and ASPs to handle the exchange correctly. Not every ASP supports self-billing configurations equally well, so businesses with existing or planned self-billing arrangements should confirm this capability specifically during the technical evaluation rather than assuming it is covered under general 'invoice support.'

UAE tax law requires businesses to retain accounting and tax records, including invoices, for a prescribed period, and an ASP's own archiving capability — how it stores exchanged invoices, for how long, and how accessible that archive is to the taxpayer — is a relevant selection criterion, particularly since the business remains responsible for its own record-retention obligation regardless of what the ASP additionally retains.

A Designated Zone's special VAT treatment for certain goods transactions under Federal Decree-Law No. 8 of 2017 is a VAT question, separate from the e-Invoicing exchange requirement itself — an entity operating in or invoicing from a Designated Zone still needs to route in-scope invoices through an accredited ASP. Where Designated Zone VAT treatment affects the invoice data itself, that is a data-accuracy question best addressed through a VAT Functional Gap Analysis alongside ASP selection.

The Peppol network is the same decentralised exchange infrastructure used in other Peppol-based e-invoicing jurisdictions internationally, and PINT-AE carries the structured data fields needed for cross-border transactions, including export documentation references where applicable. For businesses with material export volume, confirming a shortlisted ASP's practical experience handling cross-border transaction data — not just its accreditation — is a worthwhile part of the evaluation.

A low headline price that has not been normalised against your actual projected invoice volume and type mix can turn out more expensive in practice than a provider with a higher headline rate but a better-fitted pricing structure. Beyond price, the lowest-cost option is sometimes also the newest to market or the least operationally proven, which shifts risk onto support responsiveness and error-resolution turnaround rather than removing cost.

A very small, single-entity business with simple, low-volume invoicing and a common accounting platform that already has clear, documented ASP connectivity may only need a lighter comparison of two or three shortlisted providers rather than a full weighted evaluation across the entire accredited list. The evaluation should still be deliberate — connectivity confirmed in writing, pricing normalised against actual volume — just proportionate to the business's scale and complexity.

ASP pricing is a private commercial arrangement negotiated between the taxpayer and the ASP; the FTA's role is accreditation — certifying that an ASP meets the technical, security, and compliance requirements to operate in the exchange chain — not setting or capping commercial pricing. This is why pricing models and rates vary meaningfully across accredited providers and why a normalised commercial comparison is a necessary part of selection.

Where a business is already committed to an ERP transformation or migration, ASP selection should be sequenced against that timeline rather than bolted on afterward — evaluating ASP connectivity to the target ERP platform rather than the system being replaced, and coordinating the go-live timing of both projects so the business is not building an ASP connection to a system it is about to retire.

The ASP-routed exchange requirement applies going forward from the entity's mandate effective date; invoices already issued before that date under whatever invoicing process was previously in place are not retrospectively routed through the new ASP relationship. The go-live cutover and any parallel run period should be planned clearly so there is no ambiguity about which invoices follow the old process and which follow the new one.

Where a business has material business-to-consumer invoicing volume — high-volume retail, F&B, or point-of-sale transactions, for example — that volume pattern and any summary or consolidated invoicing approach used for it should be confirmed as part of the invoice-type profiling during selection, since it can affect which ASPs are genuinely well suited to the business. Confirming exactly which of your transaction types fall within the mandate's current scope is a question best resolved in the e-Invoicing Impact Assessment before ASP selection begins.

Your ERP or accounting software records and generates the invoice; the ASP is the FTA-accredited entity that validates that invoice against the PINT-AE standard, exchanges it over the Peppol network, and reports it to the FTA. Some software platforms have direct, native partnerships with specific ASPs, but the software itself is not the accredited entity unless it has separately obtained ASP accreditation — the two roles are distinct even where a single vendor happens to offer both.

Yes. Where a client's internal procurement policy requires a formal request-for-proposal process, we structure the ASP evaluation criteria, scoring matrix, and shortlist comparison into a format suitable for a formal RFP and tender, rather than only producing an informal recommendation memo.

A non-trading holding entity that does not issue or receive invoices generally has no direct ASP requirement of its own, but each operating subsidiary within scope of the mandate still needs its own ASP evaluation based on its individual ERP, volume, and invoice-type profile. We coordinate the group-level view so the holding structure informs whether a shared ASP relationship makes sense across subsidiaries, without assuming the holding company itself needs a direct ASP connection.

The Peppol network is designed to exchange invoices between different ASPs, so two group entities on different accredited providers can still exchange intercompany invoices correctly, provided both connections are properly configured and tested. The added complexity is more on the coordination and testing side — confirming both ASP connections handle the intercompany invoice format correctly — than a fundamental technical barrier to using different providers.

Yes — an ERP or accounting platform change is one of the standard triggers for reassessing ASP fit, since the original selection criteria, particularly technical connectivity, were confirmed against the previous system and may no longer hold for the new one. This reassessment does not necessarily mean changing the ASP, but the connectivity and configuration should be re-confirmed rather than assumed to carry over automatically.

Beyond any contractual exit fees or notice periods, switching involves real operational cost — re-establishing technical connectivity with the new provider, migrating or re-archiving invoice history, retesting the exchange process, and managing a transition period without disrupting live invoicing. This operational cost is exactly why getting the initial selection right, rather than treating it as easily reversible, is worth the additional evaluation effort upfront.

We refresh our review of the FTA's published accreditation list at the start of every engagement rather than relying on a prior client's shortlist, since providers are added to and occasionally removed from the accredited list over time, and newer entrants may have matured operationally since an earlier evaluation was run.

We present the full scoring matrix and underlying evidence — connectivity confirmations, pricing comparison, reference checks — so the internal team can see exactly why the recommendation scored as it did, and we are open to revisiting the weighting or scope if the internal team has technical context we did not have. What we do not do is drop a documented, evidence-based recommendation simply to align with an unstated preference; any change to the recommendation is itself documented with the reasoning.