Localisation and Arabic in Dynamics 365 Business Central

At station seven your numbers became right and closed. This station asks: are they legally acceptable, and can your users read them at all?

It is the most honest station on this path and the hardest. It is not written to discourage, but because anybody learning a product must know its limits before promising them to a client.

And read this station from its source rather than from me: the table it rests on is published on the official availability and languages page (read 6 September 2026), and you should open it yourself.

The first fact: Arabic is not in the product

The official language table lists dozens of languages — and carries no Arabic row at all. No platform translation, and no application translation.

The only thing available is a language package from a partner on the app store.

In the same table a row appears described literally as having no right-to-left support, and as English only — which tells you what the platform itself does with direction, not what one particular country does.

The working rule, in the form it is said in a meeting: anybody selling you “full Arabic” has to show you the screen, not the promise.

Ask for three things by name: the package’s name, its publisher, and the date it was last updated. Anybody without all three is not selling a package; they are selling an intention.

The second fact: the tax localisation comes from a partner

The developer handles localisation itself in around twenty countries — western Europe, north America, Australia, New Zealand and India — and not one Arab country is among them.

Saudi Arabia, the UAE and Egypt are recorded in the official table as partner-localised, on the international version.

	What the developer ships	What the partner ships
The accounting engine and the cycles	Yes	—
The general tax model	Yes	—
Your country’s tax localisation	No	Yes
E-invoicing and the authority’s platform	No	Yes
The Arabic interface	No	Yes

Read the partner column straight through once: three items, every one of them legally or operationally binding, and every one of them from outside the product.

Put plainly: your legal conformity and your users’ interface are both written in another company’s code — and possibly two different companies’.

The third fact: your database is not in your country

The same table specifies the geography the database is hosted in.

A Saudi environment is hosted in the UAE geography, as are Kuwait, Qatar, Oman, Jordan, Lebanon and Yemen. Egypt is hosted in the South African geography.

For a bank, a government supplier, or any contract carrying a data-residency clause, that is a point settled before the first meeting rather than after signature.

And it is not configurable. No setting changes it, and anybody promising otherwise is promising what neither partner nor developer holds.

The fourth fact: your dependency chain moves on a schedule you did not set

Updates are mandatory, two waves a year, on a date the developer sets.

That is excellent discipline — as long as every one of your applications is compatible on the day.

In the Arabic case specifically, your dependency chain includes the tax application and the language package, both from a partner, and both of which must be ready on a schedule the partner did not set.

The remedy is a contractual clause rather than a technical setting: the partner’s commitment to both wave dates, in writing.

The three questions asked before signature

1. Who ships each of the three items, and what is it called? The language package, the tax application, and any other application the operation depends on. By name and by publisher.

2. In how many days does each of them catch up with an update wave, and with any change in the regulation? “We will update” is not a duration. A duration is written in days.

3. Who bears the penalty or the stoppage if one of them is late?

This is a sheet used in a meeting, not a training exercise. Anybody carrying it into a first meeting says what somebody who spent a year on the screens does not say.

And why the product is still worth learning

Because this is a description of limits, not a verdict of rejection.

The accounting engine in this product is strong, the price is published, the environment is free, the material is free, and the exam is available in Arabic.

And a company living inside the same developer’s office suite has bought half the training in advance — a real argument rather than a marketing one.

The skill you built on this path — accounting, the posting matrix, dimensions and financial reports — travels with you to any other system.

Limits are learned so that you promise inside them, not so that the product is abandoned.

What you actually do at this station

• Open the official table yourself, look for the Arabic row, and record what you found with its date. Do not quote this page; verify.
• Read your country’s e-invoicing regulation from the authority’s own site, with the date you read it.
• Examine the tax setup in your environment: where the tax business and tax product groups are defined, and which account their intersection produces — the same matrix understood at station three.
• Post three invoices with three tax treatments — taxable, exempt and zero-rated — and read the entry of each.
• Produce the tax report and reconcile it against a hand total of the three invoices.
• Write the three questions on one sheet and keep it.

The three commonest errors

One: assuming the Arabic interface comes with the product. It gets assumed without asking because the developer’s name is large, and discovered after signature.

Two: promising data residency inside the country. It is said in good faith, and it is untrue and admits of no customisation.

Three: leaving the update schedule out of the contract. A year passes with no consequence, then a wave arrives that the tax application does not catch — and the penalty falls on whoever was not named.

These points and their effect on the buying decision and on the price are set out in the Dynamics 365 Business Central guide.

The acceptance test for this station

1. Open the official table and write what you found about Arabic and about your country’s localisation, with the date you read it.
2. Write which geography your country’s environment is hosted in, and what that means for a contract requiring data residency.
3. Write the three questions in their contractual form.
4. Post three different tax invoices and read their entries, tracing every account back to its intersection in the matrix.
5. Write in three lines why the product remains a serious candidate despite everything on this station.

What comes next

You know the limits. The next station draws a limit of another kind: customisation and extensions — where configuration ends and code begins, and why every customisation here is measured by one question: does it survive both update waves?