What ViDA asks of a self-hosted ERP before 2030
ViDA does not switch on one EU-wide invoice format in one go. Member States were allowed to introduce national e-invoicing mandates from April 2025, and cross-border B2B digital reporting follows from July 2030. For a finance or IT lead running Odoo or ERPNext in their own cloud or data center, the ERP work is planned country by country. Each country where the company issues or receives B2B invoices sets its own timing and channel, so the changes land in a different sequence for each. Start by listing every selling and buying country, the legal entities that invoice in each, and the date each country's rules apply. Confirm those dates with local tax advisers, because the EU framework does not give them.
The control facts that matter most sit around the invoice rather than only inside it. Where invoice data is hosted, who can see it, and whether a support engineer in a third country can view it on screen all bear on the GDPR. The EDPB Guidelines 05/2021 treat remote access from a third country, even only to display data for support, as a transfer, and storage in a cloud outside the EEA as a transfer as well. Decide whether the application server, database, backups, log stores and vendor support sessions stay inside the EEA, and record that decision before the first country goes live. Also confirm your upgrade path. On-premise Odoo upgrades require an Enterprise subscription, so an ERP version that leaves support would add an unplanned compliance change.
Two more obligations shape the plan. The EU Data Act gives customers of data processing services the right to switch to another provider or to on-premises infrastructure, and bans switching charges from 12 January 2027, so the contract with any hosting or managed-service provider should reflect those rights. Article 32 of the same regulation also asks providers to prevent third-country governmental access to non-personal data held in the Union. Before the first mandate country goes live, ask your implementation partner for a change log for each release, a test database for each country's format, and a rollback path. Each national step should be testable and auditable on its own.
Mapping ViDA obligations to ERP functions and configuration
This table maps the control requirements that apply to an ERP holding invoice data to the functions the system must perform and how to configure them in Odoo or ERPNext. Read each row as a question to answer before your ViDA project plan is signed off. The main takeaway is that data location, provider exit and access control decide architecture long before format mapping starts.
| Requirement | What the function must do | How to configure it in Odoo or ERPNext |
|---|---|---|
| Data location and transfers (GDPR Article 44, EDPB Guidelines 05/2021) | Know where invoice data with personal data is stored, backed up and accessed, including remote support sessions from outside the EEA, because these count as transfers. | Self-host in your EU infrastructure, restrict database and backup locations in writing with the hosting partner, and disable or log remote administrative access paths. Confirm the exact transfer analysis with your data protection lead. |
| Processor and third-country exposure (EDPB Guidelines 05/2021, Example 12) | Assess whether an EU processor is subject to third-country law with extraterritorial reach before engaging it, since complying with a foreign authority request would be a transfer. | Record processor and sub-processor locations in your register. For Odoo Online or Frappe Cloud, ask the vendor to confirm hosting regions and support access locations in writing. |
| Provider exit and portability (Data Act Articles 25 and 29) | Keep the ability to move from a data processing service to another provider or on-premises infrastructure, with notice and transition terms the contract must state. | Keep a regular export of invoices, partners, tax IDs and archive files in open formats. Use Odoo's database and Community edition options or ERPNext's Data Import and full site backups to keep a tested restore path. |
| Access to data held in the EU (Data Act Article 32) | Ensure providers take measures against third-country governmental access to non-personal data held in the Union where this conflicts with EU or national law. | Confirm with each hosting and support provider which technical and contractual measures apply. Limit administrator accounts and keep keys for backups under your control. |
| Change management (16 CFR 314.4, applies only to covered financial institutions) | Control changes to ERP code, tax tables, numbering and mapping rules, with testing and approval before production release. | Use a staging copy created by database duplication with neutralization in Odoo or a separate Frappe bench for tests. Route tax and format updates through a documented approval step. Restrict Server Scripts in ERPNext to approved change records. |
| Multi-factor authentication (16 CFR 314.4, covered financial institutions only) | Require multi-factor authentication for anyone who accesses the ERP or invoice systems. | Connect Odoo or ERPNext to your identity provider through LDAP or social login, and enforce the second factor at that provider. Confirm the method each platform supports for your version. |
| Activity logging (16 CFR 314.4, covered financial institutions only) | Record authorized user activity on invoice issuance, changes to supplier and customer master data, and inbound invoice handling. | Enable and retain Odoo chatter and audit tracking on invoice and partner models. In ERPNext, use Version tracking and export logs to your central logging system. Confirm retention periods with your compliance team. |
| Archive and records retention (SEC Rule 17a-4(b), only where the buyer is a broker-dealer) | Preserve bills receivable and payable and business communications for the periods the rule sets, with the first years easily accessible. | Store issued and received e-invoice XML and PDFs with the ERP record ID in write-once or access-controlled storage. Test restores of archived files, not only database backups. Most companies outside broker-dealers should confirm retention with their national tax rules instead. |
Odoo or ERPNext: which fits a country-by-country rollout
Odoo Community is published under LGPL-3.0 and forms the open source core, while Enterprise is the licensed edition that adds features such as Studio customization, version upgrades and hosting options. For a self-hosted rollout, the practical route is usually Enterprise on-premise, because the Odoo pricing page states that only the Custom plan can be hosted on Odoo.sh or on-premise and that only Custom includes multi-company, Odoo Studio, external API access and custom modules. Those last items matter when a group needs one entity per country with its own tax configuration.
- Support window: Odoo 20.0 has standard support planned until September 2029, and standard support includes security patches, so confirm how that window lines up with your country rollout dates.
- Upgrade obligations: Odoo's upgrade service requires an Enterprise subscription for on-premise use, and Community has no access to it. Plan a tested upgraded database before each major move.
- E-invoicing modules: Confirm, for each country, whether the e-invoicing or Peppol functionality is included in your edition and whether it depends on an Odoo-hosted proxy.
- Connectivity: Verify whether each target country's network or access point can be reached from your self-hosted instance without relying on a vendor proxy.
Ask the implementation partner to document which Odoo modules and external connections each country needs before the upgrade calendar is fixed.
ERPNext is licensed under GPL-3.0 and built on the Frappe Framework, which is MIT-licensed. You can self-host it with the bench command line tool, with Docker Compose from the frappe_docker repository, or on Frappe Cloud. The frappe_docker project provides production images with services for MariaDB, Redis, background workers, the scheduler, Socket.io and Nginx, but its single-file demo setup is intended only for short-lived evaluation. Frappe's supported versions page lists version 16 as supported until the end of 2029, and version 15 until the end of 2027, so version 16 is the better anchor for a multi-year rollout.
- Server Scripts: From version 15 onward, Server Scripts are disabled by default and must be enabled with the server_script_enabled setting. Country-specific validation logic that relies on them needs that setting confirmed in your environment.
- Warranty coverage: Frappe states that customers must be on a listed version and subscribed to a matching Frappe Cloud support plan to receive warranty coverage from Frappe.
- Release cadence: Both supported major versions receive frequent minor releases, so plan a test cycle for each.
- Connectivity: Confirm access point and network options for each country, since ERPNext does not replace the need for an approved connection where a mandate requires one.
- Implementation: The ERPNext pricing page states that implementation is available through certified partners, so ask for the partner's specific credentials in writing.
Confirm which ERPNext version and e-invoicing app combination each country will run before committing the rollout plan.
Both platforms move on fixed support calendars, and a country rollout that spans several years will cross at least one major version. Odoo On-premise standard support covers the first three years after a major release, and extended support is limited to Odoo.sh for select versions and on-premise, with security patches only during standard support. On Odoo Online and Odoo.sh, major upgrades are mandatory every two years, so the upgrade calendar must be set against the mandate dates for each country.
- Test copies: Odoo documents database duplication with neutralization for test copies, which should be used before every upgrade and every e-invoicing change.
- Version dates: Odoo 18.0 standard support runs until September 2027 and Odoo 19.0 until September 2028, so an older base may need to move earlier than the country schedule suggests.
- Frappe end of life: Version 14 reached end of life on January 31, 2026, so any legacy ERPNext installation needs a migration plan.
- Change control: Record every module version, country configuration and access point setting in the change log so auditors can trace the state at any date.
- Partner testing: Agree a written test plan with the partner that covers each country's formats and trading partners.
Ask the partner to map each platform's support end dates against your planned country go-live dates in a single schedule.
Because national mandates differ in timing, format and network, the ERP change should be planned one country at a time rather than as a single global project. Each country needs its own master data, tax configuration, output format and validation step, and some countries also require a registered connection to a government platform. The choice between Odoo and ERPNext should be tested against those country requirements, not against general feature lists.
- Master data: Tax IDs, Peppol identifiers where used, and customer and supplier records must be validated before the first live transmission.
- Entity structure: If you run one legal entity per country, confirm how each platform separates company data, chart of accounts and tax rules.
- Customization limits: Odoo Custom plan features and ERPNext Server Script settings determine how far country logic can be built into the platform itself.
- Dependency review: Note any country where the e-invoicing function relies on a vendor proxy or a service provider, since that dependency changes exit and continuity planning.
- Pilot order: Start with the country whose mandate has the earliest effective date in your business.
For each country, ask the partner to confirm the module, connection and format route in writing before the build starts.
Which self-hosted platforms fit ViDA e-invoicing work
ViDA e-invoicing work depends on which ERP you run, how you connect it to a network, and who operates the access point. The cards below cover the main combinations, with the license, support and vendor questions to settle before you commit to a country-by-country plan.
Odoo Enterprise on-premise
Odoo Enterprise is the only Odoo edition that can run on your own infrastructure with the upgrade service, and the Custom plan is the one that can be hosted on-premise. Community code is LGPL-3.0, but the Enterprise source is not publicly available and requires a subscription. Confirm with Odoo which country e-invoicing modules and EN 16931 formats are included in your subscription, and whether they cover the countries you trade with. Standard support covers three years after a major release on-premise, so plan upgrades against that window.
Odoo Community with a custom connector
Odoo Community is LGPL-3.0 and gives you the core ERP without a subscription, but it has no access to the upgrade service. Any ViDA-ready invoice output, validation or network connection then has to come from a custom module or a partner-built connector that you own and maintain across Odoo major versions. Ask who owns the code, how the connector is tested against each new Odoo release, and who is accountable when a country format changes.
ERPNext on frappe_docker
ERPNext is GPL-3.0 and self-hosting it is free, while the Frappe Framework is MIT-licensed. The frappe_docker repository provides production Docker images and Compose files covering MariaDB, Redis, workers, the scheduler and Nginx, but its single-file demo is for short-lived evaluation only. Check whether the e-invoicing formats and network connection you need exist as ERPNext apps or must be built, and confirm that the version you run is on Frappe's supported list, since version 14 has reached end of life.
Access point or service provider
Whichever ERP you choose, the network connection to trading partners is usually a separate component: a Peppol access point, a national clearance platform or a service provider. Odoo's Peppol module depends on a proxy, so confirm whether that proxy is acceptable for your data location and contract terms. Ask the provider for its accreditation status, supported countries and formats, reporting and archiving, and what happens to data when you exit.
Validation and archiving layer
Your ERP output must pass validation against the applicable EN 16931 syntax and national rules before it leaves your system, and inbound invoices need the same checks. Plan a validation step that is independent of the ERP's own output, with logs that record each rejection and resubmission. Confirm how the chosen platform stores signed or structured invoices and how long they remain retrievable, since record retention rules differ by country.
Country change management
Each national mandate applies on its own date and format, so the platform must allow country modules to be enabled, tested and rolled back separately. Build a register of which country rules each ERP version supports, and assign an owner who reviews mandate changes before each release. Ask vendors to show how they test a new country module against your master data, such as tax IDs and Peppol identifiers, before it reaches production.
How to sequence ERP changes country by country
The sequence turns a list of countries into a tested, country-by-country ERP change that can be cut over and archived without guessing at mandate dates or formats. Each step ends with a check the team can verify before moving on.
Inventory the countries and document flows in scope
Finance and tax leads list every country where the company issues or receives B2B invoices, along with the entities, ERP companies and document types involved (sales invoices, credit notes, purchase invoices and any corrections). IT maps which Odoo or ERPNext instances, modules and integrations touch each flow. The output is a register that names each country, entity, document flow and system owner. The step is done when every invoice stream has an owner and no country is recorded as 'to be confirmed' without a named person responsible for confirming it.
Confirm mandates and formats with each authority
For each country in the register, the tax or legal team confirms with the national tax authority or its published guidance whether an e-invoicing mandate applies to the company, from which date, which structured format is required, and which network or channel must be used. Do not take dates or format rules from this page or from a vendor summary alone, because national rules change and the authority is the source of record. The output is a signed-off country sheet with the authority source, the effective date as stated by that authority, and the reviewer's name. The step is done when every country has a sourced entry.
Fix tax IDs and electronic identifiers in master data
Master data owners correct customer, supplier and company records so that VAT numbers, national registration numbers and any Peppol or national participant identifiers are complete, validated and in the right fields. Duplicate partners and inconsistent country codes are merged or corrected. Odoo and ERPNext configurations for taxes, units, currencies and payment terms are reviewed against the format rules confirmed in the previous step. The output is a master data exception report with zero open items for the in-scope countries. The step is done when a sample extract of partners passes the validation checks the team defined.
Build issuance and inbound processing for one country
The ERP team builds the outbound invoice output in the format required for the first country, and the inbound path that receives, parses and posts supplier invoices in that format. Mapping from ERP fields to the structured format is documented, and each rule is traced to the authority specification. Error handling covers rejected documents, resubmission and the status each document carries in the ERP. The output is a tested build in a non-production environment with a mapping document. The step is done when test invoices in the first country are generated, validated against the official validation tooling named in the specification, and parsed back into the ERP without manual edits.
Repeat build and test for each remaining country
The team repeats the build and test cycle country by country, reusing shared mappings where the formats match and isolating country-specific rules, such as additional fields, tax categories or network connections. Regression tests confirm that changes for one country do not break invoices already in production for another. The output is a country test log with the sample documents, validation results and open defects per country. The step is done when every country in scope has a passing test log and a named owner for ongoing changes to its rules.
Run partner testing with trading partners and providers
Where the company depends on a trading partner, access point, service provider or state platform to exchange documents, it runs test exchanges with those parties before go-live. Test cases include standard invoices, credit notes, rejected documents, duplicate submissions and inbound documents from partners that do not follow the expected format. Responsibilities for each error path are agreed in writing. The output is a partner test report and a runbook that names the contact and escalation route for each partner. The step is done when test exchanges succeed in both directions and each error case has a documented outcome.
Cut over country by country and monitor
Go-live is staged so that each country moves to the new process once its tests and sign-off are complete, with a rollback plan and a defined monitoring window. Operations watch rejection rates, unprocessed inbound documents, failed transmissions and reconciliation breaks between the ERP ledger and the transmitted documents. Changes after go-live follow the change management process, with the tax team approving any change to mappings. The output is a cutover record for each country and a monitoring report. The step is done when each country has been live through its monitoring window without open critical defects.
Archive documents and evidence for each country
Issued and received structured documents, their validation results, transmission status and the related ERP records are stored in a way that meets the retention and accessibility requirements confirmed for each country and for the company's own record-keeping obligations. Archive access is tested by restoring a sample of documents and checking that they can be read with the original metadata. Retention periods are taken from the national rules confirmed in step two, not assumed. The output is an archive design per country and a restore test report. The step is done when a sampled restore succeeds and the compliance owner signs off the evidence pack.
What auditors and tax reviewers ask to see
This table lists the evidence items a tax reviewer or assessor is likely to request for a self-hosted ERP issuing and receiving ViDA-aligned e-invoices, what each item shows, and which part of the stack produces it. Use it to decide what must be logged, retained and owned before go-live, not after the first review. DeployOpen prepares this evidence, but independent auditors and tax authorities make the assessment and issue any reports.
| Evidence item | What it shows | Which component produces it |
|---|---|---|
| Validation logs against EN 16931 | Each outgoing and incoming invoice was checked against the EN 16931 semantic model and syntax rules, with pass or fail results and reasons | ERP e-invoice generation module plus the validator run in the pipeline or access point |
| Retained invoice XML and PDFs | The exact structured file and human-readable copy that were issued or received, unchanged since issue, with retention periods matching local rules | ERP document store, archive or records system with write-once or hash controls |
| Change records for ERP and format updates | Who changed the ERP version, mapping rules, tax codes or format templates, when, why, and what was tested before release | Git or change tickets, ERP upgrade logs, test database results and release approvals |
| Access logs and MFA records | Which users created, approved, changed or exported invoices, and that each sign-in for those roles used multi-factor authentication | ERP audit trail, identity provider sign-in logs and role assignment history |
| Transfer assessments for hosting or support outside the EEA | Whether any personal data is stored or viewed from a third country, the legal basis, safeguards and the documented risk assessment | Hosting contract, sub-processor list, remote support procedure and the controller's transfer impact file |
| Exit and portability plans under the Data Act | How invoice data, documents and configuration can be exported and moved to another provider or on-premises infrastructure, with timelines | Export scripts or database dumps, data schema documentation and a tested runbook kept with the ERP |
| Partner test records | That invoices exchanged with trading partners or networks were tested end to end, including rejected and corrected cases | Test environment logs, network or access point acknowledgements and defect tracking |
What the ERP alone does not satisfy
The ERP handles invoice creation, numbering and data storage, but several ViDA obligations sit outside it. Each card names one limit and the work you must add to close it before a country goes live.
Accredited access point connection
An ERP can produce a Peppol-ready invoice file, but it does not connect your company to the network. Sending and receiving through Peppol needs an access point, a participant identity and certificates that meet the network's accreditation rules. Decide whether you will run your own access point, buy one from a service provider or use an ERP vendor's network, then confirm that the route meets the rules in each country where you trade.
Tax treatment decisions
The ERP applies the tax codes you configure, but it does not decide whether a sale is taxable, zero-rated, exempt or subject to reverse charge. Those answers depend on place of supply, the buyer's status and the goods or services sold. Ask your tax advisor to sign off the mapping for each country and product group before go-live, and keep that decision log with the configuration so auditors can trace it.
Validation by the receiving side
Generating an EN 16931 file does not mean the file will be accepted. The receiving party's access point, a national platform or the tax authority can reject an invoice for schema or business rule errors the ERP did not flag. Build validation into the send path, route every rejection to a queue with a named owner, and test rejections with each trading partner. Confirm which rules each network enforces and how it returns errors.
Cross-border reporting from 2030
The ERP can store the invoice data that cross-border reporting will need, but it does not submit reports to tax authorities. Digital reporting for cross-border B2B transactions starts in July 2030, and the channel, data fields and submission rules will come from national implementation. Map which records must feed reporting, check whether your ERP data model captures them, and plan a separate reporting interface that you can change as rules are published.
Transfer risk for third-country hosting
If an ERP vendor's cloud, a managed host or a remote support engineer sits outside the EEA, the invoice data you process may be a transfer under Chapter V of the GDPR. The EDPB treats remote access from a third country as a transfer, even when someone only views data on a screen. Map where each invoice field is stored and who can see it, document the transfer mechanism, and assess third-country government access before engaging a processor.
Record retention policy
An ERP keeps records until someone deletes them, but it does not decide how long invoices must be kept, where archived copies sit or how they stay unaltered. Those rules come from national tax law. For example, a US broker-dealer must preserve certain business records for three years under SEC Rule 17a-4(b), which shows the kind of rule you need to map. Write a retention policy per country, set archive formats and access rights, and test restoration before relying on the archive.
Questions buyers ask before preparing ERP for ViDA
What does preparing self-hosted ERP for ViDA cost, and what drives it up?
The cost moves most with the number of countries, legal entities and ERP instances in scope, followed by how much custom logic the invoice flow needs. Several cost components recur across projects: the ERP licence or subscription, the partner's build and testing work, access point or network fees, and the maintenance that follows when formats and national rules change. ERPNext is free under GPL-3.0, and the ERPNext pricing page lists self-hosting as free, so the spend sits in hosting, implementation and testing. With Odoo, on-premise and Odoo.sh hosting require the Custom plan, which is priced per user per month, so user count feeds the recurring line. Ask every quote to separate one-time build work from recurring operations, and to price each country and each network connection on its own line.
How long does ViDA preparation take, and what depends on the country list?
The duration depends on the country list, the format scope and the ERP version work, and no duration is reliable until the scope is written. The ViDA timetable allows national mandates from April 2025 and brings digital reporting for cross-border B2B from July 2030, so each country on your list may start at a different point. Each country adds its own format and network checks, partner testing and sign-off. Master data and connectors can often be reused, so the work for a second country is usually smaller than the first. Version work can come first: if your ERP is close to the end of standard support, an upgrade may need to happen before the connector is built. Ask the partner to show the critical path, the steps that depend on your team and the dates your trading partners must meet.
What must our company provide before a ViDA project starts?
Your company must supply the data and decisions that a partner cannot invent: complete master data, test trading partners and a named tax owner. Expect to provide:
- Legal entity records with VAT numbers, registration numbers and addresses for every issuing company
- Customer and supplier records with tax IDs and, where used, Peppol participant identifiers
- Test trading partners in each country who will exchange sample invoices and agree on error handling
- A named tax owner who signs off rate mapping, exemptions and how invoices are classified
Without these, the connector can pass technical tests and still reject live invoices. Confirm early which records are incomplete, because data cleanup can become the longest task that nobody planned for.
Can an internal team prepare Odoo or ERPNext for ViDA alone?
An internal team can manage the work alone when it covers a single country, runs a supported ERP version and includes at least one engineer who has built and maintained integrations. The answer changes as scope grows, because the hard parts are format validation, the network connection, partner testing and keeping pace with rule changes after go-live. Platform details also matter for custom logic. ERPNext Server Scripts are disabled by default from version 15 and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them. On Odoo, the upgrade service that moves a database to a newer version is available to Enterprise subscribers running on-premise. Assess the team against these points honestly, and buy only the missing skill as a fixed-scope piece.
Does self-hosting an ERP reduce cross-border transfer risk under GDPR?
Self-hosting keeps the ERP in infrastructure you choose, but it does not remove transfer risk by itself. Under the EDPB's Guidelines 05/2021, remote access from a third country, even just displaying data on a screen for support, counts as a transfer, and so does storage in a cloud outside the EEA. Support contracts and hosting providers therefore matter as much as the server location. The guidelines also state that using an EU processor subject to third-country law is not itself a transfer, but complying with a third-country authority request would be, so that exposure should be assessed before engagement. Map who can reach the system and from which countries, and get legal advice on the personal data that appears in invoices, such as contact details of sole traders.
What should a fixed-scope ViDA quote include?
A fixed-scope quote should name the work, the deliverables and the exclusions before any work starts, so you can compare offers on the same basis. Ask that it cover:
- The countries, invoice formats and networks in scope, with the ERP instances and legal entities that use them
- Any ERP version upgrade or hosting change needed first, and who carries its test cycle
- Connector build, validation, archiving and error handling for inbound and outbound invoices
- The partner testing plan, acceptance criteria and who signs off each step
- Monitoring, change handling as mandates evolve, and support terms after go-live
- Exclusions, assumptions about your master data and what triggers a change request
DeployOpen agrees scope, deliverables and timelines in writing before work starts and does not publish a price list, so its quote follows from the written scope.
Does our Odoo or ERPNext version affect ViDA readiness?
Yes, the ERP version sets the upgrade path and therefore the timeline. Odoo 17.0 standard support ended in September 2026, Odoo 18.0 runs until September 2027 and Odoo 19.0 runs until September 2028. Odoo's standard support covers the first three years after a major release, and Odoo Online and Odoo.sh require major upgrades every two years. For ERPNext, version 14 reached end of life on January 31, 2026, version 15 is planned to be supported until the end of 2027 and version 16 until the end of 2029. Confirm which version the partner will build against and whether a supported upgrade must come first. Upgrading a live ERP at the same time as adding e-invoicing adds to the test scope, so plan the two as separate, sequenced stages.
How DeployOpen scopes and delivers ViDA readiness for self-hosted ERP
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source ERP inside the client's own infrastructure. For ViDA readiness, that means turning the country-by-country e-invoicing obligations into a written scope for Odoo or ERPNext, with each change tested before it reaches production.
How we scope
- Inventory which EU countries, legal entities and invoice flows the written scope covers, and which are deferred.
- Confirm the ERP version, edition and support status, including Odoo's standard support dates or ERPNext's supported major version.
- Agree in writing which EN 16931 formats, networks and master data fields are in scope before work starts.
How we build
- Configure tax IDs, Peppol identifiers and customer master data needed for compliant invoices in each in-scope country.
- Integrate the ERP with the chosen access point or national platform, using the connection model the scope defines.
- Test outbound and inbound invoices with trading partners in a non-production copy before any production change.
How we hand over
- Document configuration, validation rules, error handling and archiving steps so your team can operate the setup.
- Deliver a country-by-country change log that records what changed, when, and who approved it for audit review.
- Provide test evidence and runbooks, while being clear that independent auditors, not DeployOpen, assess compliance.
How we support
- Offer ongoing support, upgrades and monitoring as a retainer, which covers changes when national rules or ERP versions move.
- Plan ERP upgrades alongside e-invoicing changes, testing the upgraded database before it goes to production.
- Review the written scope on a set schedule so new countries or digital reporting obligations are added deliberately.
