How to verify an ERP localization before signing a contract
A country flag in an ERP presentation leaves several questions unanswered. Which legal entity can use the feature? What document does it produce? Which edition supports it? Who submits the data, and what happens when the submission fails?
Answer those questions before you compare suppliers. This guide explains how to create an evidence pack that procurement, finance and IT can use together. The process below is a recommended buying method. Country law determines the actual obligations.
Diagram: An obligation becomes a configured capability, a test and an acceptance decision. Recommended evidence process. Each legal obligation needs its own applicability decision.
Define the business that needs support
Describe the proposed operation in one paragraph. Include where the company is incorporated, where people work, where inventory sits, who contracts with customers and who imports goods. Identify sales channels and the types of customers involved.
A company selling remotely can have different requirements from a subsidiary employing staff and holding stock. Ask the tax and legal owners to decide the operating model before the ERP team assigns country packages.
Create a separate obligation record for each required output. Record the legal entity, registration, transaction population, format, recipient, frequency, applicability date, official source and responsible person. Separate invoice exchange, invoice reporting, VAT returns, payroll, annual accounts and audit exports.
For example, use: "Entity FR01 must produce the accounting file required for a French tax audit, using its French accounting context." Do not accept "France compliant" as the corresponding product requirement.
Identify the exact solution
Ask each bidder to identify its product family, edition, release, deployment, country package, additional apps and external providers. Record who publishes and maintains every component.
Oracle's FEC instructions illustrate the value of that detail. They name France Localization and Tax Reporting Framework, and explain that FEC can be generated with or without SuiteTax. The evidence establishes a particular export path and its dependencies. It does not establish every French reporting requirement. Oracle, generating France FEC
Request a diagram showing how the proposed solution reaches the recipient. Identify each contract boundary. A feature included in the ERP can still depend on an external transmission service. Ask who pays for that service, who monitors it and who resolves failures between suppliers.
Request evidence at the right level
Use a country-specific setup document or released feature note when one exists. Record its product version and publication date. Treat a roadmap as an announcement with a delivery dependency.
A marketplace listing can establish that a partner markets an integration. Ask for the supported country scenario and workflow separately. A vendor's global customer count, language list or currency list cannot answer whether a particular statutory file is available.
Use these internal labels:
- Documented: first-party material describes the proposed scenario and product context.
- Demonstrated: the supplier has shown the scenario with retained outputs.
- Accepted: your team has reproduced the agreed test in the proposed configuration.
- Unresolved: evidence is missing, contradictory or outside the proposed scope.
These are project labels. They are not tax-authority certifications.
Give suppliers the same acceptance pack
Prepare anonymized transactions that represent your actual operation. Include an ordinary sale, a purchase, a credit or correction, a foreign-currency transaction and an invalid identifier. Add prepayments, self-billing, retail consolidation or industry cases only where the business uses them.
For each case, require the source transaction, generated document, validation result, external response and resulting ERP status. Record the person who can reproduce the test. Test the actual deployment and integrations being purchased.
Make failure handling part of the demonstration. Let a submission time out. Ask the operator to establish whether it was accepted before retrying. Reject a document and follow the correction procedure. A supplier who shows only a successful invoice has not demonstrated the complete operating process.
Use the acceptance-test guide to build the full pack.
Reconcile the financial result
Trace accepted documents back to the ledger and the relevant return or audit population. Record excluded documents and timing differences. Require an explanation for every difference, rather than expecting unrelated totals to match automatically.
For a file export, compare opening balances, movements and closing balances where applicable. For an invoice flow, compare document counts and amounts by status. Check that a retry cannot create an extra financial document or duplicate reporting.
Have the local accounting owner review the output. Successful transmission and correct accounting answer different questions.
Put the unresolved work into the contract
Specify the outstanding feature, accountable supplier, delivery date, acceptance criterion and remedy if delivery fails. Price third-party subscriptions, implementation services and recurring maintenance explicitly.
Ask who updates country mappings, who owns credentials and who monitors authority changes. Agree support hours, incident escalation and the export available when the contract ends. Require the supplier to identify changes outside its support scope.
Use a comparable cost scenario for all bidders. Include the same entities, transaction volumes, document directions, storage duration and support needs. A low per-invoice fee can hide setup work or charges for inbound documents and archived evidence.
Make the purchase decision reviewable
The decision pack should contain the obligation register, component list, evidence records, test results, reconciliation, commercial scope and unresolved items. Obtain separate acceptance from the finance owner and the technical owner.
If a material requirement remains unresolved, choose a funded remedy or exclude the affected operation from go-live. Record that decision in plain language. A project cannot remove an obligation by leaving it out of the implementation plan.
Your final acceptance sentence should name what was accepted: "The tested configuration generated and submitted the agreed document types for entities A and B using release C and provider D." That statement is useful when the next release, new country or provider change arrives.
Before you sign
- Finance has approved the business model and obligation scope.
- Every material capability identifies its edition, release and dependencies.
- Your team can reproduce normal and failed cases.
- The outputs reconcile to the relevant financial records.
- Contracts assign maintenance, support and exit responsibilities.
- Every unresolved requirement has an owner and a recorded decision.
This guide provides a procurement method. It does not certify a vendor or replace an applicability assessment for your operation.
Related on this site
- Country pages: key facts with sources
- E-invoicing matrix: country × ERP support
- All 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 – abbreviations and terms used in these guides (SAF-T, Peppol, CTC, EN 16931, IFRS and more).
Page last updated: · Markdown version