Business Central in the UAE: Ask Who Maintains Your Localisation

Ask the partner selling you Dynamics 365 Business Central one question in writing, before the pricing conversation: who maintains the UAE localisation, and what happens to your system if they stop?

Almost nobody asks it, because a demonstration cannot show it. Two Business Central systems — one running a Microsoft-maintained country version, one running a partner-built app on the worldwide base — put the same screen in front of you, with the same tax codes and the same invoice coming off the printer. What separates them is not in the software. It is a publisher's name, a renewal date, a certification history and a commercial position nobody has shown you.

Start with what Microsoft publishes about itself

Microsoft's documentation on local functionality and localisation strategy opens by describing a combined localisation strategy inclusive of both Microsoft-led and partner-led models. It then gives a table of the countries where Microsoft provides the regulatory compliance and other local functionality, grouped into Europe, North America and Asia Pacific, each row linking to that country's own local functionality article. And for everywhere else it says this: the product is also available in other markets through localisation apps, and if a Microsoft partner has developed one for your country or region, you can find it in the marketplace.

Read the table rather than the summary. The United Arab Emirates is not in it.

That is not an accusation and it is not a product defect. Microsoft has drawn a boundary and published where it falls, which is more than most vendors do about anything. What it means for you is exact: in this market, the component that makes Business Central behave like a UAE system sits on the partner-led side of Microsoft's own line, and therefore has a publisher who is not Microsoft. Everything else on this page follows from that single sentence, and it is the sentence our guide to Dynamics 365 in the UAE can only afford a paragraph for.

The two products that look identical in the room

A Microsoft-maintained country version is part of the application. It moves when the application moves. Nobody has to decide to keep it current, nobody bills you separately for it, and no third party's commercial health sits between you and a working tax code.

A partner-built localisation app is a different kind of object with the same appearance. It is software published by a company, licensed on its own terms, versioned on its own schedule, and made compatible with each new release by a decision somebody at that company takes — or does not take. It has a support desk that is not Microsoft's, a renewal that is not your subscription's, and an owner who can be acquired, can change strategy, or can conclude that a market this size no longer earns the effort.

Both configure a chart of accounts. Both produce a tax return. Both demonstrate beautifully. The difference lives entirely in the following five years — the period a buyer is least equipped to examine and most exposed to.

Why the ownership question decides the next five years

Business Central online updates on a published cadence, and Microsoft documents the version relationships carefully — the supported upgrade paths between releases set out which release waves can be reached from which, and note that not all minor updates between two releases are compatible with each other.

That update mechanism is the strongest structural argument for the product. It has one dependency, and it is the one nobody prices: every extension attached to your tenant has to be compatible with the release you are moving to. Microsoft's own code is Microsoft's problem. A partner's localisation app is that partner's problem, and their problem becomes yours the moment the wave arrives.

So the failure mode is not a bug. It is a schedule. If the publisher of your localisation has not certified against the next release, your estate is blocked — not because anything broke, but because the component carrying your tax logic has not been declared ready and you cannot proceed without it. We concede the upgrade argument to Microsoft in an Odoo partner's comparison of the two products, and this is the asterisk that belongs on it.

The second failure mode is slower and worse. A publisher leaving the market does not switch anything off. Your system keeps working exactly as it did, through the next regulatory change and the one after that, producing output that is correct against a rule set that has moved. Nothing alerts you. There is no error state for a tax treatment that used to be right. The first evidence arrives from an auditor or a customer, and by then the thing needs replacing rather than updating.

What you are actually buying, and what it costs

The commercial shape of the purchase gives you a cheap way to test whether anybody in the room has understood the question. Start from the published figures and look for what is missing from them.

Microsoft lists prices on its own Business Central pricing page: Essentials at USD 80.00 per user per month paid yearly, Premium at USD 110.00, and Team Members at USD 8.00. That page carries its own qualification, verbatim: "Prices shown are for informational purposes only and may not be reflective of actual list price due to currency, country, and regional variant factors. Your actual price will be reflected at checkout."

Now look for the localisation app on that page. It is not there, because it is not Microsoft's product. A marketplace localisation is priced by its publisher, on its own terms, renewed on its own date, and it appears nowhere in the figures a Business Central proposal is usually built from. So the licence line you were quoted is not the licence line you will pay, and the gap is not a negotiating position. It is a second contract with a different company, carrying its own escalation clause and its own termination terms, and modelling it honestly is most of the work in what Business Central actually costs a UAE company.

What a UAE localisation actually has to carry

Here is where most articles start listing tax rules. This one will not: obligations here change by amendment, and a page stating a rate, a threshold or a deadline from memory will be wrong at some point without anybody noticing. So what follows is the shape of each obligation rather than a feature list. Confirm the current position for every one with the authority that owns it — the Federal Tax Authority, the Ministry of Finance, or the free zone authority that licensed the entity — and get your tax adviser's answer in writing before you accept a vendor's.

Tax determination and the return. The system decides the treatment of a transaction from facts recorded at the moment it happens, at line level rather than header level, and produces the return as a report rather than a monthly reconstruction. That requirement is independent of the product, and it holds whichever one you buy.

The content of the document you issue. Whatever the current rules require a tax invoice and a credit note to contain and to state, in whatever language, is a published requirement the localisation either meets or does not. Ask which requirement each field on the template exists to satisfy.

