You appointed an ASP. Now you have to connect to it.

Last verified: 2026-08-1911 min read

Choosing a provider feels like the hard part. For most businesses it is not. The contract gets signed, the onboarding runs through EmaraTax, and then someone asks the question that decides the timeline: how do the invoices actually get from our system into theirs?

That question has a clean answer for a business running mainstream accounting software with a built connector waiting for it. It has a much longer answer for a business running something in-house, something old, or something that has been customised for fifteen years until it stopped resembling the product it started as. This guide is about the second case, which is more common than the marketing suggests.

If you have not chosen a provider yet, the hurdle before this one is covered in choosing an accredited service provider.

Accreditation covers the transmission, not your system

Worth being precise about where the boundary sits, because most of the confusion lives here.

An accredited service provider is accredited under Ministerial Decision No. 64 of 2025 to do a specific set of things: validate invoice documents against the PINT AE specification, transmit them over the Peppol network, and report tax data to the Federal Tax Authority (FTA). That is the regulated pipe, and accreditation is the Ministry's statement that a provider can operate it correctly.

What accreditation does not speak to is the section of the journey before that: getting invoice data out of whatever your business uses to raise invoices, in a shape the provider can accept. That is upstream of the regulated boundary. It is not part of what a provider is assessed on, and it varies enormously between businesses, because your invoicing system is your own decision and always has been.

So this is a structural gap, not a failing. Providers are accredited to run the pipe. Connecting your system to the pipe is a separate discipline, and whether a given provider has already solved it for your particular software is the single biggest variable in your timeline.

Where the connection actually stalls

Four situations come up again and again.

In-house and bespoke systems. Software written for the business, sometimes years ago, sometimes by someone who has left. There is no off-the-shelf connector for it and there never will be, because there is exactly one installation of it in the world.

Older on-premise ERPs. The data is all there, but getting at it means database access, a scheduled export, or a middleware layer, rather than an API call. Nothing is impossible, everything takes longer.

Heavily customised deployments. A mainstream ERP with a decade of modifications. The connector exists, but it was built against the standard object model, and yours has extra fields, changed field meanings, and a custom document numbering scheme. The connector works and produces the wrong invoice.

Invoices assembled from more than one system. Billing in one place, the customer master in another, tax determination in a third. No single system holds a complete invoice, so no single connector can extract one.

None of these is exotic. Together they cover a large share of established UAE businesses, particularly the ones with enough revenue to be in the first compliance wave.

Why you get referred to a system integrator

If you land in one of those four situations, a common answer from a provider is a referral to an implementation partner.

That is a legitimate delivery model and it is explicitly contemplated by the regulation. A May 2026 amendment to Ministerial Decision No. 64 of 2025 allows accredited providers to deliver their technology in collaboration with third parties. A provider who tells you that a custom integration is best handled by an integrator is not deflecting. They are telling you accurately that building a one-off connector to your bespoke system is a professional services engagement, not a configuration screen, and that it is a different business from operating an accredited network connection.

The referral is honest. It is just expensive in the currency you are shortest of, which is calendar time.

What an integrator engagement adds

A custom integration project is a real project, with the shape every real project has.

Scoping and discovery, to establish what your system holds and how to get at it. Field mapping, which is the substance of the work. Build. A test cycle against the provider's sandbox. User acceptance testing with your finance team, because they are the ones who will meet the failures. Then change control, because your invoicing system is production and you cannot iterate on it casually.

Add the coordination overhead of a three-party arrangement: you, the provider, and the integrator, each with a different view of what is blocking. Nothing here is unreasonable. It simply does not compress well, and it is usually discovered after the provider contract is signed, which is the worst moment to find out.

The mapping problem underneath all of it

Strip away the project management and almost all of this work is one thing: deciding which field in your system corresponds to which business term in PINT AE.

The specification is built on UBL 2.1 with a UAE customisation. Every invoice carries mandatory business terms, conditional ones that depend on the transaction, and code lists that must match exactly. Your system has a supplier reference field. Which business term is that, if any? Your line items carry a tax category that made sense internally for years. Which PINT AE code does it map to, item by item?

This is unglamorous, it needs someone who understands both your business and the specification, and it is where custom integrations spend most of their time. The PINT AE fields glossary and the data dictionary exist so you can do this work with the actual field list in front of you, and PINT AE explained covers what the specification is doing underneath.

The mapping is also a one-time exercise. Once each field is placed correctly, it stays placed. That is the reason this hurdle is worth attacking properly rather than routing around.

What it looks like when the connection is already built

The contrast is stark, which is the point of building connectors at all.

If you run Zoho Books, QuickBooks Online, Xero, or Microsoft Dynamics 365 Business Central, the mapping work has been done once, centrally, against the standard object model, and it is maintained as both the software and the specification change. You authorise a connection and invoices start flowing. There is no scoping phase because there is nothing to scope.

Tally Prime is next on our list and is not live yet. We would rather say that plainly than list it and let you plan around something that does not exist.

If your system is bespoke

Bespoke does not mean you are stuck with an integrator engagement. It means the connection has to be described once rather than looked up.

Excel and CSV. You export invoices the way you already do and drop the file. The one piece of setup is telling us which of your columns is which, once. After that every upload just works, because the mapping is saved. Businesses with IT capability automate the drop over SFTP, at which point nobody touches it at all.

