How do you build a global template for an ERP rollout?

A global template is built in three steps: first, define the core processes and master-data rules that apply identically in every country. Second, name the permitted local deviations, usually tax, statutory reporting and payments. Third, install an authority that must approve every further exception. Without that third step, any template falls apart within the first rollout year.

What belongs in the template, and what does not?

The template contains what carries the business model: the order-to-cash process, the purchase-to-pay process, the master-data rules for items, customers and vendors, the group-level chart of accounts and the dimension logic for reporting. These elements later decide whether figures are comparable across countries.

What a country legally or practically cannot change does not belong in the template: local tax logic, statutory reporting, payment formats, archiving obligations. Forcing these points centrally produces expensive workarounds in the wrong place.

• Binding group-wide: core processes, master-data rules, chart-of-accounts logic, dimensions, permission model
• Permitted locally: tax, statutory reporting, payments, language, legally required documents
• Always subject to a decision: anything a country wants on top

The borderline case is the third category, and there it is governance rather than technology that decides.

How do you stop exceptions from hollowing out the template?

Every country organisation has good reasons for its special requests, and taken individually almost every one is plausible. The erosion comes from the sum. That is why the template needs an owner with decision rights: one person or a small committee that tests every deviation against a simple question: legally required, commercially essential, or merely familiar?

In practice, an exception ratio works well as an early-warning signal. If country-specific changes exceed roughly a fifth of the template, this is no longer a localisation topic but a governance topic. At that point the template no longer governs the countries; the countries govern the template.

What works here is not the ban but the price. When every exception is quantified with its downstream cost for testing, documentation and release maintenance, most of them settle themselves. Countries give them up voluntarily as soon as the effort lands visibly in their own budget.

The operating model: how the template is run

Internationally, people often ask about the operating model for the global template, meaning the operating order behind the rulebook: who owns the template, who represents the countries, in what rhythm decisions are made. A hub-and-spoke arrangement has proven itself: a small central team as the hub, owning template and core processes, and per country one named key user as the spoke who bundles local requirements instead of individual shout-outs.

Three roles are enough for the midmarket: the template owner with decision-making authority, one process owner per core process and the country key users. Plus a fixed rhythm in which change requests are decided in batches instead of one by one in passing. No further committee is needed, and every additional one slows down exactly the decisions the template was built for.

The operating model also decides the boundary between central and local in day-to-day business: changes to the core run through the hub, local obligations remain the country's responsibility, and everything in between has a defined path to the decision table. This keeps the template a working tool rather than a museum piece.

In what order does a solid template come together?

The most reliable route runs through a pilot country that is representative but not the most complex. There the template is proven for real: with real data, real users and a real month-end close. Only then do you scale. Finishing the template on the drawing board and launching in the largest market means testing theory under maximum pressure.

After the pilot: incorporate the findings, freeze the template, then roll out. Each wave may refine the template, but not renegotiate it. That is what separates one rollout from twelve individual projects.

The most common mistake is to declare the template finished before the pilot. A template on paper describes how things should run, not how they do, and the difference only shows with real documents and a real month-end close.

This order pays off twice in terms of time: what the pilot uncovers gets corrected once and then applies to every wave that follows. Whoever skips the pilot corrects the same thing again in every country.

What role does the data foundation play in the template?

The underrated foundation. Processes can be sharpened per country; a data foundation that has drifted apart cannot. If item numbers, customer structures and dimensions go their own way per country, consolidation remains manual work forever, and every later automation, including AI, is built on sand.

That is why master-data governance belongs inside the template itself: who creates records, under which rules, with which mandatory depth. The data foundation stays; systems and countries are added. Control remains on your side, with Business Central as home.

In practice that means: the master-data rules belong in the same sign-off as the processes, not in an appendix. And they need a named owner per data object, because a rule without an owner is a recommendation.

The test after the second wave is simple: can items and customers be analysed with the same logic across all entities? If not, the data foundation has already drifted apart, and every further wave widens the gap.

What is different in Business Central compared with SAP templates?

Almost everything written about global templates comes from the SAP world and describes a model that does not exist in Business Central. The difference changes the structure fundamentally.

• No core modification, but extensions: In Business Central the standard is not changed, extensions sit alongside it as their own apps. A template is therefore not a frozen system state, it is a set of configuration and apps.
• Configuration packages instead of transport requests: Settings and master data are distributed through configuration packages, not through a transport chain. That makes the rollout easier, but it demands discipline in versioning.
• Continuous cloud updates: Microsoft ships two major releases a year. A template that is defined once and then frozen is out of date after a year.

The Business Central template consists of three separately maintained parts: the rule set with processes, master-data rules and account logic, the configuration packages per rollout wave, and the extension set, separated into group-wide and country-specific.

How do you keep the template alive across releases?

This is the point at which most international Business Central programmes quietly drift apart. If nobody tests the half-yearly releases against the template, every country tests for itself, and over two years one template becomes twelve slightly different systems.

A plain routine prevents this: a named owner for the template, a fixed review date per release, a set of automated test cases for the core processes, and a short change report to all countries. The effort is a few days per release, compared with the effort of bringing twelve diverged countries back together.

This upkeep is the real difference between a template that was merely implemented and one that still holds after five years. Business Central as home does not mean standing still, it means regular, planned movement.

What does two-tier mean: headquarters large, subsidiaries lean?

Not every entity needs the same system, and that is exactly what the two-tier approach targets. The group headquarters stays on a larger solution while subsidiaries run on Business Central. Business Central is built as a lean second-tier solution for this and connects to the overarching structure without the subsidiary carrying the headquarters' complexity.

The advantage is speed. A subsidiary is productive in weeks to a few months instead of riding along in a group programme. The price is a deliberate decision about the interface: which data flows when and in which direction, and which system leads for which object.

This decision belongs at the start, because it determines the consolidation. Business Central ships a dedicated feature for it that transfers the balances of several companies into a consolidation company.

How do you separate local obligations from group governance?

Local obligations and group governance are two different things, and mixing them loses both. Locally belong the points a country cannot change legally: tax logic, statutory reporting, payment formats, archiving obligations. Trying to enforce these centrally produces expensive workarounds in the wrong place.

Group-wide belong the points that secure comparability: chart-of-accounts logic, dimensions, master-data rules, the permission model and the core processes. Releasing these locally costs manual work in the consolidation every month later, because the figures no longer fit together.

In between lies the area that needs a decision, and that is exactly what governance is for. Every additional country requirement is tested against one simple question: legally required, commercially essential, or merely familiar? Document flows between the companies belong settled early.