# How to prepare master data for ERP localization Prepare master data before the final integration test. Missing identifiers, ambiguous tax categories and incomplete product data can stop a valid business transaction from becoming an accepted document. Start with the chosen country's official requirements and the exact document profile. This guide gives you a preparation method. Its field inventory is a review list, rather than a claim that every field is mandatory in every country. ## Inventory the populations Identify the entities, customers, suppliers, products and payment methods used by the proposed operation. Separate active records from historical and inactive records. Keep historical identifiers available for retained documents. Assign an owner to each data domain. Finance should approve tax treatment, company secretarial staff or an equivalent owner should confirm legal identity, and the commercial owner should confirm customer routing details. Give IT responsibility for validation and migration mechanics. Avoid asking one team to approve every kind of data. The person who can correct a street address may have no authority to decide a VAT exemption. ## Create a field dictionary For each field, record its business meaning, authoritative source, format, permitted values, entity scope, effective date, owner and validation rule. Include the specification reference that makes a field mandatory or conditional. Preserve identifiers as text where their meaning requires it. Leading zeros, prefixes and scheme identifiers can be part of an identifier. Keep tax IDs, company registration IDs and electronic endpoints in separate fields even if a country's values sometimes resemble one another. Use this copyable record: - Field name and business meaning: - Object and country scope: - Mandatory or conditional rule: - Official or specification reference: - Source system and approving owner: - Format and permitted values: - Effective dates and historical handling: - Correction workflow: - Test cases and evidence: ## Verify entity and counterparty identity Confirm the registered name, address, establishment, company identifier and tax registrations. Add the relevant branch or establishment identifier where the scenario requires it. Record the issuer of each identifier and who verified it. For electronic routing, collect the participant identifier, scheme and supported document capability. Confirm the recipient through the provider's supported discovery process. A routable endpoint and a valid tax registration answer different questions. Microsoft's France setup guide gives a concrete country example. It requires company SIREN and SIRET data and customer electronic-routing information for the documented Business Central extension. Those are France-specific setup requirements, not a universal model for all localizations. [Microsoft, France electronic-invoicing setup](https://learn.microsoft.com/en-us/dynamics365/business-central/localfunctionality/france/enable-electronic-invoicing-france) ## Map tax meaning before rates Separate tax jurisdiction, transaction classification, rate, exemption reason, recovery treatment and tax point. A zero amount can result from several different tax treatments. Preserve the reason required by the selected specification and tax rule. Maintain effective dates for changes. Decide how the ERP handles a correction to an older transaction after a rate change. Ask the tax owner to approve the expected result for those cases. Do not take the presence of a default tax code as proof that the business should use it. Verify the code against the actual supply and taxpayer status. Keep the mapping decision in the obligation register. ## Prepare product and payment data Check item descriptions, units, classification codes, tariff codes, country of origin and industry data where applicable. Store the scheme or code-list version along with a code when versions matter. Odoo's Malaysia documentation illustrates the local detail that can be needed. It describes Malaysian classification codes for e-invoice products and tariff or service codes used to group transactions in SST reporting. Those mappings have distinct purposes. [Odoo 19, Malaysia localization](https://www.odoo.com/documentation/19.0/applications/finance/fiscal_localizations/malaysia.html) For payments, distinguish the payment-method code from the account identifier. [Peppol](https://erplocalization.com/glossary/core/#core-peppol-and-openpeppol)'s BR-49 requires a payment-means type code when payment instructions are present. Test bank-account and other conditional requirements against the profile in use. [Peppol BIS Billing, BR-49](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-49/) ## Validate with useful denominators Measure completeness against the population that needs a field. If only domestic customers in a particular scenario need a local routing attribute, report missing values for that population. A global completeness percentage can hide every affected customer inside a much larger unaffected population. Validate syntax separately from business correctness. A field can pass its length check and still contain the wrong entity's number. Use authority checks or approved documentary evidence where appropriate and available. Create negative tests: missing identifier, wrong scheme, expired mapping, unsupported code, duplicate supplier and changed bank details. Verify that the workflow sends each issue to the right owner. ## Control corrections and migration Retain the original value, corrected value, effective date, reason and approver for material changes. Decide how a correction affects unposted documents, queued submissions and retained originals. During migration, reconcile record counts and significant relationships. Test that the correct tax registration remains linked to the correct entity and that an address change does not silently change the treatment of historical invoices. Keep bank-data approval separate from routine address maintenance. Use the organization's payment-fraud controls for changes that affect payment destinations. ## Release the data with the process Have domain owners approve the active population. Run representative transactions through generation, validation, exchange and reporting. Confirm that failures identify the missing or incorrect field in a way an operator can resolve. Keep the field dictionary, mapping version, exception list and approval with the release. Feed unresolved records into an owned work queue. A data-cleaning exercise is complete when the required operation works and remaining exceptions have a deliberate handling process. ## Related on this site - [Country pages](https://erplocalization.com/countries/): key facts with sources - [E-invoicing matrix](https://erplocalization.com/e-invoicing/): country × ERP support - [All guides](https://erplocalization.com/guides/) Vendor documentation is cited only as an example of the level of evidence to ask for; it is not a recommendation or a ranking. This guide is general information, not tax or legal advice. Checked 2026-10-17. Related: [Glossary](https://erplocalization.com/glossary/) – abbreviations and terms used in these guides (SAF-T, Peppol, CTC, EN 16931, IFRS and more). --- Canonical: https://erplocalization.com/guides/localization-master-data-readiness/ · Last updated: 2026-10-17 · Informational only; not tax, legal or implementation advice. Featured placements are paid or promotional and do not affect the compliance data. Data: CC BY-NC 4.0 (commercial use needs a licence: https://erplocalization.com/data-licence/), attribution "ERP Localization (erplocalization.com)".