# How to maintain ERP localization when rules and schemas change Assign an owner to each country obligation before the first production transaction. That owner needs a way to detect changes, assess their effect, obtain a software update and prove that the updated process works. A localization can change because of a legal amendment, a new schema, a revised authentication method or a supplier release. These changes arrive on different schedules. Track them separately so the earliest announcement does not become an assumed production deadline. This guide describes a recommended operating routine. Each country still needs its own applicability and fallback decisions. **Diagram:** A change passes from official source through assessment, release, tests and operations. Recommended change process. Record legal dates, release dates and deployment dates separately. ## Create one obligation register Record the country, entity, registration, affected transactions, required output and official source. Add the ERP product, release, local package, mapping, provider, credentials owner and support contacts. Separate the legal owner from the technical owner. The legal or tax owner decides applicability. The application owner implements the agreed process. Operations monitors production and escalates exceptions. One person can hold several roles, but the decisions should remain explicit. Subscribe to or periodically review the authority and supplier sources relevant to the obligation. Choose review intervals based on release frequency and business risk. Increase attention near confirmed changes. Record "reviewed, no relevant change" so a quiet period is distinguishable from an abandoned register. ## Keep different dates in different fields For each change, record its publication date, legal effective date, taxpayer phase, sandbox date, vendor delivery date, internal acceptance date and deployment date. Include any appointment deadline or grace period separately. The Commission's [ViDA](https://erplocalization.com/glossary/core/#core-vida) overview provides an example of why that matters. It distinguishes cross-border B2B digital reporting from 1 July 2030 and alignment of domestic real-time reporting systems by 1 January 2035. Those dates describe different changes. [European Commission, VAT in the Digital Age](https://taxation-customs.ec.europa.eu/taxation/vat/vat-digital-age-vida_en) Label a proposal, adopted law, authority guidance and released technical change as different evidence states. When sources disagree, preserve both and assign an owner to resolve the difference. Do not quietly replace a date without recording the reason. ## Assess the affected population Identify the entities, documents, source applications and historical periods involved. Check whether the change affects sending, receiving, reporting or export only. Estimate the work in master data, mappings, credentials, user procedures, training and supplier contracts. A schema update can require a new customer field even when the transport service stays the same. For each dependency, obtain a named owner and delivery commitment. If the supplier cannot deliver before the obligation applies, escalate the gap while there is still time to choose a permitted alternative. ## Preserve historical behavior Keep specification versions, mappings, configuration exports, sample documents and acceptance results together. Record which reporting periods use each version. Norway's current [SAF-T](https://erplocalization.com/glossary/core/#core-saf-t) documentation says version 1.40 is mandatory from 1 January 2027 and may be used earlier. It retains earlier versions for financial years 2026 and earlier. This makes historical-period testing a practical requirement for an implementation plan. [Norwegian Tax Administration, SAF-T documentation](https://www.skatteetaten.no/en/business-and-organisation/start-and-run/best-practices-accounting-and-cash-register-systems/saf-t-financial/documentation/) After an upgrade, reproduce a prior-period export as well as a current-period transaction. Compare the totals and explain intentional differences. Keep access to the software or documented export process needed for retained historical records. ## Test recovery and credentials Include rejection, timeout and correction cases in release testing. Review certificates, delegated permissions and service-account ownership. Record renewal dates and recovery contacts without putting secret values into a shared change register. Use current authority guidance for outage procedures. Poland publishes a distinct procedure for planned KSeF unavailability. Treat the applicable offline process as its own workflow, with evidence and later submission rules. [Polish Ministry of Finance, KSeF unavailability mode](https://ksef.podatki.gov.pl/informacje-ogolne-ksef-20/tryb-offline-niedostepnosc-ksef/) Do not infer the current credential policy from an old implementation article. The current [KSeF certificates page](https://ksef.podatki.gov.pl/informacje-ogolne-ksef-20/certyfikaty-ksef/) is the place to check supported credential uses and announced changes. Record the date of that review in the project evidence. ## Deploy with a reconciliation plan Choose a deployment window and define the boundary between old and new processing. Identify documents already queued or accepted. Avoid letting both versions submit the same backlog. Agree the evidence that will establish success after deployment: the intended configuration is active, representative documents pass, responses return to the ERP and the relevant population reconciles. Assign a person to check each result. Define rollback conditions before release. Some changes can be reversed technically while the old format is no longer legally acceptable. Have the tax owner approve the available response rather than assuming a software rollback solves the obligation. ## Close and keep the public record current Archive the release decision, test results, reconciliation and remaining limitations. Update the internal register and the public country or ERP page from the same approved facts. Keep a concise decision record: what changed, why it applies, what configuration implements it, who accepted it and which questions remain. That record should let another person reconstruct the implementation without interviewing the original team. Review production exceptions after the first reporting cycle. A release that sends invoices successfully can still fail a later return, audit export or period-end reconciliation. Close the change only when the agreed output population has been checked. Use the [cutover guide](https://erplocalization.com/guides/erp-cutover-tax-history/) for replacing a system, and the [acceptance-test guide](https://erplocalization.com/guides/erp-localization-acceptance-tests/) for a reusable release test pack. ## 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-change-management/ · 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)".