One Epicor Template, Several Countries. What Should Stay Global—and What Must Stay Local?
Multi-country Epicor programmes work best when shared business meaning stays global while legal, language and operating differences are localized deliberately.
The short answer
A multi-country Epicor template should standardize shared business meaning and governance, while allowing controlled localization for legal, fiscal, language and genuine operating differences. The mistake is treating “global” as identical screens everywhere or treating “local” as permission for every site to redesign the process.
Epicor Kinetic supports multi-company, multi-site, multi-currency, multi-language and country-specific functionality. The implementation challenge is to decide where that flexibility belongs.
Start with the business objects that must mean the same thing
Before discussing localization, define what the group needs to compare across countries.
Typical global objects include:
- customer and supplier identity rules;
- part/item numbering principles;
- chart-of-accounts structure and group dimensions;
- order and shipment status definitions;
- costing principles;
- approval policy;
- intercompany relationships;
- plant and warehouse hierarchy;
- management KPI definitions.
If these differ without governance, consolidated reporting becomes a translation exercise.
Separate legal localization from preference
A statutory invoice requirement is different from a local manager preferring a different approval path.
Create a localization register and classify every request:
1. law or statutory reporting;
2. tax or banking requirement;
3. language or document requirement;
4. market/customer requirement;
5. operational necessity;
6. local preference.
The first four usually deserve formal design attention. The sixth should be challenged unless it creates measurable value.
Company structure is an architecture decision
Epicor's global business capabilities support multiple companies, sites, books, currencies and intercompany transactions. Do not choose the company/site model only to mirror the organization chart.
Consider legal entity, fiscal reporting, tax registration, intercompany trading, operational ownership, shared services and data-access requirements.
A site that feels operationally independent may not need a separate company. A legally separate entity may need one even if the plant is managed centrally.
Master data needs global ownership and local stewardship
A global template fails when every site can independently create versions of the same customer, supplier or item.
Define which data is:
- globally mastered;
- globally governed but locally extended;
- locally owned;
- synchronized between companies;
- prohibited from free-text substitution.
The governance should include who approves new records, how duplicates are prevented and what happens when local requirements need additional attributes.
Intercompany process is where templates become real
A company may manufacture in one country, buy centrally in another and sell from a third. The template must explain orders, transfers, shipments, invoices, currency, elimination and ownership through that chain.
Test real scenarios rather than isolated transactions:
- group company buys from another group company;
- central procurement negotiates for several plants;
- one plant supplies another after a capacity change;
- customer order is sold in one entity and fulfilled elsewhere;
- inventory moves across borders before final invoicing.
The design is successful when finance and operations can both explain the same intercompany event.
Local reporting should not destroy global comparability
Countries may need different statutory reports, tax codes or invoice formats. Keep those local outputs attached to global transaction meaning where possible.
Avoid duplicating the entire process simply to produce a local form. Use country-specific configuration, reporting and controlled extensions instead.
Epicor documents country-specific functionality within its global business framework. Existing users should treat those capabilities as part of template design rather than a late localization patch.
Language is more than translation
A multi-language ERP may translate the interface, but rollout success also depends on training language, terminology, help content and local support.
The same English term can be translated correctly and still be misunderstood operationally. Create a glossary for key statuses and transaction concepts, especially where finance, warehouse and production share the same record.
Document local examples using the global process.
Build a global design authority
A template needs a decision mechanism after go-live.
Create a small cross-functional authority that reviews changes against three questions:
- Is this requirement truly local?
- Does it change global business meaning?
- Can the requirement be met through configuration or extension without forking the process?
Record the decision so the next country does not reopen the same debate.
Roll out by process chain, not screen list
Do not validate a country by checking that every menu opens.
Run end-to-end scenarios:
- quote to cash;
- procure to pay;
- plan to produce;
- receive to consume;
- intercompany supply;
- period close;
- local tax/statutory output.
Use local data and exceptions. A global template becomes credible only when it survives the country's real operating day.
ACC's role in Asia rollout
ACC describes itself as the first Epicor partner in Asia with more than 20 years of Epicor experience and project support across multiple regions. That makes ACC most relevant when a global Epicor owner wants local delivery knowledge without losing the corporate template.
The partner's job should not be to “localize everything.” It should help the global team identify which differences are mandatory, which are operationally justified and which should remain standard.
The broader rollout situation is explored in Head Office Runs Epicor. What Changes When the Next Plant Is in Asia?.
Connect back to the improvement roadmap
The pillar Epicor Is Live. Where Does the Next Operational Gain Come From? frames global consistency as one source of post-go-live value.
A mature multi-country template reduces the amount of management work required to reconcile countries after the fact. It also makes later enhancements easier because the group knows which layer is global and which is local.
Use a template-fit workshop, not a blank-sheet workshop
For each process, begin with the current global design and ask the local team to demonstrate where it fails against a real legal or operating requirement. This changes the conversation from “how would you like the system to work?” to “what must be different, and why?”
Document accepted deviations with rationale, owner and whether the change is reusable for another country. Over time, the template becomes more mature rather than more fragmented.
Plan cutover across currencies and calendars
Multi-country deployment creates timing questions that a single-site project can ignore. Opening balances, exchange rates, in-transit inventory, intercompany documents, local tax periods and fiscal calendars all affect the cutover sequence.
Run a mock close before go-live. Confirm that the local entity can transact correctly and that headquarters can consolidate and reconcile the result without manual reconstruction.
Treat local support as part of localization
A process is not truly localized if users can transact in their language but every urgent issue waits for another time zone. Define first-line support, escalation, language coverage and ownership of global-template decisions.
This is especially important during hypercare, when local teams are still learning which problems are training issues, master-data issues and true system defects.
Use a global/local design matrix
For every major process step, record the global rule, allowed local parameters, prohibited local changes and approval owner. Keep the matrix visible during configuration and UAT.
This prevents localization from becoming a memory-based negotiation. It also gives future countries a starting point: they can see which differences were already accepted elsewhere and whether those decisions should become part of the global template.
Review the template after each country
A rollout should improve the template, not only replicate it. After hypercare, capture which local questions exposed unclear global rules, weak master-data ownership or missing test cases. Decide which lessons belong in the standard deployment kit for the next country.
That feedback loop turns regional variation into better global governance rather than accumulated exceptions.
Frequently asked questions
Should every country use the same chart of accounts?
The group needs consistent consolidation logic, but local statutory requirements may require additional accounts, books or mappings. Design the relationship explicitly rather than forcing either side to improvise.
Should local teams be allowed to create custom fields and workflows?
Use governance. Some local extensions are justified; uncontrolled local changes create future upgrade and reporting complexity.
Is multi-company the same as multi-site?
No. Company structure usually reflects legal/financial separation, while site structure can represent operational locations. The correct model depends on the business and reporting requirements.
How early should localization be discussed?
During template design, not just before user acceptance testing. Late localization creates rework because it often touches tax, banking, documents, master data and approvals.
Can ACC support a global Epicor company opening in Asia?
Yes. ACC positions its Epicor services around implementation, enhancement and multi-country support, with long experience in Asia. The scope should be aligned with the customer's global design authority.
Standardize meaning, localize necessity
A good global template does not erase local reality. It makes local variation visible, governed and compatible with group control.
That is the difference between one ERP used in many countries and a genuinely global operating model.