The close takes longer than before the implementation
Almost always an architecture and process finding rather than a system fault — account logic, reconciliation process and ownership.
Dynamics 365 Business Central: our primary Microsoft ERP practice.
Business Central is the Microsoft ERP we actively advise on, architect, implement, migrate, optimise and support long term. It is built for mid-market organisations that want a clean, scalable core — and for whom finance is not the area that gets mapped somehow at the end.
The standard
“A Business Central project has succeeded when the first quarter-end afterwards is boring. Everything else is rework that could have been avoided in the design.”
Microsoft Business Unit · Tech IQ 365 GmbH
Overview
What Business Central is built for — and what it is not.
Business Central is a complete mid-market ERP: financials, purchasing, sales, inventory, projects, light manufacturing and service on one data model, with a controlled extension model through AL and vetted ISV apps. It is deliberately not an enterprise stack — and in the mid-market that is an advantage, not a gap.
The question “does Business Central fit” can rarely be answered yes or no. The more useful question is which architecture decisions your legal, process and finance structure forces — and which of those get lost in a standard rollout. Those decisions arise with any ERP; they usually only become visible at the first close.
Where the platform plays to its strengths
- 01
Mid-market structure
From one to roughly twenty entities, a manageable number of countries, a clear group reporting line.
- 02
Product, trade and distribution
Inventory, procurement, multi-channel sales and sound cost discipline on one model.
- 03
Services and project businesses
Project structure, resources, revenue cut-off and profitability without a side system.
- 04
Light manufacturing
Bills of material, routings and production orders at a depth that suits the mid-market.
- 05
Multi-entity and intercompany
Several entities with shared reporting logic — designed cleanly rather than mapped in a spreadsheet every month.
- 06
Integration capability
CRM, commerce, payroll, payments, EDI and banking through defined interfaces instead of grown point solutions.
Where the natural limit sits
The limit does not run along a revenue figure. It runs along manufacturing and planning depth, warehouse complexity at volume, very broad statutory variety across many countries — and the question of how much extension a standard core can carry before every update becomes a project. If your structure crosses that line we say so. We then assess group-wide which architecture holds: NetSuite, SAP, another group platform — or Dynamics 365 F&O where it genuinely fits. For a full greenfield F&O implementation we are deliberately not the delivery partner at present; our F&O motion is aimed at existing environments.
Implementation
An implementation that survives the step from design to go-live.
Most Business Central projects do not fail on the software. They fail on decisions nobody made: a chart of accounts copied rather than designed, dimensions grown rather than planned, intercompany as a process rather than an architecture, extensions without a rulebook. We reverse the order.
- 01
Discovery & target picture
Operating model, reporting requirements, legal structure, critical process chains, and the question of what has to be measurably better at the end.
- 02
Finance architecture
Chart of accounts, dimensions, entity and consolidation logic, tax, intercompany and the reporting model — designed before anything is configured.
- 03
Solution architecture & process design
End-to-end processes, roles and permissions, extension rules across AL and ISV, the integration map and the data model.
- 04
Configuration & extension
Built in the standard where the standard carries. Extension only where a decision justifies it — documented, not grown.
- 05
Data migration
Master data, open items, inventory, history and opening balances — reconciled against the legacy system, not hoped through.
- 06
Test, UAT & cutover
Test coverage along the critical process chains, a cutover plan that holds, and a defined abort point.
- 07
Hypercare & handover
Support beyond the first close, a documented handover, and a support model that exists from day one.
We invent no methodology names for this. It is the business unit's four-step method — Architect, Design, Deliver, Operate — applied to Business Central.
The usual first step is the Fit & Architecture Assessment — result immediately, no contact details. If you are further along, we go straight to the target model, the migration route or support.
Check your Business Central fit
Finance architecture
The part most proposals skip.
The chart of accounts is the one decision in the project you can barely correct in live operation without losing the comparability of your own numbers. That is why we treat it as design work — not as an import from the legacy system.
- 01
Chart of accounts & dimensions
An account model that reads group-wide, with dimensions that answer a question — rather than one dimension per special case.
- 02
Multi-entity & consolidation
Entity logic, consolidation paths and a mapping that is not rebuilt in a spreadsheet every month.
- 03
Intercompany
IC as architecture with defined counter-postings and clear ownership rules — not as two-sided manual entry.
- 04
Tax & statutory requirements
VAT logic, local requirements, and the question of what belongs at entity level and what at group level.
- 05
Close & period control
Close calendar, accruals, provisions and reconciliation logic as a process, not as an act of heroism.
- 06
Reporting foundation
Report structure directly on the ERP data model. Power BI is analysis after that — not a substitute for a sound foundation.
- 07
Banking & payments
Payment runs, statement processing and reconciliation as a defined process with four-eyes logic.
- 08
Fixed assets
Asset classes, depreciation rules and parallel valuation where HGB and IFRS diverge.
Migration
NAV → Business Central: the decision before the project.
The question is not whether you migrate. The question is whether you take your NAV with you or build your target picture. Both are legitimate — but they are two different projects, with different costs, different durations and very different outcomes in year three.
Lift-and-shift
The existing model is technically lifted into Business Central. Faster, cheaper, lower change risk — and you carry the grown decisions along, including the ones nobody can justify any more.
Redesign
The core is designed again: chart of accounts, dimensions, processes, extension landscape. More effort and real change management — but afterwards the system is what you would build today.
What has to be decided either way
- 01
Which of the existing customisations are still justified on their merits — and which are habit?
- 02
How much of that does the Business Central standard now cover anyway?
- 03
Which history is migrated, which is archived — and how is it kept accessible for an audit?
- 04
How are opening balances reconciled, and against which source?
- 05
Which interfaces stay, which disappear, which are built new?
- 06
Which permission and role logic is carried over — and which was never clean in the first place?
We answer these questions before the migration project, not inside it. The Business Central Fit & Architecture Assessment is the usual entry point — it works for NAV incumbents exactly as it does for a fresh selection.
Existing Business Central
When Business Central runs — but not the way it should.
A substantial part of our Business Central work does not start from zero. The system is in place, the implementation was years ago, and the symptoms are familiar: the close takes too long, nobody fully trusts the reporting, the extension landscape has grown, and support answers tickets instead of removing causes.
Reporting is rebuilt in Excel alongside
A sign that the report structure does not sit on the ERP data model but is reconstructed next to it.
Every update turns into a project
Extensions without a rulebook. The question is what can go back into the standard and what stays a deliberate add-on.
Permissions have grown historically
Roles nobody can explain any more are an audit risk and an operational risk at the same time.
The partner rotates consultants
With an ERP, subject-matter continuity is not a comfort but a precondition for decisions that hold.
Senior support & application management
We deliberately do not build the Business Central practice as an implementation business that leaves after go-live. Ongoing operation is its own promise: incidents, release and update support, change management and functional development — with senior counterparts who know your architecture, rather than with a queue.
On response times, service levels and package cuts we deliberately state nothing here while they are not released. What we can commit to, we settle in conversation — not on a website.
Licensing & subscription
Microsoft Cloud Solution Provider — as part of the lifecycle.
JPS-iQ is a Microsoft Cloud Solution Provider. That means: if you want it, we can handle licensing and subscription for Business Central and the associated Microsoft services within the same lifecycle in which we own the architecture and the implementation — instead of running it through a third contracting party.
What it explicitly does not mean is that we are a licensing house. Our business is architecture, finance and delivery. You can just as well source your licences elsewhere — it changes nothing about our work, and we do not make the advisory conditional on it.
Microsoft Cloud Solution Provider and Microsoft Solutions Partner are two different things. CSP status concerns the commercial lifecycle. We make statements about partner designations, competency or specialisation areas only where they are individually evidenced and verifiable.
- 01
One contracting path fewer
Licence, implementation and support do not have to run through three parties if you do not want them to.
- 02
Sizing along the architecture
Which licence types you need follows from the role and process model — not from a standard assumption.
- 03
A clean switch
An existing CSP agreement can be transferred in an orderly way at renewal. We tell you when that makes sense and when it does not.
- 04
Separate from the advisory budget
Licence cost and advisory work stay separately stated. No cross-subsidy model.
Evidence
What is evidenced for this practice.
We show no Business Central customer figures here, because we have no released, attributable Business Central reference. Passing off results from mandates on other platforms as Business Central evidence would be the easier route — and the wrong one.
Microsoft Cloud Solution Provider
Licensing and subscription capability within the customer lifecycle — a verified status.
Finance architecture as design work
Chart of accounts, multibook, multi-entity, intercompany and dual GAAP are designed before anything is configured.
Senior-led
Architecture and finance ownership at senior level throughout — from target architecture to beyond the first close.
Platform-neutral
Eight business units in one group. Recommending against Business Central is structurally possible.
German finance depth
HGB and IFRS in parallel, statutory requirements, VAT and consolidation as a core competence.
Substance in the open
Our Business Central and finance-architecture positions are published as articles anyone can read.
As soon as a Business Central reference is released — client, starting position, outcome and timeframe, anonymised if necessary — it goes exactly here.
Good fit
Does this match your situation?
Good fit
- You are facing an ERP decision or a NAV migration and do not want to raise finance requirements only at the end.
- Your structure is mid-market: several entities, a manageable number of countries, a clear group reporting line.
- You want a standard core with deliberate extension — not a system that has to prove itself again with every update.
- You already run Business Central and are looking for a more senior partner for optimisation and ongoing support.
- You expect an honest answer, including one that goes against Business Central.
Weaker fit
- You are looking for a pure licence source with no advisory content — we are the wrong firm for that.
- You want a standard implementation in a single entity with no finance depth — there are cheaper partners for that, and we say so.
- Your manufacturing, planning or warehouse complexity is visibly beyond what a mid-market core carries.
- You need a full greenfield Dynamics 365 F&O implementation — we deliberately do not offer that at present.
- The decision is already made and it is only about the cheapest implementer.
Common questions
What usually gets asked before the first call.
How long does a Business Central implementation take?
That depends on legal structure, process complexity, migration load and integration scope. A single entity with clean master data and few interfaces is a very different thing from a group with intercompany, several countries and a grown NAV behind it. We name a duration once the target picture is settled — before that it would be a guess.
What does it cost?
For the same reason, the same applies. The usual entry point is the Fit & Architecture Assessment: it shows which architecture decisions your structure forces. On that basis a scope can be quantified that still holds in month three.
Do you take on projects another partner started?
Yes. We join running Business Central projects and take over existing environments. In both cases we start with a sober assessment rather than a restart proposal — a restart is the most expensive of all options and rarely the right one.
How do you keep extensions under control?
Through a rulebook rather than case-by-case decisions: what the standard covers stays in the standard. Extensions run through AL or vetted ISV apps, are justified and documented, and every extension has a named business owner. That is the difference between a system you can update and one you fear.
How does Business Central relate to JPS FinanceOS?
Business Central is the system of record — it posts the transaction. JPS FinanceOS is our own, ERP-neutral product and sits above it as a control and action layer, for when the finance organisation runs on Excel, bank portals and email despite a clean ERP. FinanceOS is not a Business Central add-on, and Business Central is not a precondition for FinanceOS. The Business Central path in FinanceOS is on the roadmap and is not available today.
And if Business Central turns out not to fit?
Then we say so and show the alternatives — NetSuite, SAP or another group platform, where appropriate through our platform-neutral entry point OPCON. That is not a marketing line: the alternatives exist as sister business units, so we do not need to sell you Microsoft.
Contact · Business Central
Evaluating, implementing, migrating or running Business Central better?
The usual first step is the Fit & Architecture Assessment — result immediately, no contact details. If you are further along, we go straight to the target model, the migration route or support.