The REST API. For systems that can make an outbound call, there is an API. Your system posts invoice data, we handle validation, PINT AE conversion, and the accredited provider connection from there. This is the route for in-house software, for middleware in front of an older ERP, and for the multi-system case where you already have somewhere that assembles a complete invoice.

Both routes share the same honest framing. The claim is not zero setup. Mapping your fields once is a real, bounded piece of work with a beginning and an end. The claim is that nothing about how you work changes afterwards: the same people raise invoices the same way in the same system, and compliance happens behind that.

Validation failures deserve a word here too, because they are the one moment anyone in your business touches compliance directly. When an invoice fails, the exception needs to arrive in language a finance person can act on, with a clear fix, rather than as a Schematron code. Ask about this wherever your invoices end up. It is the difference between a system that handles compliance and a system that forwards it to you.

The nine-week problem

For the largest businesses the arithmetic is worth stating plainly, as dates.

If your annual revenue is AED 50 million or above, you appoint an accredited provider by 30 October 2026 under Ministerial Decision No. 244 of 2025 as amended, and you go live on 1 January 2027 under Ministerial Decisions No. 243 and 244 of 2025. The appointment date moved out from 31 July 2026. The go-live date did not move.

That leaves roughly nine weeks between appointing and being live, across a period containing the December holidays and a year-end close. Nine weeks is comfortable for a connector that already exists. It is tight for a scoping exercise, a build, and a UAT cycle with three parties in the room.

Which is the practical argument for doing the integration thinking early, while you are still comparing providers rather than after you have signed with one. The question "can you connect to what we actually run" belongs in the first conversation, not the fourth.

For businesses below that threshold the mandate is phased through 2027 and there is more room. The work is identical, only the deadline is different.

Where Nazm fits

Nazm is the layer between your system and the accredited provider.

You still appoint an accredited provider, and that legal obligation remains yours. What sits on top of it is ours: the connection to your software, the field mapping, validation before anything is transmitted, the canonical archive of what was sent, and the management of the accredited provider relationship itself. If the arrangement underneath ever needs to change, we handle the migration and your integration does not change.

For mainstream accounting software that means a connector that already exists. For Excel it means map once and drop the file. For bespoke systems it means SFTP or the API, and a mapping exercise measured in days rather than a project measured in months.

If you are working through this now, the ASP directory shows the current landscape, and choosing an accredited service provider covers the decision that comes first. If you would rather not run either project, ask us for early access and we will take it from your invoice data onwards.

Common questions

Does my ASP handle the integration with my accounting system?

Sometimes, and it depends entirely on the provider and the software. Accreditation under Ministerial Decision No. 64 of 2025 covers validation, transmission over the Peppol network, and tax data reporting. Getting invoice data out of your system and into theirs sits upstream of that boundary, so whether a connection already exists for your particular software varies a great deal between providers.

Can an ASP connect to a custom or in-house built system?

Rarely out of the box, because there is one installation of your software in the world and no off-the-shelf connector for it. The connection has to be described once rather than looked up, which in practice means a mapped file drop, an SFTP feed, or an API your system posts invoice data to.

Why do accredited providers recommend a system integrator?

Because building a one-off connector to a bespoke system is a professional services engagement rather than a configuration screen, and it is a different business from operating an accredited network connection. A May 2026 amendment to Ministerial Decision No. 64 of 2025 explicitly allows accredited providers to deliver their technology in collaboration with third parties.

How long does ASP integration take?

If a connector for your accounting software already exists, you authorise a connection and invoices start flowing, because there is nothing to scope. A custom integration is a project with scoping, field mapping, build, sandbox testing, user acceptance testing, and change control. That sequence does not compress well, which matters most for businesses appointing by 30 October 2026 and going live on 1 January 2027.

What if my invoices are assembled from more than one system?

This is one of the cases where a single connector cannot help, because no one system holds a complete invoice. The usual answer is to assemble the invoice in one place first, then send it onward through a single route, either a mapped file drop or an API call.

Do I need to replace my accounting software for UAE e-invoicing?

No. Zoho Books, QuickBooks Online, Xero and Microsoft Dynamics 365 Business Central have connectors already built, Excel and CSV work through a mapped file drop or SFTP, and bespoke systems can post to an API. Mapping your fields is a one-time setup, after which the way your team raises invoices does not change.

Sources

Ministerial Decision No. 64 of 2025, on the accreditation of Service Providers, as amended
Ministerial Decision No. 243 of 2025, on the Electronic Invoicing System
Ministerial Decision No. 244 of 2025, on the Implementation of the Electronic Invoicing System, as amended
UAE Electronic Invoicing Guidelines V1.0, Ministry of Finance, 23 February 2026
PINT AE specification, UBL 2.1 with the UAE customisation

Dates verified against primary Ministry of Finance sources on 19 August 2026. Provider accreditation status changes; confirm the exact legal entity on the Central Register before signing anything. None of this is tax advice. Take UAE-qualified advice before acting on anything with a deadline attached.

Tools

E-invoicing, handled for you

Nazm turns these rules into a working PINT AE integration — appointment, validation, transmission, and reporting — so you meet the deadline without becoming an expert.