Dynamics 365 is not one product, it is a set of applications that share a data platform. That is its strength and the reason most implementations go wrong: teams buy modules against a wish list rather than a process, and end up with a configured system nobody recognises. We start from the process and work back to the licence. Where the group runs a legal entity in each market, that includes the localisation, statutory reporting and indirect tax work per country, which is usually the larger half of the programme and the half most plans underestimate.
What we do on it
Fit-gap against your processes, configuration, integration and a go-live with the data proven correct. Phased so the first release lands in months rather than at the end of a programme. Where there is a legal entity per market, that phasing is a country rollout: one global template, then country waves with the localisation and statutory work sequenced ahead of each go-live.
Dynamics GP, NAV and AX onto Dynamics 365, with the balances reconciled to source, the cutover rehearsed and a rollback that has been tested.
Custom development that survives platform updates, and integrations to the systems either side with error handling, contract tests and an owner.
Estates that were implemented years ago against a business that has since changed. We find what is being worked around and fix the configuration rather than the symptom.
A named team that knows your configuration, absorbing platform updates and moving an enhancement backlog rather than only closing tickets.
Copilot Studio agents and Power Automate flows scoped to tasks with a measurable completion signal, evaluated before they reach a user.
Products covered
General ledger, accounts payable and receivable, fixed assets, budgeting, intercompany, multi-entity and multi-currency, revenue recognition and financial reporting. A legal entity per market, each with its own statutory chart mapped back to the group chart, consolidation and elimination on the platform rather than in a spreadsheet after the close.
Country configuration: tax codes and determination, document numbering, local invoice formats, banking and payment files, language and local audit file requirements. Built on the regulatory layer the platform ships, meaning Globalization Studio, electronic reporting formats, the electronic invoicing service where a jurisdiction mandates one, and the tax calculation service. Statutory accounts come out of the ledger rather than being rebuilt outside it.
Inventory, warehousing, procurement, production control, master planning, quality and third-party logistics integration.
The mid-market option covering finance, sales, purchasing, inventory and projects in one application, where Finance and Operations would be more platform than the business needs.
Opportunity and pipeline management, quoting, forecasting, and the integration back to the ledger so pipeline and revenue reconcile.
Case management, queues, entitlements and service-level agreements, knowledge base, and omnichannel where it earns its cost.
Work order management, scheduling against real technician capacity, mobile execution, inventory on vans, and the loop back into billing.
Project accounting, resourcing, time and expense, and revenue recognition for businesses that sell work rather than product.
The shared data layer underneath the applications, and the assistants on top of it, governed rather than switched on by default.
Reconciliation, intercompany and consolidation done by people rather than by the system. Usually a Finance engagement, sometimes just a configuration fix nobody has had time to make.
GP, NAV or AX, with customisations nobody documented. This starts as an assessment: what is load-bearing, what is habit, and what each path costs.
Pipeline in one system, ledger in another, and a monthly argument. A Sales and Finance integration with the system of record agreed field by field.
The most common one. We map what people actually do, including the spreadsheets, and reconfigure around that rather than retraining them into a design that never fit.
Each new market arrives with its own statutory chart, its own tax treatment and its own filing calendar, and the group ends up running a different close in every country. This is a template and rollout question rather than a module question: what the group standardises, what a country is genuinely allowed to vary, and in what order the countries move.
A tax authority deadline is the one date in this work that does not move. It usually forces a decision: bring that country forward in the rollout, or meet the obligation on the system it is still running while the programme catches up. We will tell you which is cheaper rather than letting the mandate set the whole plan.
It comes down to transaction volume, entity count and how much process complexity you genuinely need rather than have inherited. Business Central covers far more than teams expect and costs less to run. We will tell you if the cheaper option is the right one, and that call is part of the fit-gap rather than a sales conversation.
You should be in a test environment with your own data inside six weeks on most engagements. If a plan has you waiting until month five to see the system, that is a plan built around the supplier rather than around you.
Yes, and we do it regularly. It starts with a review of what has been built, because we will not commit to a date on a configuration we have not read. That review is scoped separately and you keep it whatever you decide.
No, and you usually should not. Modules are independent enough to phase. We scope the one carrying the most pain, prove it, then extend once your team has absorbed the change rather than during it.
Yes. That is a programme rather than a project: a global template designed once in a reference entity, then deployed in country waves, each wave carrying its own localisation, statutory reporting, indirect tax and e-invoicing work. The shape runs 9 to 18 months depending on the number of countries and how much local variation survives design, and it needs programme governance from day one rather than added when the second country starts arguing.
This is the real decision on these programmes and it is worth being blunt about it. A local requirement backed by statute is not negotiable and goes into the template as a country variant. A local requirement backed by habit is negotiable and belongs on the register with a price against it, decided by a sponsor rather than by whoever argues longest. The failure mode is a group that never wrote down that rule, and ends up with a country build in each market held together by a shared logo.
Microsoft ships localisations and regulatory features for a substantial list of countries, and it is a moving list, so we confirm coverage for your specific markets during scoping rather than assuming it. Where a market is not covered, or the shipped localisation stops short of what your local auditors expect, the gap is closed with electronic reporting configuration, a partner localisation, or a scoped extension. Which of those it is gets costed before it is committed to, and if a market is genuinely awkward you will hear that from us early.
No. We build the system that produces the numbers, the statutory reports and the digital reporting files, and we test them against a real filing period with your people. The tax position, the transfer pricing policy and the filings themselves stay with your tax advisers and local accountants. We work alongside them, and we would rather say that plainly than let a procurement pack assume otherwise.
Bring the process that is breaking and we will tell you what it takes to fix it, including when the answer is not a project.
