Business Central or Finance and Supply Chain: choosing on complexity, not size

Why the question is harder than it looks

Most comparisons of Dynamics 365 Business Central and Dynamics 365 Finance and Supply Chain start with company size. You will see a user count or a turnover band presented as the dividing line. It is a convenient rule and it is frequently wrong, because Microsoft does not licence either product by the size of the business. It licences them by the functionality a named user needs.

We have seen small businesses with genuine multi-entity, multi-currency and regulated manufacturing requirements that Business Central would have to be extended heavily to meet. We have also seen large organisations running a straightforward finance and distribution model that Business Central handles cleanly, where Finance and Supply Chain would have added implementation cost and administrative weight for capability nobody was going to use.

The useful question is not how big you are. It is how complex the thing you operate actually is, and how much of that complexity is permanent rather than a symptom of a process nobody has fixed.

The test we work through

There are six areas where the two products genuinely diverge. If your answers cluster on the right of each pair, Finance and Supply Chain is likely to be the honest answer. If they cluster on the left, Business Central usually is.

• Legal entity structure: a handful of companies with simple intercompany posting, or many entities with consolidation, elimination and statutory reporting obligations in several jurisdictions.
• Manufacturing model: assembly and light production, or multi-site production with detailed capacity planning, subcontracting and route-level costing.
• Warehousing: straightforward stock locations, or advanced warehouse management with wave and load handling, directed put-away and multiple picking strategies.
• Volume and concurrency: transaction volumes a mid-market finance team recognises, or continuous high-volume posting where batch performance is itself a design constraint.
• Regulatory load: standard UK statutory obligations, or industry regulation and multi-country compliance that has to be evidenced rather than asserted.
• Rate of structural change: a stable operating model, or frequent acquisition and reorganisation where the ERP has to absorb new entities regularly.

One clear answer on the right of this list matters more than five on the left. Complexity does not average out. A single genuine advanced-warehouse requirement is enough to change the recommendation.

What this does to cost

Licensing is the visible difference and the least important one. Business Central and Finance and Supply Chain sit at different price points per user per month, and Microsoft publishes both. The number that decides the business case is implementation and ongoing change, and that is driven by scope, data quality and how much of the process you are prepared to standardise.

Choosing the heavier platform to buy optionality is a common and expensive mistake. Capability you do not configure is capability you still have to govern, test and upgrade around. Choosing the lighter platform and then rebuilding missing capability through extensions is the same mistake in reverse: the licence looks cheaper and the estate becomes a bespoke product that only one partner understands.

Our position is that the platform should be the smallest one that meets the permanent requirement. Anything beyond that should have to justify itself explicitly.

Separating real complexity from process debt

A large share of the complexity described in requirements workshops is not a property of the business. It is accumulated workaround: a spreadsheet that exists because a previous system could not do something, a manual reconciliation that survives because nobody has been given time to remove it, a bespoke report that encodes a rule nobody can now explain.

Carrying that into a platform decision inflates the requirement and pushes organisations toward heavier products than they need. Before we recommend either ERP, we separate three categories: complexity the market imposes on you, complexity you have chosen and would defend commercially, and complexity you inherited and would remove if asked directly.

Only the first two belong in the platform decision. The third belongs on a list of things to fix, and it is usually cheaper to fix it than to licence around it.

What each wrong answer looks like later

Under-specifying shows up in year two. Month-end takes longer than it did before, because consolidation is being done outside the system. Stock accuracy plateaus because the warehouse process the business actually runs cannot be represented. Extensions accumulate, and each one makes the next update slower to test.

Over-specifying shows up earlier, during implementation. Configuration decisions take longer because there are more ways to do everything. Testing scope grows. The internal team needed to run the platform is larger and more specialist than the organisation planned for, and adoption suffers because users are given an interface built for a more complex operation than theirs.

Both are recoverable. Neither is cheap. The diagnosis costs a fraction of either.

How we run the decision

We work through the six areas above with the people who own the processes, not only with IT. Each requirement is recorded as permanent, negotiable or inherited. Where an answer is genuinely uncertain, we say so and design the next step to resolve it rather than guessing in the business case.

The output is a recommendation with the reasoning attached, so the decision can be challenged by a board rather than accepted on trust. If the honest answer is that a fixed-scope accelerated route fits, we say that. If it is that the requirement needs a full transformation programme, we say that too, including where it will be difficult.