Your ERP, a connector and your ASP: who does what

What does an accredited service provider do?

An accredited service provider (ASP) is a Peppol service provider that the Ministry of Finance has accredited to provide e-invoicing services in the UAE: sending, receiving and exchanging e-invoices, e-credit notes and related business documents to the Ministry's standards. A service provider may offer those services in the UAE only after it is accredited (MD 168/2026, Art. 1 and Art. 3(1)). To be accredited, a provider must already be an active Peppol-certified service provider that has passed OpenPeppol's conformance tests (Art. 4(1)(a)).

Under MD 243/2025 every issuer and every recipient of e-invoices appoints an ASP and meets its exchange and reporting duties through it (Art. 5(1) and Art. 6(7)). In the five-corner model your ASP is corner 2. It validates the invoice data you send, converts it into the UAE XML e-invoice when it arrives in another format, sends it to the buyer's ASP, reports tax data to the Federal Tax Authority and passes the confirmations back to you (Guidelines V2.0, §5.1).

You appoint one ASP for both sending and receiving (Guidelines §6.1), chosen from the list the Ministry publishes (MD 243/2025, Art. 5(2)). Onboarding with it starts in EmaraTax (Guidelines §9), and when onboarding is complete the ASP gives you your Participant Identifier (App. 3, §15.4).

For businesses with revenue of AED 50 million or more, the deadline to appoint an ASP was 30 October 2026, and e-invoicing must be implemented by 1 January 2027 (MD 244/2025, Art. 5(1)(a), as replaced by MD 66/2026, Art. 1).

Sources: ^{[1][2][3][4][5][8]}

What does your accounting system or ERP do?

It stays where the invoice is born. You keep posting invoices and credit notes as you do today, and every e-invoice is built from that data. The legal duty to issue it stays with you: in practice ASPs carry out the exchange, but the compliance obligation remains with the supplier (Guidelines V2.0, §5.2).

The Ministry's readiness steps ask every business to check that its accounting, ERP or invoicing system can generate and extract all the data points an e-invoice needs, and to plan any data migration (Guidelines App. 1, §13.1(c)). The usual gaps are data your system never needed before: the buyer's Participant Identifier, which the supplier must collect from each buyer (§5.2), the invoice transaction type, and the tax category on every line.

One duty stays with you whatever software you use: notify your ASP in writing of any change to the data registered with the FTA, within five business days of the FTA confirming it (MD 243/2025, Art. 5(3)).

Sources: ^[1][2]

What is a connector, and what is it not?

A connector, also called an e-invoicing integration or middleware, is software on your side of corner 1. It reads posted invoices and credit notes from your system and hands their data to your ASP in the format you agreed with it. The Guidelines describe this step: corner 1 submits invoice data “in an agreed format” (Guidelines §5.1), and the readiness steps say businesses may need to integrate their applications with the ASP's systems (App. 1, §13.3(b)).

A connector is not an ASP. It holds no accreditation, does not exchange e-invoices with your buyers and does not report to the FTA. Exchange and reporting go through your ASP (MD 243/2025, Art. 6(7)), and a service provider may offer e-invoicing services only after it is accredited (MD 168/2026, Art. 3(1)). If a vendor suggests otherwise, look for its name on the Ministry's list.

What a connector can add sits on your side of the line: invoices read from your system instead of retyped, each one built and checked against the PINT AE rules before it leaves, and the ASP's status and any rejection reason brought back to whoever posted the invoice.

Sources: ^[1][2][5]

When do you not need a connector?

Often. This page is written by a connector vendor, which is why these cases come first. Check them before you buy anything:

• Your accounting software already sends e-invoices through an ASP. Some software vendors are themselves on the Ministry's list of accredited providers. If you are content with that provider, the route already exists.
• Your chosen ASP has its own integration for your system. The Ministry tells businesses to ask exactly this: whether the ASP can integrate with their current ERP, accounting or invoicing system, and through which APIs and data formats (Considerations for selecting an ASP, §3.2.2).
• You issue few invoices. If your ASP lets you enter or upload invoices yourself and your volume is small, that may be enough. Ask first how it handles credit notes and rejected invoices.
• Your IT can build and maintain the link to your ASP's API. If they can finish and test it before your go-live date, and keep it current when the specification changes, you may not need anyone else.

