Choosing an ASP is an architecture decision, not a procurement one

Every business in scope of the UAE e-invoicing mandate has to appoint an Accredited Service Provider. There is no direct connection to the Federal Tax Authority, no self-service corner of the network, and no exemption for companies that already run good invoicing software. You contract with one ASP, you onboard to it through EmaraTax, and from then on every invoice you issue leaves your building through that one door.

The evaluation that usually precedes this is a procurement exercise: price per invoice, uptime SLA, support hours, logo on the Ministry’s register. All reasonable. None of it predicts how much work the integration will be, or how much of your own system you will end up handing over. Building NAZM’s submission layer, we found the differences that actually matter sit one level below the commercial sheet, and most of them are invisible until you have API docs in front of you.

Who owns the XML

This is the fork that decides everything downstream. Some ASPs accept a finished PINT AE UBL document and act as a transport: you generate, they validate and route. Others accept their own JSON or CSV shape and generate the UBL themselves as a service.

The second option looks like less work, and for a small merchant with one source ledger it may genuinely be. For a platform it is a bad trade. If the provider generates the XML, their mapping decisions become your compliance posture: their interpretation of tax category codes, their rounding, their handling of a credit note against a partially paid invoice. When an invoice is rejected you are debugging a document you did not produce, through a support queue. And the artefact you are legally on the hook for is one you have never seen.

We chose to own generation, which means owning validation too - the same data dictionary, VAT and schema rules the network runs, executed before anything leaves the platform. The upside is that a rejection from the ASP becomes a rare event rather than a workflow, and the error a customer reads is a sentence about their invoice rather than a schema fault code.

Sync answer or async verdict

The second question to ask any provider is what submit actually returns. Some APIs give a verdict on the request. Most give you an accepted-for-processing receipt and a transaction id, and the real outcome arrives minutes later by callback, by polling, or both. That single detail determines whether your submission path is a function call or a state machine with durable storage, timeouts and a reconciliation job.

Because we could not know which provider a customer would land on, the pipeline was written against the smaller of the two shapes:

export interface AspGateway {
  submit(params: {
    invoiceId: string;
    organizationId: string;
    xmlPayload: string;
    attemptNumber: number;
  }): Promise<AspSubmitResult>;
}

export type AspSubmitResult =
  | { status: 'submitted'; transactionId: string } // accepted, verdict pending
  | { status: 'rejected'; reason: string } // the network said no
  | { status: 'failed'; error: string }; // we never got an answer

Three outcomes, not two. The distinction between rejected and failed is the one people collapse, and it is the one that causes duplicate invoices: a rejection is final and safe to leave alone, a transport failure means the invoice may or may not be in flight. A separate poller reconciles anything still awaiting a verdict, and the pipeline itself depends only on this interface. Swapping providers is a binding change, not a rewrite.

The questions worth putting in the RFP

Beyond the two above, these are the ones whose answers changed our design:

• “What is your idempotency key?” If retrying a timed-out submission can create a second invoice at the tax authority, that is your problem to solve, and you need to know now.
• “Is there a sandbox before we sign?” Providers who can hand you credentials and a rejecting test endpoint during evaluation are describing a product. Providers who can only demo are describing a roadmap.
• “Who bumps the version?” PINT AE specifications move. When the network adopts a new customisation identifier, is that a coordinated release with you, or a date on which your invoices begin failing?
• “How do inbound invoices reach us?” Corner 3 to corner 4 is half the model and gets a tenth of the attention in most conversations. Push, poll, and what the retention window is.
• “Which legal entity is accredited, and at what stage?” Accreditation attaches to a named entity on the Ministry’s Central Register, and pre-approved and accredited are distinct stages that marketing copy tends to blur. Check the register, not the deck - ours included.

Why the stickiness matters

A person or government entity onboards with a single ASP for all their e-invoicing. Switching later is not a config change: it is re-onboarding through EmaraTax, re-establishing the participant identifier, and whatever your contract said about exit and data extraction on a day when nobody is feeling generous. With appointment deadlines in late 2026 and early 2027, most of these decisions are being taken right now, under time pressure, on the basis of a price list.

The defensible position is to keep the surface small. Own the canonical model, own generation, own validation, and let the provider be a well-defined edge with three possible answers. Do that and the ASP choice stops being an architecture decision and becomes what everyone assumed it was in the first place - a commercial one.

If you are picking a provider and want a second read on the technical questions, we’re easy to reach.