Self-hosted accounting software for EU data sovereignty

Which GDPR, transfer and record rules shape the accounting build

This table maps each transfer, access and portability rule to what it means for where the ledger is hosted, who can reach it for support, who holds the keys and what the processor contract must say. Read each row as a question to answer before the hosting decision is made. The main takeaway is that the support and administration path matters as much as the storage location, because remote access from outside the EEA can itself count as a transfer.

Which Odoo edition and hosting model keep finance data under your control

Which open-source platforms fit an EU sovereignty brief and why

Three platform families dominate self-hosted accounting for EU sovereignty briefs, and each one puts the hosting, licensing and upgrade work in a different place. The cards below set out the license, the hosting path that keeps ledgers and payroll postings on EU infrastructure, and the constraint that most often changes the decision.

How the EU sovereignty rollout runs from data mapping to first close

The sequence turns a sovereignty requirement into a documented data map, a hosting and access decision, tested EU infrastructure and a first close that finance can prove was restorable. Each phase ends with a named artifact that auditors, data protection officers and the board can review.

1. Map data categories and transfer paths

   The finance lead, the data protection officer and the DeployOpen team list every data category that touches the ledger: customer and supplier records on invoices, bank details, employee identifiers and payroll postings, plus the logs and backups that hold copies of them. For each category, document where it is created, stored, backed up and viewed, and who outside the company can reach it. Remote access from a third country, including screen sharing during support, counts as a transfer under the EDPB guidance, so include support sessions in the map. The step is done when the data inventory and transfer register are signed off by the data protection officer.

2. Choose edition and hosting location

   Select the edition and the hosting model before any contract is signed, because the choice decides who operates the database. Odoo's pricing page states that only the Custom plan can be hosted on Odoo.sh or on-premise, so confirm the edition and hosting options in writing with the vendor. For ERPNext, confirm whether Frappe Cloud or a self-managed Docker or bench deployment fits the register. Ask each vendor to confirm the EU locations of any hosted component. The step closes with a written hosting decision that names each region, each operator and each sub-processor.

3. Agree processor terms and the access model

   Legal and procurement work with the hosting provider and the implementation partner to paper the roles, the data processing terms and the support access procedure. Terms should cover where data is stored and backed up, which sub-processors may act, how requests from foreign authorities are handled and assessed, and how a customer exits to another provider or on-premises infrastructure. The access procedure defines who may open a support session, how it is approved, how it is logged and how screen sharing is limited. The step is complete when the signed terms and a written access procedure exist and both sides have reviewed the authority-request clause.

4. Build and harden in EU infrastructure

   DeployOpen installs the chosen platform in the client's EU accounts or data centers and configures encryption in transit and at rest, multi-factor authentication for administrative and user access, and access logging. Separate production, test and backup environments so that test copies carry no live personal data unless neutralized. Document key custody: who holds the encryption keys, where they are stored and how rotation is performed. The step closes with a tested environment, a hardening record and a key management record that lists every key owner and location.

5. Migrate and reconcile opening balances

   The finance team and DeployOpen load the chart of accounts, customer and supplier master data and opening balances from the legacy ledger, using a documented import and a reconciliation workbook. Each opening balance is tied to the closing trial balance of the source system, and every rejected record is logged with its cause. Migration copies used for testing are created from the production database with neutralization of personal data. The step is done when the migrated trial balance matches the source for every account and the reconciliation is signed by the controller.

6. Run the first close with restore tests

   The finance team runs its first month-end close on the new environment while DeployOpen monitors access logs, job schedules and backup jobs. In parallel, the team performs a restore of the database to a separate EU environment, confirms record counts and balances against the production ledger, and records the time and the result. The restore test is repeated after each significant change, such as an upgrade or a new integration. The step closes when the close is signed off and the restore evidence, including the logs of the test, is filed with the transfer register.

What buyers ask before hiring help for EU-hosted accounting

Which evidence proves EU residency, access control and transfer assessment

