Business Central or Finance and Operations: Which Dynamics Are You Being Sold?

The proposal on your desk says Dynamics 365. Somewhere in it there is a per-user figure, a phase plan and a go-live date, and the whole document reads as though it describes one product.

It does not. Dynamics 365 is a brand covering several separate systems, two of which are sold into the same conversations here. One is Business Central. The other is the product Microsoft's own pricing page calls Dynamics 365 Finance, and which almost every proposal, partner and consultant in the Gulf still calls Finance and Operations, or F&O, or simply AX.

They are not two editions of one system. Business Central descends from Navision. Finance and Operations descends from AX. Different origins, different implementation shape, different partner profile, different project duration, and a list price gap you can read off Microsoft's own website.

If you are earlier than this and still working out where Microsoft sits against the rest of your shortlist, the wider map is in the guide to how the Dynamics family is sold in the UAE. This page assumes you already have a Microsoft proposal in front of you and want to know which of the two products it is actually for.

What actually differs, and it is not a feature grid

Put the module lists away. Two systems that both keep a general ledger, buy stock, sell it and cost it will produce feature grids that agree on nearly every row, and the rows they disagree on get argued away in the meeting.

Four things genuinely differ, and each of them moves your budget:

1. The list price per user.
2. The size and shape of the organisation each product is built around.
3. What the implementation actually consists of.
4. How much of the project is configuration and how much is programme management.

Only the first is published. The other three have to be read out of the proposal, and the rest of this page is how to read them.

The price gap, stated from Microsoft's own pages

Microsoft publishes both. On the Business Central pricing page, Essentials is USD 80.00 per user per month paid yearly, Premium is USD 110.00, and a Team Members licence is USD 8.00. On Microsoft's Dynamics 365 Finance pricing page, Finance is USD 210.00 per user per month paid yearly and Finance Premium is USD 300.00.

Set those two lines against each other first. USD 210.00 against USD 80.00 is not a percentage difference. It is a multiple, it applies to every full user, and it recurs every year you run the system.

Two caveats, and the first is Microsoft's. Both pages carry the same footnote, word for word: "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." So a quote written in Dubai may not match the published figure, and a partner who says so is not necessarily doing anything wrong. What that footnote cannot explain away is the shape of the gap. Currency and regional factors move a price. They do not turn a multiple into a rounding difference.

The second caveat is ours. On both products the licence is the smaller half of the money, which is why comparing licence lines alone settles nothing — where the money actually goes in a Business Central deployment here is the figure that decides affordability, and the licence is one line inside it.

The minimum seat count that is not on the vendor's page

Now the part that is worth the rest of the page.

Partners in this region routinely quote a minimum seat count for Finance and Operations, and they quote it in the grammar of a rule: you cannot buy this product under a certain number of users. It usually arrives in a first call, before anybody has counted your users, and it does a great deal of work there. It disqualifies a company from one of the two products without an argument, or it quietly inflates a user count towards a threshold, and either way it fixes the budget before the requirements exist to test it.

Here is what the vendor's own pages say about it. Microsoft's Business Central pricing page states no minimum seat count anywhere on it. Microsoft's Dynamics 365 Finance pricing page states no minimum seat count and no minimum purchase anywhere on it.

That is the whole claim, and it is deliberately narrow. It is not a statement that no minimum exists in any Microsoft agreement anywhere: enterprise agreements, volume programmes and a partner's own commercial terms are not published, and nobody outside your negotiation has read yours. The claim is only this. The number you were given is not on the page it is being attributed to.

So ask, in writing, of whoever quoted it: where does this minimum come from, and in which document? Three answers are honest ones.

A term in a specific agreement. Then ask for the clause, and read which agreement it binds — Microsoft's, the partner's, or a third party's.

The partner's own commercial floor. Entirely legitimate. Below a certain size the engagement does not pay them, and a firm that says so plainly is telling you something useful about itself. It also makes the figure theirs rather than the vendor's, which changes who you negotiate it with.

A rule of thumb about where the implementation stops being economic. The most likely answer and the most useful one, because it is a judgement about your organisation rather than a fact about the software, and a judgement can be argued with.

The answer that should not survive being asked twice is "Microsoft requires it". A supplier who cannot source a number they used to size your budget has told you something about how the rest of the document was assembled, and it comes from the same instinct a rehearsed demonstration is built on — the asks that break the rehearsal are in how to take control of a vendor demo script.

How to tell which one you are being proposed

Proposals are not always explicit, particularly in a first response where the partner is still deciding which product to steer you towards. Read for these five tells.

The team shape. One functional consultant, one developer and a part-time project manager is one product. A named solution architect, a data lead, a test lead, a change lead, a programme manager and a steering committee with a fortnightly cadence is the other. Count the named roles in the resourcing table and you will usually know before you reach the scope.

The vocabulary for changes. Look at the words the document uses when it describes making the system fit you. Configuration, setup and personalisation belong to one kind of project. Design documents, build cycles, release trains and a formal cutover rehearsal belong to another. That vocabulary is chosen by people who have done this before, and it leaks.

The environments. Ask how many non-production environments the price includes, who refreshes them and how often. The answer separates a consultant configuring in a sandbox from a programme with a sequence of environments somebody manages full time.

The governance line in the fee. If there is a line for programme management, project governance or a project office, read what it costs as a share of the total. That share is the most reliable tell in the document, and it is the part of the fee that has nothing to do with software.

