To roll out a marketing spend platform across many countries, build one global template first, prove it in a single pilot market, then go live in waves of markets that share the same setup. Agree up front what is fixed globally (budget structure, approval logic, reporting, controls) and what each market sets locally (currency, tax and invoice rules, local vendors, approvers). Every market gets the same platform configured, not a separately built one.
When a global company selects a marketing spend platform, the rollout question is usually bigger than the feature list. Twenty or thirty markets mean different currencies, tax rules, fiscal calendars, languages, vendors and ways of working. A rollout that treats each market as a new project will take years and end with twenty versions of the same system.
This guide sets out what should be global and what should be local, how to sequence the waves, what a market needs before it goes live, and how to handle different planning cycles. It includes a global-versus-local worksheet and a market readiness checklist you can use as they are.
What should be global and what should be local in a multi-country rollout?
Fix everything that leadership compares across markets. Let markets set everything that is genuinely local by law or by market.
Use this: copy this worksheet and agree every row with the global programme lead, regional finance and IT before the first market starts. Anything you leave undecided gets decided differently in every market.
Element | Global (same everywhere) | Local (set per market) | Who decides |
|---|---|---|---|
Budget structure | Top levels: brand, category, channel, activity | Lower levels: local regions, cities, local activities | Global marketing finance |
Approval logic | The rules: approval by budget line, amount and type of action | The people and the limits in local currency | Global policy, local finance |
Currency | Reporting currency and exchange-rate source | Transaction currency | Group finance |
Tax and invoice rules | The checks that must run on every invoice | Which local tax fields and formats apply | Local finance |
Vendors | How vendors submit plans and invoices | The vendor list, and onboarding in the local language | Local marketing |
Reports and dashboards | The core set leadership uses to compare markets | Extra local views | Global marketing |
Controls and access | Roles, segregation of duties, auditor access | Who holds each role | Global finance and IT |
ERP link | The integration design and the IDs every record carries | The company code and local cost objects | Group IT |
How should you sequence a multi-country rollout?
One global template, one pilot market, then waves. Each wave starts only when the one before has met its exit criteria.
Global template. Build the global settings from the worksheet above, with one module that solves a problem every market shares, often the budget or invoice checks.
Pilot market. Choose a market that is large enough to matter but simple enough to finish: one ERP company code, a manageable number of vendors, and a local sponsor who wants it. Run at least one full month-end close in the platform before calling it done.
Waves. Group the remaining markets by what they share (ERP instance, region, language, tax regime) so each wave reuses the same local settings. Each wave starts with the lessons of the last.
Add modules after markets. Widening one module across markets is usually easier than deepening many modules in one market, because the global template stays simple.
What should a market have ready before it goes live?
Use this: a market goes live only when every item is ticked. Run the check two weeks before the planned date.
Budget structure loaded, with the local levels agreed and mapped to the global ones.
Local cost objects mapped to the ERP company code, and the integration tested.
Approval limits set in local currency, with named approvers and stand-ins.
Local tax and invoice rules configured and tested on real invoices.
The top vendors by spend onboarded and able to submit, with templates in the local language where needed.
Local users trained by role, and at least one local administrator named.
Exit criteria agreed: for example, one month-end close and one full invoice cycle completed in the platform.
A support route for the first month, with a named contact on each side.
How do you handle different planning cycles across markets?
Lock one global calendar for reporting, and let markets keep their local calendar underneath it.
Some markets run a different financial year; some plan quarterly, others monthly. The platform should hold each market's budget in its own calendar and roll it up into the group's reporting periods, so global reviews compare like with like. Agree three things globally: the reporting periods, the dates of the global reforecasts, and the cut-off for each month's numbers. Leave the rest to the markets.
How does Brandintellé scale across markets and regions?
Brandintellé is one product, configured for each company and each market, so a new market is a configuration exercise, not a new build.
Global structure, local detail: the budget is built on your own dimensions and levels, so global levels stay fixed while each market adds its own underneath.
Markets configured during implementation: each market's company codes, currencies, tax and invoice rules are configured as part of its rollout.
Approvals and access by market: approval rules by budget line and amount, and role-based access, so each market's people see and approve only what they should.
Regional and local spend: regional teams and dealers can submit plans under the central campaign, with co-funded spend tracked against budget and claims backed by proof.
Planning cycles: budget, outlook, available and consumed show by month, with increases, decreases and reallocations against a live budget.
One module, one team first: we recommend starting with one module for one team and adding the rest once it's working, the same logic as a pilot market.
A global rollout succeeds when the template is decided once and every market is a configuration, not a project.