Questions and answers
All 78 of them, including the ones where the answer is no. Nothing here is gated and nothing needs a call first.
By platform
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.
It covers more than most teams expect and less than the licensing implies. We use it where it holds and drop to custom code where staying on the platform would create a maintenance problem later. That line is a judgement call and we will show you our reasoning rather than just the conclusion.
Environments separated, data loss prevention policies applied, a Dataverse schema with owners, and a documented route for someone in the business to get an app reviewed rather than blocked. It is a process your team runs, not a service you buy from us indefinitely.
Not on usage data alone. Low-usage apps get an owner check and a notice period, because the monthly regulatory report is a low-usage app. Nothing goes without sign-off.
Sometimes not, and we will say so before you buy rather than after. It earns its place where there is a repetitive task with a clear completion signal. Where there is not, it produces impressive demonstrations and no change to anyone's week.
Usually not. Most orgs need a subset removed, a subset rebuilt and the rest left alone. The review tells you which is which with a cost against each, so a rebuild becomes a decision you make on evidence rather than a quote you accept on instinct.
Yes. We take a defined workstream with its own scope and release train so there is no ambiguity about who owns what, and no two teams deploying into the same org on the same afternoon.
It depends on the field, and pretending otherwise is how these integrations fail. Customer master, pricing, order status and revenue often sit in different places. We agree it field by field and write it down before anyone builds.
Regularly. A Dynamics ledger with a Salesforce front end is a normal estate, and the interesting work is usually in the seam between them rather than in either platform on its own.
Whichever costs less over five years, and plenty of estates are best left with SAP as the ledger and something lighter in front of it. The assessment gives you both numbers rather than the one that suits us.
Yes, as well as at the integration and data layer between them and a Dynamics or Salesforce core. If a piece of work needs a skill we do not hold, we will say so rather than learn it on your budget.
We do not take vendor commission on selections, and the analysis is yours whatever you decide, including if you decide to keep what you have. That last outcome is more common than the industry admits.
Yes. It is a normal shape for us: a defined workstream, our own delivery lead, and reporting into your programme rather than around it.
If the existing warehouse works, we build on it. Migrating a functioning platform to a newer one is a cost looking for a justification, and we would rather spend your budget on the semantic model, which is where the value actually is.
Almost always because the same word means two things in two places. Revenue, customer and order each have several definitions in most organisations. The fix is a semantic model with those definitions agreed and signed off once, not another reconciliation spreadsheet.
Less of it, but not none. Even a fully hosted application has environments, releases and a deployment path, and those decide how much a change hurts.
Your team, with the documentation and training to do it, or ours under managed services. We are explicit about which before the work starts rather than discovering it at handover.
By service line
Yes, and for a first engagement we usually recommend it. The modules are independent enough to phase, so we scope the one carrying the most pain, prove it, then extend once your team has absorbed the change.
It depends on transaction volume, entity count and how much process complexity you genuinely need rather than have inherited. That call is part of the fit-gap, and we will tell you if the cheaper option is the right one.
We keep what you need live and archive the rest somewhere queryable. Carrying ten years of history into a new ledger is usually a cost with no reader, so we decide that deliberately rather than by default.
Yes, and it is a different shape of engagement rather than a bigger version of a single-entity project. It runs as a programme: a global template built once in a reference entity, then country waves, each carrying its own localisation, statutory reporting, indirect tax and e-invoicing work. There is a walkthrough of how that runs month by month on this site, including where it gets difficult.
With a rule agreed before the first country, not by argument during the third. A variation with a statutory basis is not negotiable and goes into the template as a country variant. A variation without one goes on the register with a cost, and a named sponsor decides. Groups that skip that rule end up with a separate build per market and a consolidation that still runs on a spreadsheet, which is the outcome the programme was meant to remove.
They are treated as dated obligations from month one, not as a reporting task at the end. Regimes differ: some require an invoice to be cleared by the tax authority before it can be issued, others require structured reporting after the fact, and several markets are moving between the two. The rules and the dates change often enough that we confirm the current position per market during scoping rather than working from a matrix, and we build and test the connection against the authority's test facility where one is published.
We configure tax determination, tax codes and the returns or digital reporting files the system produces, then prove them against a real filing period with your finance team. The tax position itself, the transfer pricing policy and the filings stay with your tax advisers and local accountants. We implement what they decide. Any supplier who offers you both should be asked which one they are actually accountable for.
Typically 9 to 18 months, and the range is honest rather than cautious. What moves it is the number of countries, how much local variation survives design, and whether local finance teams are available to test their own market. The first country is deliberately slow because it finds everything the template got wrong. If waves three and four are not materially faster than the first, the template is not working and that should be said out loud rather than absorbed into the plan.
No. Cleaning it in the old system usually means doing it twice. We profile it, agree the rules, and resolve duplicates and gaps as part of the migration, with the results reviewed before cutover.
Yes, and it often has to. We build a two-way sync with a clear system of record for each field, so the two do not fight over the same data.
Adoption is a scope item, not an afterthought. Configuration follows the process people already run, and we track usage after go-live so the gaps surface while we are still there.
Usually not. Most orgs need a subset removed, a subset rebuilt and the rest left alone. The review tells you which is which, with the cost of each, before anyone commits to a rebuild.
Yes. We take a defined workstream with its own scope and release train, so there is no ambiguity over who owns what.
Sometimes not, and we will say so. It earns its place where there is a repetitive task with a clear completion signal. Where there is not, it produces demos rather than results.
Whichever costs less over five years. Plenty of estates are best left with SAP as the ledger and something lighter in front of it. The assessment gives you both numbers.
Yes. We deliver on Oracle, PeopleSoft and Workday directly, as well as at the integration and data layer between them and a Dynamics or Salesforce core. If a piece of work needs a skill we do not hold, we will say so rather than learn it on your budget.
Two to three weeks for a scoped assessment covering current state, options and costs. Longer selections are usually longer because of internal alignment, not analysis.
Often not where the vendor slide says. A two-tier shape, with the group ledger on one platform and lighter entities on another, is a legitimate answer and sometimes the cheaper one over five years. What it costs you is the consolidation and intercompany layer, which then has to be designed rather than assumed. The assessment gives you both paths with the numbers, including the option of leaving a market where it already is.
The obligations do not change at all. They belong to the legal entity and the jurisdiction, not to the software. What changes is where the work is done and how the output reaches the group. We map the obligations per market first, then decide which system produces each one, because doing it the other way round is how a group discovers in a filing period that nothing owns a return.
With an inventory. Most estates have a small number of apps carrying real load and a long tail that can be retired. We separate them, then govern what is left.
Power Platform covers more than most teams expect and less than the licensing suggests. We use it where it holds, and drop to custom code where it would otherwise become a maintenance problem.
Environments separated, data loss prevention policies applied, a Dataverse schema with owners, and a route for a citizen developer to get an app reviewed rather than blocked.
Almost always because the same word means two things in two places. The fix is a semantic model with agreed definitions, signed off once, rather than another reconciliation spreadsheet.
If the existing warehouse works, we build on it. Migrating a functioning platform to a newer one is a cost looking for a justification.
Your team, with the documentation and training to do it, or ours under managed services. We are explicit about which before the work starts.
An evaluation suite built before the agent ships, with a baseline you can hold it to. Anything without a measurable completion signal is not a use case we would take.
Retrieval runs against your records under your access rules, so an agent cannot surface something the user could not already see. Data handling is documented as part of delivery.
Production. A pilot with no evaluation, no monitoring and no cost per task is a demonstration, and most of them never leave the workshop.
Nearly always environment drift: production has configuration or data that test does not. We make the environments match, then make the difference visible when it reappears.
Less of it, but not none. Even a fully hosted platform has environments, releases and a deployment path that decides how much a change hurts.
Yes. We would rather extend the pipeline your team already knows than replace it with one only we understand.
Yes, and it is common. We catalogue what exists, document the contracts, and replace the ones that cannot be maintained. Working ones are left alone.
An upstream release changing a field, and nobody noticing until month end. Contract tests and alerting turn that into a ticket on the day rather than a discovery weeks later.
Whichever the estate justifies. Middleware earns its cost past a certain number of interfaces, and below it adds a layer for no return.
At least one full rehearsal with reconciliation, usually two. A cutover nobody has practised is a cutover with an unknown duration.
Urgent enough to plan now and not urgent enough to rush. The risk is that an unsupported platform gives you no room when something does break, and a rushed migration produces a ledger nobody trusts.
Rarely worth it. We keep what is needed live, archive the rest somewhere queryable, and make that a decision rather than an accident.
No. A helpdesk resets passwords. This is the team that knows why your intercompany posting is configured the way it is, and can change it safely.
Agreed with you and written into the contract, by severity. We would rather commit to something we can hold than publish a number that means nothing at three in the morning.
Yes, after a handover review. We need to understand the configuration before we can promise anything about it, and that review is scoped separately.
The analysis takes days. Resolving it takes longer, because the conflicts are usually there for an operational reason. We give you the conflicts, the business impact of each fix, and a sequence.
No. This is your platform configuration and evidence position. It makes those audits far less painful, but it is not the audit itself.
Your team. We build the process and the reporting so a review is a scheduled task rather than a project, and hand it over.
A contractor is a person you manage. A pod is a team with a lead, a review process and a handover obligation, and it does not leave a knowledge gap when it ends.
Yes. We would rather you did. A pod that your delivery lead has not met is one your delivery lead will not trust.
Then say so, and we will tell you honestly whether a pod adds anything. Sometimes it does not, and a single senior engineer under your lead is the right answer.
Multi-country
Both, and they are not the same thing. Multi-entity is a structural and consolidation problem inside one operating model. Multi-country adds a legal entity per market with its own statutory reporting, its own tax treatment, its own localisation and its own filing calendar, and that part is usually the larger half of the programme. We deliver the localisation and statutory reporting work, not only the entity structure around it.
Governance, mainly. A project has a scope, a team and a date. A programme has a template, a rule for deviating from it, a change log, a wave sequence and a deployment lead per country. Run as a long project, the third country renegotiates the design the first one agreed, and by the fifth there is no design left. The difference shows up in month seven, not month one, which is why it has to be set up in month one.
Typically 9 to 18 months for a phased country rollout, driven by the number of markets and how much local variation survives design. The team is larger than a single-country project: a programme lead, a solution architect, a template lead, functional consultants across the workstreams, a localisation and statutory reporting lead, data engineers, integration development, and a deployment lead per wave. There is a month-by-month walkthrough of the shape on this site.
The obligations belong to the jurisdiction, so the question is really whether the platform's shipped localisation reaches far enough for your specific markets, and how far the gap is if it does not. That is confirmed market by market during scoping rather than promised up front, because coverage and mandates both move. Where a market is genuinely awkward, you will hear that from us early and with a cost attached, which is more useful than a map of flags.
Two options, and the answer is whichever is cheaper rather than whichever suits the plan. Either that country moves up the sequence so it goes live compliant, or the obligation is met on the system it is still running while the programme catches up. Both are legitimate. What is not legitimate is planning a cutover against a tax authority date and hoping the two meet, because that date is the one thing in the programme that will not move for you.
Sometimes, and it is a sponsorship question rather than a technical one. What we can do is make the choice explicit: here is the local variation, here is what it costs to carry it in the template, here is whether it has a statutory basis. Groups that make that visible tend to standardise more than they expected. Groups that leave it to workshop negotiation standardise less than they planned and pay for the difference.
Yes, and on a rollout of this shape it is common. We take a defined workstream with its own scope and release train, or we hold the template and the group build while local partners handle specific markets, provided the template governance is agreed and one party owns it. Ambiguity over who owns the template is the failure mode there, so it is settled in writing before a wave starts.
Rarely on configuration. They go wrong when statutory reporting is left to a phase at the end, when nobody wrote down the rule for local deviation, when the template freezes and the live countries drift away from it, and when local finance teams are asked to sign off a market they were never given time to test. Those four are predictable, which is why the plan addresses them by month two rather than treating them as bad luck later.
The one everybody asks
A scoped assessment runs $8k to $15k over two to three weeks, and you keep the output whether or not we do the work. A single country project runs $40k to $200k depending on the platform and the scope. A multi-country programme starts at $350k and runs 9 to 18 months in country waves. An embedded pod runs $14k to $28k a month on a three-month minimum.
Because a number produced before anyone has read your configuration is designed to win the work rather than to survive it. The figures above are there so you can rule us in or out before spending a meeting on it, which is a different thing from a quote. The quote comes after the fit-gap, and it comes with the working attached.
Platform licences, which you buy directly and we will help you size rather than resell. Third-party software. Your own team’s time, which on a programme is the larger cost and the one most often left out of a business case.
Send it. If the answer is useful to other people it ends up on this page, and if the answer is no you will get that too.