Electronic invoicing. Whatever the programme currently requires of the document, of the parties who transmit it, and of the dates by which you must be capable, comes from the authority running it and has moved before.

Payroll and wage transmission. A fixed-format file, defined by somebody other than you, transmitted through a party with no interest in your month end. Either the localisation produces it correctly or a person rebuilds it every month.

Record retention and retrieval. The obligation is to produce a named document, in the form it was issued, years later — a period that outlives software versions and vendor contracts, which makes it an architecture question rather than a backup policy.

Entity, establishment and zone status. Licensing, indirect tax and corporate tax each draw their own boundaries and they do not sit on top of each other. The system needs classification on the master record, not an assumption in somebody's head.

Against each category the question is never "does the app do this", because every app says yes. It is who decides what "this" means when the rule changes, and how long they take. Note also that one of those categories sits substantially outside the ERP, which is why choosing the provider that will carry your documents is a separate decision on separate criteria that no localisation app can answer for.

Arabic is a separate axis, and it fails on its own

Tax correctness and Arabic correctness are unrelated properties: a localisation can be entirely right about treatment and still produce documents an Arabic-reading customer cannot use. Three things travel under the word Arabic and they fail independently. The interface arrives with the software and is what every demonstration shows. The data is what your company put in — product names, account names, unit names — and none of it arrives translated. The document is what leaves the building, drawn by a different engine from the one drawing your screen.

The printed document is where the defects live, and they are a class no server-side test can find. Bidirectional text puts a right-to-left script and left-to-right numbers on the same line, and the characters with no direction of their own — the space, the slash, the hyphen, the bracket — resolve according to what surrounds them. So a fraction, a ratio or a part number written with a slash can appear reversed inside an Arabic paragraph while the value stored in the database is perfectly correct. Every automated test passes, because a test reads the value rather than the page, and what Arabic support actually means separates the three failures cleanly enough to hold across any product.

The instrument that detects this is a person looking at a printed invoice. Not a screenshot in a slide deck, and not the screen. Ask for the artefact: an Arabic document, for a real customer record whose language is set to Arabic, containing a product code with a slash and a number in it, printed from the version you are being sold. It takes ten minutes and it tests the interface, the data, the template and the rendering engine at once.

The questions to put in writing before contract

This is the part worth pasting into an email. Send it, ask for written answers, and treat evasion on any one of them as the answer. If you are moving an existing Dynamics estate, send it once per extension rather than once per project — the inventory of local modifications that comes out of a migration from Dynamics NAV to Business Central is exactly the list to run it against.

1. Who publishes the UAE localisation you are proposing? Give the legal entity name, not a brand.
2. Is it a Microsoft-maintained country version or a marketplace app on the worldwide base? Point me at Microsoft's own documentation for the answer.
3. Is the publisher you, an affiliate of yours, or a third party? If a third party, what happens to that relationship if we change implementation partner?
4. What has it been certified against, release wave by release wave, for the past three years? Give dates, and the interval between each Microsoft release and the app being declared compatible.
5. What is the contractual position if it is not certified in time for a release we are scheduled onto? Who carries the cost, and who talks to Microsoft?
6. What is the licence and renewal structure, separately from the Business Central subscription, and what governs price increases?
7. If the publisher exits, is acquired, or discontinues the app, what happens to our system — and is that written down anywhere we can rely on?
8. Who is contractually responsible for updating it when a UAE regulatory requirement changes: you, the publisher, or us?
9. What is the lead time between a published rule change and the app supporting it? Name a change that has already happened and tell me how long it took.
10. Which parts of our compliance obligations does the app not cover at all, and what fills those gaps?

Question nine separates the vendors who have lived through a change from the ones who have read about one: there is no correct number, only whether they can name a real instance and account for it. Question ten never gets asked and is worth the most, which is a pattern repeated across the questions that separate a real vendor from a good presenter.

What a good answer sounds like

Not "yes, it is fully compliant". That describes a feature list rather than your data, and it is the most common sentence in this market.

A good answer names the publisher, admits the app is on the partner-led side of Microsoft's boundary, produces a certification history with dates on it, and is specific about which obligations it does not touch. A partner who answers that way has read the same documentation you have and decided to compete on candour. A weak answer treats the question as hostile, and that reaction is itself the finding: either they do not know who publishes the component their proposal depends on, or they know and would rather you did not.

None of this argues against Business Central. It is a serious product with a better answer to upgrade economics than most of its competitors, and frequently the right purchase here. The argument is narrower and applies to any product with a partner-led localisation: know who owns the piece that makes it local, before that piece owns you.

Whether that dependency is acceptable is a scoping decision, and it belongs in the diagnosis rather than in a renewal conversation three years later. Getting the gaps named and priced before contract is the point of how we scope an ERP implementation, and the discipline is the same whichever vendor's logo ends up on the system.

Source note

The combined localisation strategy, the list of countries where Microsoft provides local functionality, and the statement that other markets are served through partner localisation apps are from Microsoft's localisation documentation. The release-wave upgrade paths and the note on minor-update compatibility are from its supported upgrade paths documentation. The Essentials, Premium and Team Members figures and the quoted pricing qualification are from its Business Central pricing page. All three were read on 9 September 2026; prices and product boundaries change, so confirm them at the source. No UAE tax rate, threshold or deadline appears anywhere on this page, by design — confirm every obligation with the authority that owns it before designing around it.