Choosing an Accredited Service Provider Without Regretting It
· 12 min read · Faceela
You are about to sign a contract with a company that will stand between your sales invoices and your customers, permanently.
Not between your invoices and the tax authority — that framing makes it sound like a filing agent, and filing agents are interchangeable. Under the five-corner model, your Accredited Service Provider carries the document itself. If they are down, your invoices are not late in some administrative sense. They have not been issued. Your customer has not received them. Nothing is in anyone's payables.
That is a different class of dependency from the ones you are used to buying, and most businesses are about to select it the way they select a courier: three quotes, pick the middle one, sign in October.
This is about how to do it properly, in the time available.
What the deadline actually obliges you to do
From the Ministry of Finance's e-invoicing programme: if your annual revenue is AED 50 million or more, you must appoint an Accredited Service Provider by 30 October 2026 and go live on 1 January 2027. Below that threshold, you appoint by 31 March 2027 and go live on 1 July 2027. Government entities go live on 1 October 2027. Voluntary participation opens on 1 July 2026. Non-compliance carries a penalty of AED 5,000 per month.
The appointment deadline moved once already — it was 31 July 2026 before it became 30 October 2026 — and the go-live date did not move with it. This is the single most misread fact in the whole programme. The extension gave you three more months to sign a contract. It gave you nothing at all for the work that follows the signature, which is where the real duration is.
So the sequence is not "appoint, then relax". It is: appoint early enough that the integration has a chance, and treat the deadline as the last acceptable date rather than the target.
What an ASP does, and what it emphatically does not do
An accredited provider validates your outbound document against the published specification, transmits it across the network to your customer's provider, reports the required data to the authority, returns a status, and receives inbound documents addressed to you.
It does not:
- Decide your tax treatment. Nothing in the provider's stack knows whether this particular supply to this particular customer is zero-rated. That determination happens in your ERP, before the document exists.
- Fix your master data. A missing or malformed tax registration number produces a rejection, not a repair.
- Own your process. If an invoice is rejected, the provider will tell you. Somebody in your building has to care.
- Make you compliant. It makes transmission possible. Compliance is the sum of what your system asserts and whether those assertions are true.
Hold that boundary firmly in your head during every sales meeting, because the sales meeting will blur it. The demo will show a beautiful invoice sailing through validation, and the implied promise is that the provider has solved e-invoicing for you. They have solved the transport. What the mandate actually requires of your ERP is a longer list, and almost all of it stays on your side of the boundary.
Accreditation is a floor, not a ranking
Every provider you talk to will lead with the fact that they are accredited. Of course they will. It is also the least differentiating thing about them, because accreditation is a threshold test: it establishes that a provider meets the Ministry's requirements to operate on the network. It does not establish that they will be good to work with, that they understand your industry, that they will still exist in four years, or that their support desk answers on a Friday.
Treat the accredited list the way you would treat a licence to trade. Necessary, and the beginning of the evaluation rather than the end of it.
The market has three rough shapes, and each fails differently.
Global e-invoicing networks. Deep in the standard, present in many jurisdictions, well capitalised. Their weakness is local: your account is small, your industry-specific billing quirk is not on any roadmap, and your escalation path ends in a different time zone.
Regional tax and compliance software firms. Closer to the ground, more likely to understand the local flavour of the problem. Their weakness is depth of engineering and the strain of scaling through a mandated onboarding wave in which every customer wants the same three months.
ERP vendors and their partners bundling a provider. The most convenient, because the connector is somebody else's problem and the commercial relationship is one you already have. The weakness is coupling: your transmission capability is now tied to your ERP relationship, and if you change one you may be forced to change the other.
None of these is the right answer. The point of naming them is that you should know which one you are buying and price its specific weakness into the contract.
What to ask, and why
Most e-invoicing evaluations are a feature checklist. Feature checklists are useless here, because every accredited provider does the same core thing by definition. The useful questions are about behaviour under stress, and about who owns what when something breaks. This is the same discipline as any serious ERP selection exercise in this market: stop asking whether the software can do it and start asking what happens on the day it does not.
When my document fails validation, what exactly do I receive? Ask for a real error payload from a real rejection, not a description of one. Is it a code and a human-readable message, or is it a stack trace? Does it identify the field? Can a finance clerk act on it without calling anyone? You will be reading these messages every week for the rest of the company's life, and their quality is a bigger day-to-day cost than the subscription fee.
How do statuses come back to my ERP? Push or poll. Webhook or file drop. What happens to a status if my system is down when it arrives — is it queued and retried, or is it lost? A provider who cannot answer this crisply has never had a customer with an ERP that goes down, which means either they are new or their customers are small.
Show me your sandbox, today. Not a demo environment they will provision after signature. A working test endpoint your integrator can hit next week. The gap between contract and go-live is short, and a provider whose test environment lags their production one will eat that gap entirely.
What is your onboarding queue like in the last quarter of 2026? Every business above the threshold is contracting in the same window. Ask how many implementations they can start in a month, how many consultants they have in the country, and what happens if you sign in the last fortnight before the deadline. The honest answer to this question tells you more about the firm than anything on their website.
Who has done this in my industry? Not a logo wall. A specific answer about how they handled the awkward document — a payment certificate with retention deducted, a consolidated monthly invoice against a framework agreement, a rebate credit that spans two tax periods. If your billing is unusual, and it probably is in at least one place, that unusual thing is where the integration will fail.
What do you do about entities? If you run several legal entities, this question is bigger than it appears. Each registered entity needs its own identity on the network, and the answer changes depending on where those entities sit. Anyone operating across free zone and mainland structures should get this settled explicitly and in writing before signature, not discovered during configuration.
What happens to my archive if I leave? Answered below, because it belongs in the contract rather than in a conversation.
What the contract must say
A subscription agreement written for a software tool is not adequate for a service that sits inside your revenue path. Six things need to be in the document, and the negotiating leverage to get them exists only before you sign.
Availability, defined against issuance rather than uptime. A generic uptime percentage measured monthly can hide a four-hour outage on the last working day of a quarter, which is precisely when it hurts. Push for a commitment expressed in terms of documents accepted for transmission within a stated window, and for a credit regime that is not merely a refund of a small monthly fee.
A named escalation path with a human being at the end. Support tiers, response times by severity, and the specific route for "our invoicing has stopped". If the only channel is a ticket portal, ask what happens at 9pm on the 31st.
Data ownership and export, stated plainly. Your invoice data is yours. The contract should say so, and should say in what format and within what period you can get all of it out, including the transmitted artefacts and their status history — not just a report of them.
Archive continuity beyond termination. You are obliged to retain and produce documents for the statutory period, which is far longer than any subscription you are about to sign. Establish now, in writing, who holds the transmitted document, how it is retrieved, and what happens to it if the relationship ends or the provider is acquired. This is the clause that will matter most and gets the least attention, and it is the one that decides whether an FTA audit is a document retrieval exercise or an archaeology project.
Portability, in operational terms. Switching providers under a network model should be possible. The contract should not make it expensive or slow: no lock-in on your network identity, no punitive exit fee, a defined migration cooperation obligation, and a notice period you can actually live with.
Liability that is not laughably capped. Most software contracts cap liability at fees paid. For a service whose failure stops your invoicing, negotiate for something proportionate to the exposure, or at minimum ensure the cap does not apply to breaches of confidentiality and data handling. You may not win this. Ask anyway, and note who refuses.
Where the ERP boundary actually falls
Here is the question that decides whether your project is calm or chaotic: who owns the mapping?
A structured invoice is a set of fields. Your ERP has fields. Between them sits a translation — this field goes there, this code becomes that code, this condition means the tax category is such-and-such. That translation is the integration, and it is where every ambiguity in your business surfaces.
Three parties can own it. The provider, as part of onboarding. Your ERP partner, as part of the connector. Or you. In practice it is always shared, and the failures happen in the seams: the provider assumes the ERP will send a clean tax category, the ERP partner assumes the provider will derive it, and the field arrives empty in production.
Insist on a single written mapping document, agreed by all three parties before build starts, that names for every required field the source in your ERP and the person accountable for it being populated. It is a boring artefact. It is also the difference between a four-week integration and a four-month one, and the absence of exactly this kind of agreed-upon detail is the most reliable predictor of an ERP project going wrong.
Two more boundary questions worth settling explicitly:
Where does validation happen first? Ideally your ERP refuses to post an invoice that the network would reject, so the error appears in front of the person creating the document rather than in a queue an hour later. That means duplicating some of the provider's validation rules locally. It is worth the duplication.
Who watches the queue? Somebody has to look, daily, at the list of documents that left and did not arrive. Name that person before go-live and give them a screen. If the answer is "the system will email us", you do not have a control.
The three ways this goes wrong
You choose late and take whoever has capacity. Signing in the final fortnight before 30 October 2026 leaves you at the back of every onboarding queue, integrating over the year-end close, going live on 1 January. Every day earlier is disproportionately valuable, because it buys position in a queue rather than just calendar time.
You buy the connector and skip the process. The integration works. Invoices transmit. And then it turns out that a third of your invoices were historically issued after a manual adjustment, that credits were done by voiding and reissuing, and that nobody has ever owned the tax code decision. The connector is not the problem. The habits it exposes are, and habits take longer to change than software.
You treat it as an IT procurement. The person who signs the ASP contract should not be the person who buys laptops. This decision touches revenue recognition, customer relationships, audit exposure and the finance calendar. Put it where those things live. It belongs to the same conversation as deciding how the business will run before choosing the platform that runs it, and it should sit with a finance sponsor and an operational owner, not with a procurement matrix.
The shortest useful version
Appoint early, not on the deadline. Read the accreditation as a licence rather than a recommendation. Interrogate failure behaviour, not features. Get the archive and exit clauses right, because those are the ones you will need years after everyone who negotiated the contract has left. And write the field mapping down before anybody starts building.
The published guidance sets the dates and the network model; it does not tell you which provider suits a business that bills the way yours bills. That part is a judgement, and it is one worth making deliberately rather than in the last week of October.
If you would rather approach the whole thing as a sequenced piece of work than a scramble, how we structure this kind of engagement is written down and is the same whether the deadline is regulatory or self-imposed.