Home › Guides

How to test an ERP localization before go-live

Build the test pack from your obligation register and real transaction population. Give each test a precise expected result and retained evidence. This makes acceptance repeatable after a release or provider change.

The cases below are test-design recommendations. Select the ones that fit your operation, then have the local finance owner approve the expected legal and accounting result. A sandbox acknowledgement establishes behavior in that environment; it does not certify all production scenarios.

Record the configuration under test

Identify the ERP edition, release, country package, mapping, validation artifacts, provider, tenant and credentials role. Record which components differ from production.

Freeze or version the relevant configuration while running the pack. If a supplier changes a mapping halfway through, record which cases used the earlier version and rerun affected cases.

For every case, retain this record:

Test the ordinary flow

Create an ordinary sale with known entity, customer, tax and payment data. Compare the posted transaction, generated document and externally received result. Check the identifiers, currency, tax classification, amounts and references.

For inbound processing, send a valid supplier invoice. Confirm the supplier match and expected draft or posting behavior. Test the purchase-order reference and attachment scope agreed for the implementation.

Retain the structured original and acknowledgements, not just screenshots. Screenshots can help an operator recognize a state, but they rarely contain the whole transmitted record.

Test amounts and tax meaning

Include line discounts, document-level adjustments, freight or other charges, rounding and foreign currency where used. Have finance approve whether each value belongs in the taxable base and how it is presented.

Use the selected profile's actual validation rules. For example, Peppol BIS Billing defines a payable-amount relationship involving the VAT-inclusive total, paid amount and rounding. Treat that as a document-rule test, then check the underlying accounting independently. Peppol BIS Billing specification

Test exempt, zero-rated and out-of-scope treatment only where the business uses them. Give each case its approved tax rationale. Equal tax amounts do not make those classifications interchangeable.

Test corrections and lifecycle changes

Issue a credit document against an accepted invoice. Verify the reference, amounts, external result and ledger effect. Include partial corrections if they are in scope.

Test cancellation only where the selected country and document workflow support it. Record any applicable time limit from the current authority rule. Do not reuse another country's cancellation procedure.

Add prepayment, self-billing, consolidated retail or other special cases only when relevant. These can require different document types and mappings. Treat them as explicit scope decisions rather than assuming they follow the ordinary invoice path.

Test invalid data

Remove a required identifier, use an incompatible scheme, choose an invalid code and submit a document with inconsistent amounts. Confirm which layer detects the failure and what the user sees.

Check that an error identifies the affected document and next action. The operator should be able to distinguish a master-data correction from an integration outage or a tax decision needing review.

Confirm that a rejected submission cannot quietly appear in the accepted reporting population. Preserve the rejection and the later corrective action as linked events.

Test uncertain outcomes and duplicates

Simulate a timeout after transmission. Use the provider's supported status lookup to establish whether the original submission succeeded. Verify that a retry follows the connector's documented duplicate-prevention behavior.

Deliver the same inbound document twice. Confirm that the implementation identifies the duplicate using the agreed business identity and does not create two payable documents.

Test a delayed response arriving after a retry or operator action. Check that the late event attaches to the right transaction and does not overwrite a newer state incorrectly.

Test outages and access

Rehearse the country's approved fallback process. Have the operator locate the procedure, identify permitted actions, retain evidence and recover the backlog. Test the handoff to the provider and finance owner.

Check an expired or revoked credential in a safe test environment. Confirm that the failure is visible and that the documented renewal process restores service. Use test credentials and avoid disrupting production.

Keep tax-authority rules separate from a provider's technical recovery options. A connector's ability to create an offline file does not establish permission to issue it in a particular legal circumstance.

Test returns, exports and history

Generate the relevant periodic return or audit export from the tested population. Compare its document coverage and amounts with the ledger. Explain timing differences and approved manual adjustments.

Produce a historical-period extract after the new release. Check that older account mappings, registrations and document relationships remain available. Include a year-end or fiscal-period boundary when that affects the output.

Use the authority's validator where one is provided and appropriate. ANAF, for example, publishes D406 technical materials and validation tools. A validator result should accompany reconciliation rather than substitute for it. ANAF, SAF-T technical materials

Decide what passes

Agree severity and acceptance criteria before execution. A blocking case fails when a required output is wrong, missing or unrecoverable. A presentation issue may have a different release decision if it does not affect the agreed obligation or operation.

Record each failure, owner, corrective version and rerun result. Do not replace a failed result with an unlinked screenshot of a later success. Preserve enough history to explain the final decision.

Finance accepts the legal and accounting result. IT accepts the configuration and interfaces. Operations accepts monitoring and recovery. Record unresolved scope explicitly in the release decision.

Keep the pack as a versioned regression asset. Rerun the affected cases when a rule, schema, ERP release, provider or material business process changes.

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 – abbreviations and terms used in these guides (SAF-T, Peppol, CTC, EN 16931, IFRS and more).

Page last updated: · Markdown version

Newsletter – monthly digest of mandate and ERP support changes. Subscribe on the home page.