Your e-invoicing provider is accredited. Your regulator will still have questions

With the 30 October deadline to appoint an e-invoicing provider approaching, UAE banks and other regulated firms risk mistaking Ministry of Finance accreditation for regulatory sign-off

Here’s a question I’ve taken to asking bank risk and compliance leaders. If the Central Bank asked you tomorrow where your e-invoicing data is processed, backed up, monitored and accessed, could you answer?

Most can tell me where the main database sits. Far fewer know where the backups go, which country the disaster recovery site is in, or where their provider’s support engineers are logging in from. That gap matters more than most boards realise, and time is short.

UAE businesses with annual revenue of Dh50 million or more have until October 30 to appoint an Accredited Service Provider (ASP) under the Ministry of Finance’s e-invoicing programme, and they go live on January 1, 2027. Most banks fall into that group. Exempt and zero-rated financial services sit outside the mandate, but fee income that attracts VAT and the invoices banks receive from their suppliers do not.

Under that kind of deadline pressure, it’s tempting to treat the Ministry’s accreditation as the end of due diligence. For a regulated institution, that would be a mistake.

Accreditation answers a different question

To be fair to the process, accreditation is no rubber stamp. Providers must be Peppol-certified, hold ISO 27001 and ISO 22301 certification, encrypt data at rest and in transit, and show at least two years of experience running e-invoicing systems. It tells you a provider can operate securely within the UAE’s e-invoicing network.

What it can’t tell you is whether that provider’s set-up fits your obligations to the Central Bank of the UAE, the DFSA, the FSRA or VARA. The Ministry’s own criteria recognise this, requiring ASPs to meet each client’s regulatory requirements on data hosting, storage, archiving and residency. Checking that they actually do is the client’s job, and no supplier can take that responsibility off your hands.

For banks, the rules are specific. The Central Bank’s outsourcing regulation requires a bank’s master system of record, including confidential customer data, to be kept in the UAE, and customer data can’t be shared outside the country without Central Bank approval and the customer’s written consent. Many other regulated, government and government-owned businesses effectively follow the same rules. Invoices carry customer names, tax registration numbers and transaction values. If a supervisor asks how those rules were applied to your e-invoicing provider, “they’re accredited” won’t be enough.

Data residency is only the start

The line I hear most in vendor meetings at the moment is “we support UAE data residency”. It sounds reassuring, and it’s often true as far as it goes. The main database may well sit in a UAE cloud region.

But an invoice doesn’t live in one place. Before it reaches that database, it passes through an integration layer connected to the bank’s ERP. It’s validated, sent through a Peppol access point to the customer’s provider and reported to the Federal Tax Authority. Along the way it’s logged, backed up, copied to a disaster recovery site and, now and then, looked at by a support engineer. Each of those steps happens somewhere, and not always in the UAE.

That’s the difference between data residency, which is about where data is stored, and data sovereignty, which covers everywhere it travels, who can reach it and under whose laws. Regulators care about the second.

None of this means an offshore component is automatically a breach. Many can be managed with the right approvals and controls. The real risk is not knowing they’re there.

Questions worth asking now

I’d encourage any regulated firm to put a few plain questions to its provider and get the answers in writing. Where is the integration layer hosted, and where do failed invoices wait to be retried? Where are the backups and the disaster recovery site? Who runs the Peppol access point, and from where? Which teams can reach production systems, and from which countries? Who controls the encryption keys? Which subcontractors are involved, and what data do they see? And if you leave, where is your archive and how do you get it back?

Then ask for evidence: architecture diagrams, data flow maps, a subprocessor register and security certificates whose scope actually covers the service you’re buying. A good provider will hand these over without fuss. One that hesitates is telling you something.

These aren’t questions for the IT team alone. They go to outsourcing risk, operational resilience and customer confidentiality, which is why they belong in front of risk committees and, where the exposure is material, the board.

Already signed? Ask anyway

Many banks will have chosen a provider already. The same questions apply. There’s still time before January 1 to close gaps and update outsourcing documentation. That’s far harder to do once invoices are flowing.

I should declare an interest: my company is one of the accredited providers that offers complete data sovereignty. I’d still rather buyers asked harder questions. Providers that have done this properly will have the answers ready, and banks deserve to know which ones do before go-live, not after.

When a regulator comes asking, “our provider is accredited” will only be the start of the conversation. The institutions that come through it well will be the ones that can show, with evidence, where their data goes.

– Jay Riche is the co-founder and CEO of Daribatech.