Global ERP: a localization checklist

Build a country-by-country requirements map

List each legal entity, its operating country, transaction currencies and reporting currency. Assign local finance and operations owners to document mandatory outputs and practical workflows. Distinguish a vendor’s global availability from supported localization in the edition and partner proposal you are evaluating.

Test more than the interface language

Request a demonstration of documents, rounding, date formats, units and translated master data. Validate local finance outputs with qualified local advisers. If a partner supplies localization, confirm maintenance ownership and the response to rule changes. Do not assume that a language pack establishes tax or statutory suitability.

Follow intercompany transactions

Use one example involving an intercompany sale, shipment, receipt and settlement. Check transfer pricing inputs, currency conversion, inventory ownership and consolidation adjustments. Document which steps are automated and which require review. Assess the practical process with the people who will close each entity’s books.

Design support across time zones

Map service hours to each plant’s shift pattern. Ask where support and data processing occur, and who owns cross-border incidents. Include data portability and entity separation in your exit planning. Global ERP fit is a combination of product, configuration, local expertise and support coverage; it cannot be established by a worldwide logo map.

Distinguish entity, site and group views

A legal entity, an operating site and a management reporting segment answer different questions. Map them before choosing a company structure in the application. Record which entity owns inventory, employs staff, signs purchase orders and invoices the customer. Shared physical space does not necessarily mean shared ownership. Also identify records that should be global, such as a group item identity, and records that must vary, such as local accounts or supplier payment terms. Have finance and operations approve the mapping together. A consolidation report cannot repair transactions posted in the wrong entity, and an unnecessary company split can create avoidable intercompany work.

Build an output pack for local review

Collect anonymized examples of the outputs your local team actually uses: sales invoices, credit notes, purchase documents, bank files, close reports and management reconciliations. Mark required fields, document numbering, currencies and approval responsibilities. Ask a qualified local adviser to identify which outputs have statutory significance and verify them against current requirements. This guide does not establish those requirements. In the demonstration, generate the documents from a connected transaction rather than editing a standalone sample. Record whether delivery is native, partner-maintained or manual. Keep localization acceptance separate from translation acceptance; a readable screen can coexist with an unusable filing or payment workflow.

Follow a shipment through two closes

Illustrative example: entity A ships components to entity B on the last business day of a month, and B receives them next month. Ask both finance teams to explain ownership, in-transit inventory, matching documents and period treatment under their approved accounting policies. Repeat with an invoice correction and a different transaction currency. The example is deliberately fictional and makes no accounting-policy prescription. Business Central's official intercompany documentation focuses on sales, purchase and journal exchanges. Do not infer complete consolidation or local reporting from that scope. Require a separate demonstration of matching, currency translation and elimination work for the exact products proposed.

Design shared data without erasing local control

Decide who creates a supplier, how duplicate identities are detected and which changes require local approval. A shared address may be convenient while shared bank details create a larger control burden. Version global product information so a new formulation or revision does not silently change local open orders. Test a product released centrally but not yet approved for use at one plant. Maintain a field ownership matrix identifying global fields, local fields and permitted overrides. Include character sets and address lengths in migration tests. Interfaces can truncate information even when the core application's screen displays it correctly, so inspect generated files and destination records as well.

Follow the incident across the calendar

A group operating several time zones needs more than a stated support language. Map production shifts, warehouse shipping cutoffs and month-end calendars against actual support coverage. Define who can authorize a local workaround when the central application owner is asleep. Rehearse a failed intercompany message and identify whether the plant, implementation partner or central IT team opens the incident. Include time-zone conversion in order timestamps and scheduled jobs. Publish an escalation card containing the process owner, technical owner and decision authority for each region. The point is to shorten uncertainty during a real interruption, not merely to count support locations on a vendor website.

Maintain localization as a living dependency

Ask how the selected provider tracks changes affecting local outputs, how updates are tested and how much notice users receive. Record contractual responsibilities and the evidence needed for local acceptance. For partner extensions, identify source ownership, upgrade dependencies and an alternative if the partner stops supporting the product. Test export of entity-specific records and attachments before committing to a group rollout. Maintain a country register with the named edition, local provider, open issues, acceptance owner and review date. Treat an additional country as a new validation exercise even when the same core template is reused. A template can accelerate work; it cannot establish local suitability by itself.

Common questions

Continue your research

The following profiles provide a starting point for checking vendor-described scope. Inclusion is not a ranking or a statement that every requirement is supported.