What Business Central Actually Costs a UAE Company
You have a per-user price off a Microsoft web page and a proposal that looks nothing like it. Neither is wrong. Here is the real cost shape built out of its parts, which parts nobody is able to publish, and the arithmetic to run on the figures you were actually quoted.
· 11 min read · Written by Faceela Research & Editorial Team
You have a number. It came off a Microsoft web page, it is per user per month, and it is the only figure in this decision anybody has been willing to publish. Then the partner's proposal lands and does not resemble that number at all.
Neither document is wrong. They measure different things, and nobody has told you which parts of the real cost can be published and which cannot. This page separates the two. It ends in arithmetic rather than a total, because a total built without your entity count, your user split and your gap list is a guess with a decimal point in it.
Business Central sits inside a family of Microsoft products, and the family is where most Dynamics quotations begin to confuse people. How the Dynamics 365 products fit together for a buyer in this market is the wider map; this page is only about money.
The figures that are actually published
Start where verification is possible, because there is exactly one place in this purchase where it is. The vendor publishes list prices on a public page, and that page is the only document in the exercise that neither you nor a partner controls. Everything else you will be shown is an estimate of your company produced by somebody with a commercial interest in the answer. A published price is also the only figure that cannot be quietly revised between the meeting and the proposal, which is what makes it the reference point for every question you are about to ask. Read it yourself rather than off a slide, and write down the date you read it, because what is on it is a snapshot rather than a permanent truth.
Read on 9 September 2026, Microsoft's Business Central pricing page shows Business Central Essentials at USD 80.00 per user per month paid yearly, Business Central Premium at USD 110.00 per user per month paid yearly, and Team Members at USD 8.00 per user per month paid yearly. No minimum seat count is stated anywhere on that page.
Underneath sits a footnote most buyers scroll past, and for a UAE buyer it is the most consequential sentence there. Quoted exactly as Microsoft writes it: "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."
Read that as an operator rather than a lawyer. Microsoft is saying, in its own words, that the number you copied into your model may not be the list price in your country, and that the binding figure appears at the point of purchase. So the gap between the page and the proposal is not automatically the partner's margin. Ask what it is made of.
The parts that are on no page at all
The subscription is the only line that can be priced without knowing anything about your business. Every other line depends on facts nobody has looked at yet.
| Line | Who can publish it | What sizes it |
|---|---|---|
| Subscription | Microsoft, with its country caveat | User count, and each user's tier |
| Implementation | Nobody, before a diagnosis | Processes, entities, exceptions, decision speed |
| Data migration | Nobody, before somebody opens the data | Its state, not its volume |
| Localisation | Whoever maintains it, who may not be Microsoft | A country version, or an app doing that job |
| Integration | Partly the far end, absent from your meeting | Who owns each system you keep |
| Training | The partner, if you make them scope it | Roles, languages, turnover after go-live |
| Support | The partner | What was built, not who uses it |
The economics of the middle five lines are not a Microsoft matter. The same forces set the number in any mid-market project, which is the subject of where the money actually goes in a UAE implementation. What is specific here is the ratio: the subscription is large enough that buyers treat it as the decision, and services are still the bigger half of year one. A proposal where the licence dominates and the services line is modest is telling you services have not been scoped, not that the project is small.
Integration is priced by a party who is not in the room. Your bank's file format has a version. Your customs broker has a portal rather than an interface. Your payroll provider charges for changes at its own rate and schedule. One line reading "integration with existing systems" is not a scope; it is a placeholder for an argument you will have in month four. For every interface, write down who owns the far end, whether they have done this before, and what they charge. If any of the three is unknown, that line belongs in the budget as a range.
Localisation is a question about who, not whether. Microsoft describes the boundary between core functionality and local functionality in its own Business Central localisation documentation, and that boundary is the commercial point. Some markets are covered by a Microsoft-maintained country version; elsewhere the local behaviour arrives as an app built on the worldwide base by somebody else. Those arrangements have different costs, different renewal terms and different failure modes, and a proposal saying "UAE localisation included" has not told you which one you are buying. Ask in writing who maintains it, what it costs annually, and what happens if that publisher stops.
The tier boundary is a cost event, not a feature
The published page carries separate figures because capability sits behind a boundary. Essentials at USD 80.00 and Premium at USD 110.00 are not two ways of buying the same thing. They are two sides of a line, and the moment one requirement crosses it the arithmetic changes for full users rather than for one user.
What makes that expensive is when the crossing is discovered. Tier decisions are taken in design workshops, months after the budget was approved, by people solving a functional problem who do not know they are pricing it too.
There is a second boundary further out, and buyers meet it the moment somebody says the requirement sounds like a bigger product. That is a different licence entirely. Read on the same day, Microsoft's Dynamics 365 Finance pricing page shows Dynamics 365 Finance at USD 210.00 per user per month paid yearly and Finance Premium at USD 300.00 per user per month paid yearly, and states no minimum seat count and no minimum purchase. Set those beside the Business Central figures and the size of the step is visible without anybody computing anything for you.
The Team Members figure belongs in the same conversation, as a discipline rather than as a saving. It is published, it exists, and the work of deciding who is a full user and who is not happens in the same workshops that set the tier. Model your user list from the process design — walk each process and count who touches a record — rather than from the org chart, and settle it before a renewal teaches you the answer. Whether your requirements genuinely sit on the far side of the larger step is a scoping argument rather than a pricing one, and it is the subject of the honest test for which of the two products you actually need.
Marketplace apps, and why most five-year models omit them
This is the line that separates a model that survives from one that does not. An app from the marketplace is priced by its publisher, frequently per user, and it sits on top of the subscription rather than inside it. Four requirements closed with four apps is four per-user charges, four contracts, four renewal dates coinciding neither with each other nor with your subscription, and four publishers whose commercial health you have quietly made your own problem.
Each carries an obligation you did not sign for. Business Central online moves on Microsoft's update calendar rather than yours, and every app has to be certified by its publisher against each wave. A publisher who is slow, distracted or gone is a blocker on an update you cannot decline.
So build the app list as a register before contract: publisher, pricing basis, renewal date, and the certification record against recent waves. That register prices your third year, and almost nobody builds it, because at proposal stage each app reads as a small line item rather than a permanent dependency. If the localisation turns out to be an app rather than a country version it belongs on the register too, and it is the row that matters most — which UAE requirements the standard product does not cover is the list to check the answer against.
What renews, and what a renewal can do
Year one is the number your committee will argue about and the year that decides least. The recurring shape is where the decision lives.
Four things renew, on four calendars. The subscription renews annually. Each marketplace app renews on its publisher's terms. Support renews on the partner's. The localisation arrangement, if it is an app, renews on somebody else's schedule again. Nothing synchronises them for you.
A renewal can then do three things a first-year quotation cannot show. It can apply an uplift, stated as a percentage, an index, or "then-current list price", which is not a number at all. It can bill the users your design created rather than the users your business case assumed, because roles multiply the moment people see the system. And it can arrive after a new-business discount has quietly expired, so what reads as a modest annual rise is a rise plus an unwinding.
None of that is opportunism. It is a design decision taken in month three arriving as an invoice in month fourteen, by which point nobody connects the two events. The way to make it visible is to build the recurring lines before you sign, which is the subject of building the four years after go-live before you commit to year one. Negotiate the mechanism now: cap the uplift for the initial term, price the addition of a block of users and of one entity in writing, and secure the right to reduce the user count at renewal rather than only to raise it. Most contracts are silent on reduction, and silence favours whoever issues the invoice.
The arithmetic, which is yours to run
We are not going to publish a total, and you should distrust any page that does. What follows is the shape, written so you can run it on the figures you were quoted.
Start with the subscription. Full users at their tier, plus Team Members at theirs, priced at the figure in the proposal rather than the figure on the web page, with the difference explained in writing. Multiply by twelve. That is your annual licence base, and the only line you can forecast confidently.
Then express every other line against that base as a multiple, because multiples survive currency, country and time in a way absolute figures do not. Implementation as a multiple of the base. Migration as its own multiple, sized after somebody has opened your data. The app stack as an addition to the per-user figure, so it compounds with user growth as the licence does. Support as an annual figure with its exclusions listed, not as a percentage of a licence it has no real relationship to. Then the internal owner who holds the configuration after the consultants leave — a salary, or a real fraction of one, and in no proposal ever written.
The ERP cost estimator runs that arithmetic in the same units, returning implementation, migration and first-year support as multiples of whatever annual licence figure you have been given rather than as a price we invented. It is vendor-neutral by construction, which is what lets a proposal built on one licensing theory be set beside a proposal built on another without either being flattered.
What to put in writing before anybody quotes
Five things, and all five are answerable before contract. The entity list, including the dormant company somebody forgot. The user list split by tier, modelled from process design rather than headcount. The requirements that sit on the higher tier, named. The app register, with publisher, pricing basis and renewal date on every row. And the exclusions list, read before the inclusions list, because that is where the boundary of a fixed price actually sits.
Then make every bidder price the same four years on the same page, with the assumption behind each cell stated. That one act does more for cost control than any negotiation on the per-user rate, and it costs a fortnight of somebody's attention rather than a consultant. If the other proposal on the desk is an Odoo one, be careful about setting the two side by side line by line — the structural comparison of the two products explains why only the totals compare, and why the cheaper licence is not the cheaper system.
Two questions extract most of what a proposal is hiding, and neither is about price. Ask what the assumed volume is behind each services line: how many master records, how many interfaces, how many approval levels, how many printed documents. An estimate whose assumptions cannot be produced was a feeling. Then ask what the bidder would remove from the scope to reduce the figure by a fifth. A good answer names specific things and says what you lose. A discount on identical scope tells you what the original number contained.
The uncomfortable corollary is the same here as on any product. A proper diagnosis costs money and it is the cheapest money in the project, because it is the only thing that turns a published figure and a proposal figure into one number you can defend in front of a board. If you would rather have the assumptions checked before you commit, that written diagnosis is where an ERP implementation starts with us.
Every figure above was read from Microsoft's own pricing pages on 9 September 2026, and Microsoft's own footnote says the published figure may not be your list price. Check the pages on the day you build your model.