Multi-country and localisation
Multi-entity and multi-currency are the easy half. The half that decides the programme is country by country: a legal entity per market, its own statutory reporting, its own tax treatment, its own localisation and its own filing calendar. This is the work we do on that, what it costs you in sequence and governance, and where we stop.
What the work covers
None of these is optional in a market that trades in its own name. What varies is how much of each the group standardises, and that is a decision rather than a discovery.
Each market that trades in its own name is its own entity, with its own statutory chart, its own reporting currency, its own numbering and its own filing calendar. The design question is how much of that sits on the group chart and how much is a local mapping on top of it. Get this wrong and every later problem, from consolidation to tax, inherits it.
The real decision on these programmes. One template designed once, then a rule for what a country may vary, on what grounds, approved by whom. Without that rule written down before the first country, a rollout becomes a set of country builds sharing a logo, and the group pays for the same work several times.
Local statutory accounts, local audit files and the regulatory returns each jurisdiction expects, produced from the ledger rather than rebuilt beside it in a spreadsheet. Reconciled to the books your local accountants sign, and tested against a real reporting period rather than demonstrated on sample data.
Tax codes and determination, document numbering, local invoice and credit note layouts, banking and payment file formats, withholding, rounding rules, language and local archiving requirements. Individually small, collectively the reason a country go-live slips.
Tax determination configured so the rate and treatment come from the transaction rather than from a person, registrations and place-of-supply handling across borders, and the periodic return produced by the system. Cross-border movements, reverse charge and intra-group supplies are where determination usually breaks, so those are tested first.
Regimes fall into a few shapes: an invoice cleared by the tax authority before it can be issued, structured reporting submitted after the fact, network-based exchange between trading parties, and periodic audit files. Which shape applies, and when, changes often enough that we confirm the current position per market during scoping rather than working from a stored matrix.
Group consolidation running on the platform, with intercompany balances agreed and eliminations posted rather than assembled after the close. Currency translation and the treatment of differences designed once, so the group close stops being a reconciliation exercise with a deadline attached.
Your advisers set the policy. We make the system express it: intercompany pricing on the transaction, the intercompany invoicing flow, the postings that support the documentation, and the reporting that lets someone show the policy was actually applied. We implement a policy. We do not write one.
Which country goes first and why, which follow in which wave, and what forces a country up the order: a dated mandate, a system going out of support, an acquisition, a reporting deadline. The sequence is an argued decision with the reasoning written down, not the order the countries happened to be listed in.
The decision underneath it
Almost every multi-country programme is really an argument about one question: how much does the group standardise, and how much does each market keep. It is usually treated as a technical question and settled late, country by country, by whoever pushes hardest in the workshop. That is the single most reliable way to overrun one of these programmes.
It is worth being precise about what is actually being argued, because two very different things get put in the same bucket. Some local requirements exist because a statute, a tax authority or a local auditor says so. Those are not preferences and there is no point negotiating them: they go into the template as a country variant and the cost is what it is. Other local requirements exist because a market has always done it that way, often because an old system could not do it any other way. Those are preferences, and a group that treats them as obligations ends up funding nine versions of the same process.
So the useful output of the design phase is not a requirements document. It is a rule: what a country may vary, on what evidence, and who approves it. A statutory citation approves itself. Anything else needs a named sponsor willing to own the cost, on a register, with a number against it. That rule takes a fortnight to agree and it is the difference between a template and a shared logo.
The second thing that decides these programmes is order. Countries do not queue by size or by enthusiasm. They queue by what forces them: a dated e-invoicing or digital reporting obligation, a system leaving support, an acquisition that has to be consolidated, a reporting deadline the group has already committed to externally. The first country in the sequence is deliberately the slowest, because it is the one that finds everything the template got wrong while there is still time to fix it centrally rather than nine times.
The honest measure of whether any of this worked is not the first go-live. It is whether the third and fourth waves are materially faster than the first. If they are not, the template is not doing its job, and that is worth saying out loud in a steering meeting rather than absorbing quietly into the plan.
How a country moves
The first country is deliberately slow, because it finds everything the template got wrong. Every country after it runs this cycle, and the cycle is supposed to get shorter.
The country's finance and operations teams walk their process against the template rather than against a blank page. Everything that does not fit is written down as either an obligation or a preference, because those are handled completely differently and confusing the two is what makes these programmes expensive.
Tax determination, document numbering, local formats, banking files and the statutory reports are configured for the market, on the regulatory layer the platform ships wherever that reaches. Where it does not reach, the gap is closed with reporting configuration or a scoped extension, costed before it is committed to.
The country's own finance team tests its own market, on its own data, including a full period. A country signed off without its controller in the room is a country that finds its reporting problem later, in a filing period, with a deadline on it.
Balances and open items come across and are reconciled to the local source, then the cutover is rehearsed against a timed runbook. The runbook is the same one the previous wave used, which is the point of running countries in waves at all.
Anything the country forced into the core is folded back, versioned and recorded, so the next wave starts from a better template rather than from a longer list of exceptions. This step is the one most often skipped, and skipping it is why wave six costs what wave one did.
Where we stop
Worth stating before procurement has to ask. On a multi-country programme the boundary between the system and the tax position is where responsibility quietly goes missing.
We configure determination, build the returns and the digital reporting files, and prove them against a filing period. The tax position itself stays with your advisers. A supplier offering both should be asked which one they are accountable for.
We make the system produce them from the ledger and reconcile them to the local books. Your local accountants and auditors do what they do. We work alongside them and expect them in the room during the first country.
Shipped localisation coverage is broad and it moves. We confirm the position for your specific markets during scoping, and where a market is thin we say so and cost the gap rather than discovering it in the wave.
A country count is not a scope. Until the statutory, tax and e-invoicing obligations per market are on paper with their dates, any number for a multi-country rollout is a number designed to win the work.
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.
Tell us the markets, the entities and any dated mandate you are already carrying, and we will come back with a sequence, the parts that worry us, and what would have to be true for the first country to go live.