Sources: ^[7][8]

When does a connector help?

A connector earns its place when the direct route is missing or costly. The common cases:

• You want a different ASP from the one your software offers, for service, price or because your group already uses it. A connector lets you keep your system and still choose the provider.
• Your version has no e-invoicing support, and upgrading or replacing the system before your go-live date is not realistic.
• Invoices come from more than one system. A business appoints one ASP for both sending and receiving (Guidelines §6.1), so a sales system and a separate billing system in the same company must both feed that one provider.
• Your invoices live in an in-house system on its own database. A read-only database login lets a connector read posted invoices without touching the system. Vattora's connector for in-house SQL systems is in testing; see its real status.
• You want the check before the ASP. Each invoice is built and checked against PINT AE on your side, so a wrong tax category or a missing buyer identifier is fixed before it is sent, not after a rejection.

Sources: ^[1]

What about a group of companies?

Each member of a tax group onboards for e-invoicing on its own, with its own TIN and its own Participant Identifier, and the members may onboard with different ASPs (Guidelines App. 1, §13.2). The TIN is the first 10 digits of the member's own TRN, not the group representative's (§2). If members run different systems or choose different providers, list each pairing of system and provider before you decide how to connect them.

MD 197/2026 lists transactions between members of the same tax group as excluded for 24 months starting on 1 January 2027 (Art. 2, which rewrote Art. 4 of MD 243/2025; see the new Art. 4(1)(f)). The Guidelines call this a grace period that affects the timing only and does not take those transactions out of scope (§6.3.2). Every other transaction of each member follows that member's own go-live date.

Sources: ^[1][6]

How does a connector reach your system?

Vattora connects in one of four ways; your system, not preference, decides which. Each system's page shows which one applies and its real status.

Whichever way, a connector should only read. Where a credential could also write, as an API key can, it should be used only to read. The security page explains what Vattora reads and how it is kept.

• An agent on your PC or server, for desktop and on-premises systems: a small Windows service that only calls out, so nothing on the internet can reach it.
• A cloud connection you approve, for cloud systems: you grant access inside the system itself, and nothing is installed.
• A read-only database login, for systems that keep invoices in their own database: your IT gives a login that can read and cannot write.
• A file upload, for systems without an interface: export invoices to Excel or CSV in a set template and upload them.

What changes if you switch ASP?

Your Participant Identifier is 0235 followed by your 10-digit TIN (Guidelines §3), so it identifies your business, not your provider. What has to move is the link between your system and the provider.

Without a connector, an integration built for the old provider's API or file format usually has to be rebuilt for the new one. With a connector, your system side stays as it is and only the provider side changes: the link to the new provider is built and tested in that provider's test environment before your first real invoice goes through it.

The Guidelines do not describe a separate procedure for switching ASP. Onboarding with an ASP starts in EmaraTax (Guidelines App. 1, §13.2), changes in your circumstances are updated there through the reverification or offboarding processes (§13.5), and you may appoint only one ASP for sending and receiving (§6.1). So agree the handover date, the exit terms and what happens to your stored e-invoice data with both providers before you sign, and ask them how the move is recorded in EmaraTax. The Ministry's own considerations for selecting an ASP ask about data retention (§3.2.2).

Sources: ^[1][7]

Where Vattora fits, and when you do not need it

Vattora is connector software on corner 1's side. It reads posted invoices and credit notes from your system, builds each one as a checked PINT AE e-invoice and hands it to the ASP you appointed. Vattora connects to the ASP you choose through that provider's API; each link is built and tested in the provider's test environment before your first real invoice. Each system has its real status on the systems page. If one of the four cases under When do you not need a connector? fits you, you do not need Vattora.