Global Template or Local ERP? A Decision Framework for China

The short answer

Four variables decide the question, and they should be assessed in this order: how much consolidation the parent actually needs, how heavy the local compliance load is, where the organisation's real capability sits, and what happens at the next upgrade or rule change. The first two determine which architecture is theoretically appropriate. The last two determine which one will still be working in three years.

Most failures in China ERP programmes come from answering the first two and ignoring the last two. That produces a decision that is defensible on a slide and unsustainable in operation — a global template customised until nobody can maintain it, or a local system adopted for compliance with no credible path into group reporting.

Why this decision recurs

The tension is structural rather than a vendor shortcoming. A group template exists to make entities comparable: one chart of accounts, one set of controls, one consolidation. A China entity exists in a regulatory environment that requires outputs the template was not designed to produce, connected to state infrastructure the template was not designed to talk to.

Both pressures are legitimate. Standardisation reduces group-level cost and risk; local compliance is non-negotiable. The decision is therefore not about choosing one value over the other, but about deciding where the boundary between them sits, and making sure the boundary has an owner. Every architecture described below is workable; what distinguishes them is where the recurring effort lands and who carries it.

Variable 1: how much consolidation the parent actually needs

This is the variable teams misjudge most often, in both directions. Some parents describe a requirement as 'group reporting' when what they actually need is a monthly spreadsheet of mapped figures. Others describe the same need as 'a summary' when the group in fact consolidates entity by entity under a single accounting framework.

The distinction matters because it determines whether the China entity needs to sit inside the group's ledger or beside it. Full consolidation under group policies implies the entity's transactions have to be reportable in the group's structure, which pushes toward the template. Mapped aggregates imply the entity can keep its own books and report a defined subset, which makes a local system entirely viable.

Establishing this takes one conversation with group finance and one look at the actual reporting calendar. It is worth doing before any vendor conversation, because it eliminates roughly half the options immediately. Our guide to HQ consolidation from a China subsidiary sets out what a credible bridge looks like.

Variable 2: how heavy the local compliance load is

The second variable is the entity's own compliance surface, and it varies far more than most global teams expect. A pure service entity with a handful of invoices a month has a light load. A trading company with high invoice volumes and foreign-currency settlement has a moderate one. A manufacturer that exports has a heavy one, because the compliance chain runs from production through customs to refund.

Two properties of this variable matter. First, it is not proportional to revenue — a company can be large and domestically simple, or small and export-heavy. Second, it compounds with volume, because manual bridges that survive at low transaction counts become control failures at high ones. Our guides to export tax rebate in an ERP and customs declaration integration show how far the export chain extends.

Plotting the entity on these two variables — consolidation need against compliance load — is the core of the framework. The remaining two variables decide whether the theoretically correct answer is practically sustainable.

Variable 3: where the real capability sits

Every architecture requires somebody to own a boundary. A template extended into China needs somebody who understands both the platform and Chinese compliance. A local system reporting upward needs somebody who owns the reconciliation between the two views. Groups frequently choose an architecture without asking who that person is, and the answer is often 'the consultant', which means the capability leaves with the project.

The honest assessment has three parts: whether the China finance team has capacity to own a boundary, whether central IT can support a local exception, and whether the partner relationship will outlast the implementation. Where the answers are weak, the right architecture is the one that requires the least custom maintenance, irrespective of which is theoretically better.

Variable 4: what happens at the next upgrade or rule change

This is the variable that separates architectures that age well from those that do not. Chinese tax formats and invoicing rules change, and so do platform versions. A template extended through customisation pays for both: each rule change touches the localisation, and each platform upgrade threatens to break it.

The same question applies to a two-platform architecture, where the risk sits in the bridge: if the mapping changes, somebody has to change it, and if the change is not controlled, the reconciliation drifts. Neither architecture is immune, but each gives a clear signal about where the maintenance burden sits — and that is the burden to cost over five years rather than one.

The three viable architectures, and when each wins

Almost every workable arrangement is a version of one of these three. The labels matter less than the conditions under which each is the right answer.

• Architecture A — global template with a funded localization layer. Wins when the parent consolidates under group policies, the entity is material to group reporting, and the organisation can fund and own the localization for the life of the system.
• Architecture B — local system with an owned reporting bridge. Wins when the entity's compliance load is heavy, the parent needs mapped aggregates rather than full consolidation, and the local finance function is small.
• Architecture C — two systems with an owned reconciliation. Wins when both requirements are genuine and neither can be compromised, and the organisation accepts the organisational cost of maintaining two platforms.

The architecture that fails is a variant of A without the funding: a template customised heavily for China, with no maintenance agreement and no internal owner. It works until the first rule change or staff departure, and then it becomes a liability that is expensive to unwind. Our article on why global ERP templates break in China describes that pattern in detail.

A scoring model you can actually use

