Understanding Business Central costs — the cost logic behind Microsoft's mid-market ERP.
Licence prices for Business Central do circulate, but they say little about actual project costs — the larger share arises during implementation through the partner. This page explains the underlying cost structure: what licence and project effort depend on, and how to build a sound budget view.
How the licence and subscription model works.
Dynamics 365 Business Central is licensed as a Microsoft subscription per user per month. The licensing logic is user-profile-based: the scope of functionality a user needs — for example whether manufacturing and service capabilities are required, or whether finance, sales, and warehousing suffice — determines the assigned licence profile. In addition, reduced access levels exist for employees who only occasionally enter documents or view information. In DACH projects, procurement usually runs through a Microsoft partner, who is also responsible for the implementation.
For budget planning this means licence costs scale largely linearly with the number of users and are comparatively transparent to calculate. What matters more is an honest assignment of user profiles — giving every employee the most comprehensive profile means permanently paying for unused functionality, while planning too tightly forces later upgrades. You should also budget for apps from the Microsoft ecosystem, which many projects use for industry-specific or supplementary capabilities.
What drives implementation effort.
Implementation is fundamentally partner-led, and the partner's services are typically the largest cost block. Common effort drivers are the scope of processes to be covered (especially manufacturing and intercompany scenarios), data migration from the legacy system, interfaces to surrounding systems, custom extensions, and the question of whether industry apps cover the need or bespoke development is required.
In terms of project size, Business Central implementations typically sit at the lower to middle range of classic mid-market ERP projects — well below Dynamics 365 Finance & Operations or SAP S/4HANA, and in many constellations below NetSuite as well. The timeline depends primarily on process scope, the number of entities, legacy data quality, and the availability of the internal team; implementations close to the standard can, in our experience, be delivered within manageable timeframes.
The ongoing cost logic.
Ongoing costs consist of the monthly Microsoft subscription, possibly subscriptions for supplementary apps, and usually a support or care agreement with the partner. Microsoft applies two major releases per year centrally to the cloud environment; your own extensions are technically designed to be update-stable through the extension model, but still require regular review and maintenance. In the cloud variant, your own infrastructure is not needed — internal effort shifts towards application support and continuous improvement.
What a five-year view should cover.
- Plan user profiles realistically over time: growth, role changes, and the share of occasional users drive ongoing licence costs more than the initial setup.
- Include app subscriptions from the Microsoft ecosystem — industry and add-on apps are recurring items that are often missing from initial calculations.
- Treat partner support and the maintenance of your own extensions across release cycles as a fixed annual item.
- Assess synergies with existing Microsoft agreements: current Microsoft 365 estates, Power Platform usage, and Azure services all influence the overall picture.
When it typically gets more expensive
- Complex manufacturing or multi-entity requirements that go beyond industry apps and demand extensive custom extensions.
- Numerous interfaces to surrounding systems and historically grown data sets whose cleansing and migration is laborious.
- Attempting to replicate legacy processes unchanged instead of using the Business Central standard.
When the project typically stays lean
- Processes close to the standard in trade or services that the functional scope covers without major adaptation.
- An existing Microsoft environment in which users, IT, and data flows integrate without additional effort.
- A clearly limited initial scope with few entities, deferring special topics to later phases.
Alternatives typically evaluated in this constellation.
Oracle NetSuite
Typically evaluated when international multi-entity structures are central from the outset and an integrated cloud suite with vendor-managed operations is preferred.
Odoo
Considered when a modular, flexible approach with a smaller entry footprint is sought and no close Microsoft alignment exists.
Xentral
Frequently evaluated when a trade- or e-commerce-driven company prefers a deliberately lean functional scope over a classic ERP suite.
Neutral editorial assessment of the cost structure — deliberately without price figures, as conditions are negotiated individually and change continuously. No paid placements; our approach is documented in the methodology.
What would a suitable ERP mean in your constellation?
Our structured selection advisory captures your situation systematically and shows which systems realistically belong on your shortlist.