This table maps each piece of evidence an assessor will ask for to the system that produces it and the owner who keeps it current. Read it as a checklist for the first audit cycle, not as a list of tools to buy. DeployOpen prepares this evidence, but independent auditors and regulators decide whether it is sufficient.

Which questions to put to an implementation partner on EU hosting

How the EU-hosted deployment is built and operated

This sequence turns a chosen edition into an EU-hosted system where login, admin access, backups and updates are controlled by the buyer and documented well enough to show a regulator or auditor how the ledger is run.

1. Confirm the EU hosting boundary and edition

   Before any build, the buyer and the implementation partner agree in writing which accounts, data centers or regions will hold the application servers, database, file storage, backups and logs, and which edition is in scope. Odoo hosting on Odoo.sh or on-premise is limited to the Custom plan according to Odoo's pricing page, so the edition decision comes first. Done means a signed hosting map lists every location where ledger, invoice or payroll posting data can be stored or displayed, including support tooling. Confirm with the vendor that the chosen edition and hosting option are available in the target EU region.

2. Provision the EU environment in buyer accounts

   The implementation partner builds the environment inside the buyer's own cloud tenancy or data center, using infrastructure as code so that the configuration is versioned and reviewable. For ERPNext, this can use the frappe_docker production images and Compose files, which include MariaDB, Redis, workers, the scheduler and Nginx; the single-file demo setup is intended for short-lived evaluation only. Done means the buyer holds the administrative credentials to the cloud account and the build can be reproduced from the repository. Ask the partner which staff can reach the production tenancy and how that access is logged.

3. Connect login to the buyer's identity provider

   Users sign in through the buyer's directory rather than local passwords. Odoo documents LDAP authentication, and ERPNext documents LDAP integration and social login keys, so the partner configures the directory binding, group mapping and deprovisioning path against the identity provider the buyer already runs. Done means a test leaver account loses access to the ledger on the next authentication attempt, and the mapping of directory groups to finance roles is written down. Confirm that multi-factor authentication is enforced at the identity provider, since the FTC Safeguards Rule requires it for any individual accessing an information system.

4. Separate administrative and user access paths

   Finance users reach the application through the normal web address, while database administration, server shell access, deployment pipelines and the Odoo or Frappe administrator functions run through a separate, restricted path with its own named accounts and session logging. Server-side scripting in ERPNext is disabled by default from version 15 and must be enabled explicitly, so the partner records who is allowed to enable it and why. Done means an access matrix shows which roles can reach each path, and a test shows that an ordinary finance account cannot open the database or the server console.

5. Replicate and test backups inside the EU

   Database dumps, file attachments and configuration snapshots are written to storage in the same EU jurisdiction as production, encrypted at rest, with keys held by the buyer. Backup copies are not placed in a third-country region for convenience or disaster recovery unless the transfer analysis has been completed first, because remote access from a third country is itself a transfer under the EDPB guidance. Done means a restore of the most recent backup has been completed into a separate environment, the restored copy has been checked for ledger totals, and the restore time and location are recorded in the runbook.

6. Stage every upgrade in a test copy first

   The partner builds an update calendar tied to the vendor's support windows. Odoo standard support covers the first three years after a major release, Odoo 20.0 is planned for standard support until September 2029, and Odoo Online and Odoo.sh require major upgrades every two years. Frappe requires customers on a listed version, so ERPNext must stay on version 15 or 16 while those are supported. Each change is applied to a duplicate database with personal data neutralized, tested against reconciliation reports, then promoted. Done means a dated change record exists for each release, with test results and an approver.

7. Document operations and hand over evidence

   The partner delivers the runbooks, the hosting map, the access matrix, the identity configuration, the backup restore record and the change log in one controlled document set. The buyer's compliance owner signs off that the evidence matches the running system. Done means the buyer can answer, from documents alone, where each category of finance data lives, who can reach it, how it is recovered and how each release was approved. Any independent assessment or audit is performed by the buyer's chosen auditor, since DeployOpen prepares evidence but does not issue certifications.