The duration. A plan measured in weeks per phase and a plan measured in quarters describe different products, whatever the cover page says. Neither is dishonest; they are different amounts of work. What a realistic phase shape looks like, and which parts cannot be compressed at any price, is in how long an implementation really takes and what makes it longer.

Configuration, or programme management

The difference the price gap is really pointing at is not depth of functionality. It is how much of your project is somebody configuring a system and how much is somebody running a programme.

On the smaller product, most of the money goes to people who set the system up and people who move your data into it. On the larger one, a substantial share goes to people whose job is to manage the fact that several hundred decisions are being taken by dozens of people across several entities in a fixed order. That is not overhead in the pejorative sense — a change of that size requires it, and anybody who has run one knows why the test lead exists.

The error is buying the second structure for the first problem. It does not fail loudly. It costs more, takes longer and produces documents nobody reads, and it happens because the product was chosen before the scope was written.

If you are already on a Microsoft system

Many UAE companies arrive at this decision from an existing Microsoft installation, and the legacy estate often decides more than the evaluation does. Microsoft publishes the upgrade paths for Business Central, and they are worth reading before you accept anybody's migration estimate. Its upgrade paths documentation shows that NAV 2015 (v8), NAV 2016 (v9), NAV 2017 (v10), NAV 2018 (v11) and Business Central October 2018 (v13) reach Business Central 2026 release wave 1 only by hopping through v14, then v25, then v28. On that path the documentation states plainly: "This path requires you convert your application from C/AL to AL."

Read that as two intermediate stops and a language conversion of everything anybody ever wrote for you. It is not an argument against moving. It is an argument against accepting a fixed price from a supplier who has not opened your objects and counted them, because the conversion is proportional to what was written and nobody can size it from a demonstration.

Note the asymmetry in what has just been quoted, too. That is a published path for one of these two products. If you are sitting on AX and being offered Finance and Operations, ask for the equivalent Microsoft document for your version, by URL, and read it yourself before you accept a number. A migration estimate that cannot be traced to a published path is a hope with a decimal point in it. On the Business Central side, the honest version of the exercise is set out in what the move from NAV to Business Central actually involves.

There is a second reason to make a supplier show you the path rather than describe it. A migration proposal is the one document in the pack that has to reckon with what your company actually built over fifteen years, and a firm that will not put that reckoning on paper before contract will put it on an invoice afterwards.

Localisation, and the boundary Microsoft draws

Every ERP in this market is sold on the promise that it handles UAE tax, and every one of them handles part of that in the core product and part of it in something local — a country version, a partner-built layer, a configuration somebody did once. What decides your next five years is which obligation sits on which side of that line, who maintains the local side, and what happens the day the maintainer stops.

Microsoft describes the boundary between core functionality and local functionality in its own Business Central localisation documentation. The point here is narrower than the localisation question itself: the answer is not the same for both products, and a proposal for one does not answer for the other. Ask it per product, in writing. Ask it again about statutory reporting and again about e-invoicing, and notice which proposal answers with a document and which answers with reassurance.

The failure mode, in both directions

Both errors are made by intelligent people looking at good proposals. They differ mainly in when the bill arrives.

Buying Finance and Operations for a Business Central problem. The system works. What you bought alongside it is a governance apparatus built for an organisation you are not: a steering committee for a company that decides things in a corridor, a test manager for a scope one person holds in their head, and a per-user line at the published Finance figure rather than the published Business Central one. Nothing breaks and nothing announces itself. You simply pay it every year, which is why this error surfaces in the five-year number rather than the first-year one.

Buying Business Central for a Finance and Operations problem. This one is quiet in year one, because year one is the finance core and the finance core is fine. It surfaces in year two: the fifth legal entity, a second country's statutory reporting, an intercompany matrix that grew a dimension, a transaction volume nobody modelled, a plant. It arrives as a series of small requests, each answerable on its own with a change. The honest answer to all of them together is a different product, and by then you have a live system, a trained population and a sunk implementation behind you.

Neither error is visible in a feature grid. Both are visible in an honest count of entities, countries, users, volumes and statutory obligations, done before the shortlist rather than after it. There is also a third possibility worth naming: that neither shape fits, and what you want is functional breadth without the programme. That is a different comparison, and we have made it in an Odoo partner's own read of Business Central's licence and upgrade economics.

What to put in writing before you sign

Five questions, and they cost nothing to send.

1. Which product is this proposal for — name it, and name the licence line as Microsoft's own pricing page names it.
2. If a minimum seat count has been mentioned, what is its source document?
3. What share of this fee is programme management, and what does that role deliver?
4. How many non-production environments are included, who refreshes them, and how often?
5. For the migration: which published Microsoft upgrade path does this estimate follow, by URL?

An answer you can check is worth more than a discount. If all five come back clean, you are dealing with a firm that has done this before.

Where this leaves you

The two products are not competing for the same buyer, and most of the confusion in this market comes from one brand pretending otherwise. Count your entities, your countries, your users, your volumes and your statutory obligations first. The count usually names the product, and it does it without a demonstration and without a discount deadline.

If you want that count done independently, before either Microsoft product is priced and before anybody's minimum is quoted at you, that is how we scope an ERP implementation: the diagnosis written down first, the gaps priced before contract, and the exclusions named.