What is an ASP in UAE e-invoicing, and how do you choose one?

The short version

In the UAE e-invoicing model, your business does not talk to the Federal Tax Authority directly. It talks to an Accredited Service Provider (ASP). The ASP is your gateway to the Peppol network and your channel for tax reporting. Choosing an ASP, and integrating with it well, is one of the most important decisions in your UAE e-invoicing project.

What does an ASP do?

Within the UAE’s 5-corner model, an ASP sits at corners 2 and 3:

• As your provider (corner 2): it receives invoice data from your system, validates it against PINT AE and UAE business rules, and sends it over Peppol to the buyer’s provider.
• As the buyer’s provider (corner 3): it receives invoices sent to its customers and delivers them into their systems.
• Tax reporting (to corner 5): it reports the required invoice data to the FTA.

Most ASPs also provide portals, APIs, inbound invoice delivery, archiving and support. Some provide ERP connectors for popular systems.

What does an ASP not do?

Being clear about this avoids surprises later:

• It doesn’t fix your data. If a buyer’s Tax Registration Number is missing in your ERP, the invoice will be rejected.
• It doesn’t extract invoices from your ERP unless it offers (or you buy) a connector for your specific ERP and version.
• It doesn’t decide your tax treatment. Mapping your tax codes to PINT AE categories is a finance and tax decision.
• It doesn’t handle your internal rejection process. Someone in your team must correct and resubmit.

That gap between your ERP and the ASP’s API is where most of the engineering work sits.

How the ASP fits the 5-corner model

How do you choose an ASP?

Price matters, but it shouldn’t be the only factor. Here is the checklist we use when helping clients compare providers neutrally:

Accreditation and stability

• Listed on the Ministry of Finance’s official list of accredited providers.
• Track record with Peppol in other countries, or a credible UAE plan.

API and integration

• Well-documented REST API with a sandbox environment.
• Clear error codes and validation messages that map to PINT AE rules.
• Webhooks or status endpoints for asynchronous responses.
• Support for credit notes, inbound invoices and attachments.
• Reasonable rate limits for your volume.

ERP support

• Existing connector for your ERP and version, or openness to a third-party connector.
• No requirement to send data in a proprietary format that locks you in.

Operations

• Support hours that match yours, with an escalation path.
• Monitoring dashboards and archive access.
• Data residency and security certifications that satisfy your policies.

Commercials

• Pricing model that fits your volume (per invoice, tiered or subscription).
• Clear contract terms on exit and data export.

Why ASP-agnostic integration matters

Many businesses will choose their first ASP under time pressure. Prices, features and service quality will change as the market matures. If your ERP integration is written tightly against one ASP’s API, changing provider later means another integration project.

An ASP-agnostic design separates three layers:

1. Extraction from your ERP.
2. A canonical invoice model mapped to PINT AE, with your validation rules.
3. An ASP adapter that speaks to your provider’s API.

Switching ASP then means replacing layer 3 only. The same structure lets one ERP serve several countries, for example a UAE ASP adapter alongside a ZATCA module for Saudi Arabia.

How does integration with an ASP work in practice?

A typical flow for each invoice:

1. Invoice is posted in your ERP.
2. The connector picks it up and maps it to PINT AE.
3. The connector pre-validates it (tax IDs, totals, categories) before calling the ASP.
4. The connector submits it to the ASP’s API with a unique reference, so retries never create duplicates.
5. The ASP validates, transmits over Peppol and reports to the FTA.
6. The connector records the ASP’s response on the invoice in your ERP: accepted, or rejected with reasons.
7. Rejections appear in a queue for your finance team.

Questions to ask an ASP before signing

• Which ERPs do you have production connectors for, and which versions?
• Can we see your API documentation and get sandbox access before signing?
• How do you return validation errors, and how quickly?
• How are inbound invoices delivered to us?
• What happens to our data and archives if we leave?
• What are your support hours, and who do we talk to when invoices are rejected at month end?

Pricing models you are likely to see

ASP pricing varies, and the cheapest headline price is not always the cheapest outcome. Common structures include:

• Per document: a fee per invoice or credit note sent, sometimes with a separate fee for documents received.
• Tiered bundles: a monthly or annual allowance of documents, with overage charges above the tier.
• Subscription per entity: a fixed fee per legal entity or TRN, regardless of volume within limits.
• Setup and connector fees: one-time charges for onboarding or for an ERP connector the ASP provides.

When comparing, model your real volumes, including credit notes and inbound invoices, across a full year with seasonal peaks. Ask what happens to pricing when your volume grows, and whether archive access after you leave is included.

What good onboarding with an ASP looks like

A well-run onboarding follows a predictable path. Use it to judge both your ASP and your integration partner:

1. Contract and identifiers. Your entities are registered with the ASP and Peppol participant identifiers are set up.
2. Sandbox credentials early. Your integration team gets API access before the build starts, not at the end.
3. Test scenarios agreed. You and the ASP agree which invoice scenarios must pass, including credit notes, exports and reverse charge.
4. Error catalogue shared. The ASP explains each validation error your team may see and what usually causes it.
5. Production switch-over planned. A date, a rollback plan and named contacts on both sides for the first billing cycles.
6. Ongoing change notices. The ASP tells you in advance about specification or API changes, with a test window.

If any of these are missing, raise it early. Most go-live delays come from late sandbox access and unclear error handling, not from the integration code itself.

For ASPs: the other side of the table

If you are an ASP, your bottleneck is often not the platform but the number of client ERPs waiting to be connected. Co-Mate works with ASPs and Access Points as a white-label integration team, building ERP adapters and handling client onboarding under your brand.

Next steps

If you haven’t chosen an ASP yet, start with the official list and the checklist above. If you have, the next step is a field gap analysis between your ERP and PINT AE. Our UAE e-invoicing integration service covers both, and our engineers can join your ASP evaluation calls to ask the technical questions.