If the framework is to change a decision rather than describe one, score the candidate architectures against weighted criteria. The weights below are a starting point, not a recommendation, and they should be adjusted to the group.

• Group reporting fit — weight high if the parent consolidates entity by entity under group policies.
• Local compliance coverage — weight high if the entity files domestic returns monthly and handles export documentation.
• Recurring maintenance burden — weight high if internal finance capacity is limited.
• Upgrade resilience — weight high if the entity has significant customisation or a long platform roadmap ahead.
• Talent and support continuity — weight high if the partner relationship is narrow or the internal owner is a single person.
• Cost over five years — including connector maintenance, reconciliation time, and parallel running.

Score each architecture on each criterion, then read the result critically. Where two options score closely, the tiebreaker is usually talent continuity, because the architecture nobody can maintain is the one that fails regardless of how well it scored on capability.

Worked example: a mid-sized trading subsidiary

A trading subsidiary with moderate invoice volumes, foreign-currency settlement, no export manufacturing, and a parent that consolidates quarterly under group policies. Consolidation need is real but not deep; compliance load is moderate; the finance team is three people.

This profile usually resolves to Architecture B or a light version of A. Because the parent consolidates, the bridge has to be credible and owned, but because volumes are moderate and the entity does not manufacture, the compliance load does not demand a deep product extension. If the parent already runs the group platform, A with a properly funded localization is defensible. If it does not, B with an owned bridge is usually cheaper to run and easier to support.

Worked example: a manufacturing subsidiary with export sales

A plant with production costing, high purchase and sales volumes, export sales, and a parent consolidating under group policies. Compliance load is heavy and compounding; consolidation need is genuine.

This is the hardest profile, and the one where the boundary matters most. The operational depth required by the plant and the depth required by the export compliance chain both point away from a thin extension of a global template. In practice this profile frequently resolves to Architecture C: a global platform as the group's reporting spine, a domestic system carrying statutory, invoicing, and export compliance, and a disciplined reconciliation between them. Our Infor vs Kingdee manufacturing comparison explores the same trade-off from the plant's perspective.

Worked example: a small service entity

A representative office or small service company with low transaction volume, few invoices, and a parent that needs a summary. Consolidation need is light, compliance load is light, and the finance function is one person or partly outsourced.

This resolves almost always to the lightest viable option: a domestic system covering compliance, with mapped figures reported upward, or a group platform if the licensing and support model makes that cheaper at this scale. The risk here is over-engineering, and the discipline required is to resist buying capability the entity will never use.

The costs people forget

Framework decisions are usually made on visible costs and broken by invisible ones. These are the lines that most often go missing.

• Localization connector maintenance, quoted at go-live but recurring for the life of the system.
• Internal finance time to own the reconciliation, which is a permanent headcount commitment rather than a project cost.
• Parallel running during implementation, where both processes must agree before the manual route is retired.
• Upgrade remediation, proportional to how much was customised.
• Retraining, because China finance teams have turnover and the system has to be learnable by the next person.
• The exit cost if the architecture has to change later, which is highest for the most customised option.

Failure modes to design against

• A template customised for China with no maintenance agreement and no named owner.
• A local system with no reporting path, discovered at the first consolidation.
• A bridge that is rebuilt manually each period, making its reliability depend on the person doing it.
• Compliance flows left outside the system because the volumes seemed low at the time.
• A decision made on licence cost without modelling recurring maintenance and internal reconciliation time.

Each of these is visible in advance and each is cheap to prevent at design time. They are expensive afterwards because they surface during a filing error, an examination, or a staff departure rather than during a project meeting.

How to run the decision as a process

The framework is only useful as a sequence, and the sequence matters because later steps change based on earlier answers.

• Confirm the parent's actual consolidation requirement in writing, with the reporting calendar.
• Document the entity's compliance flows and volumes, including the export chain if it applies.
• Assess internal capability honestly: who owns the boundary, and what happens when that person is unavailable.
• Score the three architectures against weighted criteria, including five-year cost.
• Name the owner of the boundary before signing, and write it into the project plan.
• Run a trial close on real data on the chosen architecture, and compare the effort with the current process.
• Write down the assumptions that would have to change for the decision to be revisited.

The last step is the one that protects the organisation at the next review. China ERP decisions are frequently revisited two or three years later, and the groups that handle that well are the ones who recorded why the original choice was made. For the requirements themselves, see our ERP checklist for foreign companies operating in China.

Verdict

There is no universally correct architecture, and any adviser offering one is selling something. What can be decided rigorously is the order of the questions: consolidation need, compliance load, capability, and maintainability. Answering them in that order produces a decision that is both theoretically appropriate and practically sustainable, which is the only kind that survives contact with a rule change and a staff departure. For the comparison of specific vendor pairings under this framework, see our SAP vs Kingdee and NetSuite vs Yonyou analyses.