Self-hosted subscription billing for EU data sovereignty

Why self-hosted subscription billing for EU data sovereignty changes the build

Self-hosting Kill Bill or Lago inside EU infrastructure the company controls is the main route to removing the transfers a billing SaaS creates, but only if support access and payment gateway flows are designed in from the start. A billing SaaS typically holds invoice, contact and usage data in a vendor-controlled environment, and that data can leave the EEA through hosting location, remote support sessions or vendor-side processing. Under the EDPB's Guidelines 05/2021 (version 2.0), storage in a cloud outside the EEA is a transfer, and so is remote access from a third country even when the person only views data on a screen. A self-hosted deployment removes the storage path, but an engineer in another country who opens a production database for troubleshooting recreates the transfer. The build therefore has to decide who holds administrative access, from where, and under which logged and time-limited procedure.

The platform choice matters less than three questions: where the data sits, who can see it in the clear, and which legal exposures remain after the move. Kill Bill and Lago both store customer, invoice and event data in a database the company operates, so the design work moves to the surrounding parts: the payment gateway that receives card data, any tax or accounting plugin that copies invoice records to a foreign service, error monitoring and backup targets, and the vendor or implementation partner's own access to the environment. Each of these is a separate data flow to map. Even with everything in the EU, a US-parented provider with access to data in its control can still face a third-country request. The GDPR on EUR-Lex makes the controller responsible for these flows, so the exposure assessment belongs in the requirements, not after go-live.

Which GDPR and sovereignty requirements shape a self-hosted billing system

This table maps each GDPR, US and EU Data Act requirement that affects billing data to what it means for hosting location, admin access and support tooling. Read each row as a question to answer in your own architecture, then confirm the interpretation with your counsel and data protection officer. The main takeaway is that the hosting region alone does not settle sovereignty, because remote administration, support screens and vendor-side tooling can each create a transfer or a disclosure exposure.

Requirement	What it means for hosting location	What it means for admin access and support tooling
Article 44 GDPR, transfers including onward transfers	Personal data in invoices, contacts and payment references must stay in the EEA or move only under a valid Chapter V mechanism, and every sub-processor location counts	Each vendor, plugin and support provider that receives billing records must be mapped, with its own transfer basis documented
EDPB Guidelines 05/2021, remote access counts as a transfer	Hosting in the EEA does not help if staff or vendors in a third country can view the data	Screen sharing, remote consoles and log exports from outside the EEA must be treated as transfers and restricted or covered
Storage in a cloud outside the EEA	Backups, replicas, log sinks and analytics copies in a non-EEA region are transfers, not only the primary database	Confirm where observability, error tracking and email delivery tools store billing payloads
Article 48 GDPR, limits on enforcing third-country orders	A third-country disclosure order is not automatically enforceable in the EU, so the legal basis for any compliant disclosure must be checked case by case	Ask the vendor how it responds to foreign legal requests and whether it notifies the customer before disclosure
US CLOUD Act, 18 U.S.C. 2713	Data held by a US-linked provider can be subject to US preservation or disclosure orders wherever it is physically stored	Check the corporate control of each hosting, support and tooling provider, not only the data center location
EU Data Act Article 32, non-personal usage data	Usage events and meter data that contain no personal data still fall under the Article 32 safeguards for third-country governmental access	Usage pipelines and metering exports need the same provider review as personal data, plus documented measures to prevent conflicting access
Article 83 GDPR, fine tiers	Transfer infringements sit in the highest tier (up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher); security failures sit in the lower tier (up to EUR 10 million or 2%)	Use the tiers to prioritize: unreviewed remote access and transfers carry the greater exposure
Article 32 GDPR, security of processing	Encryption at rest and in transit, and tested recovery, apply in every region where billing data is held	Admin access needs strong authentication, least privilege, logging and reviewed support sessions, which the assessor will ask to see

What a billing SaaS exports outside the EU, and what you must verify

A billing SaaS moves personal data out of the EU in three ways, and the contract rarely says which of them apply. The first is storage: customer identity, billing contacts, invoice history, payment token references and raw usage events may sit in a cloud region outside the EEA, including in backups, logs and analytics copies the vendor makes. The second is remote access: a support engineer in a third country who opens a tenant to debug a failed renewal or a dunning run is making a transfer, even if they only view the screen. The EDPB's Guidelines 05/2021 treat both as transfers. The third is less obvious. An EU-based processor that is subject to third-country law with extraterritorial reach is not itself a transfer under Example 12 of those guidelines, but complying with a foreign authority's request would be. Ask the vendor to name the legal entity that holds the data, its parent company's jurisdiction, and where each usage and invoice dataset is stored.

The answer must be written into the data processing agreement, the subprocessor list and the transfer impact assessment, not inferred from a marketing page. Ask for the region of every production, backup and log store, the list of countries from which staff can access tenant data, the process for a government access request, and the transfer tool used for each flow. Standard contractual clauses under Commission Implementing Decision (EU) 2021/914 remain valid after *Schrems II* in Case C-311/18, but the EDPB's Recommendations 01/2020 also say that where a provider needs data in the clear and foreign public authority powers go beyond what is necessary and proportionate, no effective technical supplementary measure may exist. The EU-US Data Privacy Framework adequacy decision also rests on the appeal in Case C-703/25 P, so a contract that relies on it alone is exposed. Keep a second transfer basis documented and review it when the appeal is decided.

Kill Bill or Lago: which self-hosted billing platform fits an EU-only data estate

Each option below keeps a different slice of billing data, so the choice depends on where customer, invoice, usage and payment data must sit and who operates each component. Read the cards as a set: the billing engine, the metering layer, the payment orchestrator and the downstream ledger each need an EU location decision.

Kill Bill for plugin-driven billing

Kill Bill is an Apache-2.0 subscription billing and payments platform, and killbill-0.24.22 was published on September 29, 2026. It is a Java-based engine where payment gateways and tax logic typically attach as plugins, so the plugin set decides which third parties receive customer and invoice data. Confirm which plugins you need, where each one runs, and whether any sends card or invoice data to a provider outside the EU. Confirm also how the database holding accounts, invoices and payment history is hosted and backed up.

Lago for usage metering

Lago is a self-hostable option that teams often choose when usage-based metering is a priority. Its event ingestion and storage layer will hold every usage record tied to a customer, so the location of that store is the main sovereignty question. Confirm the current release notes and the supported deployment options before design, since this page does not rely on a version figure for Lago. Check where event data, customer identifiers and any analytics exports are stored.

Hyperswitch for EU payment routing

Hyperswitch is an Apache-2.0 composable payments platform, and v1.128.0 was published on October 16, 2026. Self-hosted, it can keep routing logic and the card vault inside your EU environment, which narrows what your billing platform must hold. Confirm which processors and vault providers you connect, because each connector sends data to its own infrastructure. Confirm also where the vault database and logs reside, and who can access them.

ERPNext or Odoo for ledger data

Billing output usually flows to a general ledger, and ERPNext (GPL-3.0) and Odoo Community (LGPL-3.0) are open source options that can run in your own infrastructure. The ledger holds invoices, tax lines and customer master data, so it inherits the same GDPR and transfer questions as the billing engine. Confirm whether the ERP is self-hosted or run by a vendor, where its backups go, and which add-on modules send data externally. Odoo Enterprise adds hosting options, so check that separately.

Apache Fineract only where banking applies

Apache Fineract is an Apache-2.0 core banking platform, and Fineract 1.15.0 was published on July 14, 2026. It belongs in this design only if your organization runs lending or deposit products that share customer records with the billing estate. For a pure SaaS subscription business, it adds a second sensitive system without a billing role. Where it is in scope, confirm how customer identity data is shared between Fineract and billing and which regulator-driven retention rules apply.

Deployment patterns that keep billing and usage data in EU infrastructure

Each pattern answers one question: who controls the infrastructure, where invoices and usage events are stored, and who can reach them. The cards work together, since a region choice means little if operators, vendors or payment and tax integrations can still pull personal data out of the EU. Use them to scope the design before selecting a hosting provider.

EU cloud account in an EU region

Run the Kill Bill or Lago stack in a cloud account your company owns, with workloads pinned to EU regions. Confirm the provider's backups, logs, monitoring, snapshots and support tooling stay in the same region, since a copy of a database snapshot in another region is still stored data. Ask the provider in writing where each managed service keeps its data and metadata.

Company-owned data center in the EU

Hosting the billing core in a facility you lease or own removes most provider-side access questions, but shifts patching, backups, physical access and capacity planning to your team. Document who holds keys to the hypervisor, storage and backup media. Confirm that offsite backup copies and disaster recovery sites are also inside the EU.

Restricted network for the billing core

Place the billing application, its database and the job workers in a network segment with no direct internet route. Only the gateway, tax engine and ledger endpoints needed for invoicing get outbound allow-listed paths through a controlled proxy. Review that every egress rule maps to a documented data flow.

EU-only database and object storage

Store invoices, customer contact records, usage events and generated PDFs in an EU-only database and object store, with separate buckets for each. Usage event volumes can be large, so check that analytics or reporting copies do not replicate to a non-EU warehouse. Keep retention rules in the catalog or configuration so deletion requests can be executed against every copy.

EU-hosted SSO and privileged access

Authenticate operators through an identity provider hosted in the EU, with multi-factor authentication and privileged sessions recorded. Keep the identity store, session logs and admin credentials under the same control boundary as the billing data. Confirm that the identity provider's own support and logging do not route user records outside the EU.

Time-limited, logged vendor and partner support

Grant vendor or implementation partner access only through a ticketed, time-boxed session that is logged and reviewed afterward. Where the support engineer is outside the EU and can view personal data on screen, that is a transfer under EDPB guidance, so decide in advance whether access is from inside the EU or covered by documented transfer safeguards. Write these rules into the support contract before go-live.

How a sovereignty-first billing rollout proceeds

The sequence starts by finding every place customer, invoice and usage data travels, then fixes the platform and hosting region, and only then migrates subscriptions, so the company can show where data sits and who can reach it at each stage.

Map data flows and build the transfer register
Inventory every system that touches billing data: the billing platform, databases, object storage, backups, logs, email and CRM sync, tax and accounting connectors, and each payment gateway. For each one, record the personal data categories, the storage and processing locations, every subprocessor, and where support staff or vendor engineers can view data remotely. Remote display counts as a transfer under EDPB Guidelines 05/2021, so support paths belong in the register. The output is a transfer register signed off by the data protection lead, with each third-country exposure marked for a decision.
Assess vendor and third-country access exposure
For each processor and gateway in the register, collect contractual terms, subprocessor lists, hosting regions and the vendor's stated position on government access requests. Compare these against the Article 48 and CLOUD Act questions that the register raises, and document whether a processor could be compelled to disclose data held in the EU. Where a technical supplementary measure cannot prevent that access, record the residual risk and the decision taken. The output is a vendor exposure memo that the legal and privacy owners approve before any platform choice is final.
Choose the platform and EU hosting region
Select Kill Bill or Lago, or a billing SaaS if the exposure memo supports it, based on the requirements in the register. Fix the hosting region, the cloud account or data center that the company controls, and the operating model for administrators, including who holds root access and where those staff are located. Confirm with the chosen vendor which components can run fully self-hosted without a required external service. The output is an architecture decision record naming the platform, region, administrator locations and any remaining external dependencies.
Deploy and harden inside the EU boundary
Build the environment in the approved region and enforce encryption in transit over external networks and at rest for all customer information, including database volumes, backups and exports. Enforce multi-factor authentication for every individual with access to any information system, and turn on logging of authorized user activity, with logs stored inside the boundary. Put change management on deployments and configuration. Consider a penetration test and vulnerability assessment as part of acceptance, since the FTC Safeguards Rule sets that expectation for covered institutions. The output is a deployment record with configuration baselines, encryption settings, MFA enforcement evidence and a test report.
Migrate catalogs, subscriptions and tokens with residency checks
Load the product catalog, price plans and tax configuration first, then migrate active subscriptions and invoice history in a test environment that uses the same region. Check that no staging copy, export file or analytics extract lands outside the approved boundary. For payment method data, confirm that only gateway tokens move and that the gateway relationship and its data flows are recorded in the register. Reconcile invoice counts, balances and open receivables against the source system before sign-off. The output is a migration report with reconciliation totals and a residency check log showing where each dataset was stored.
Cut over with a signed access review
Schedule the cutover with billing, finance and support teams, freeze catalog changes during the window, and switch traffic and gateway webhooks to the EU environment. Before go-live, run an access review that confirms each administrator, support engineer and service account has only the rights required, and that vendor remote access paths are either removed or documented in the register. Retire the old environment only after the retention plan for its records is approved. The output is a signed access procedure and a cutover record listing who approved access, what changed and what was decommissioned.
Review transfer exposure as the legal position changes
Set a recurring review of the transfer register, vendor terms and legal developments that affect the choices made. Examples include the pending appeal in Case C-703/25 P on the Data Privacy Framework, the Omnibus proposals that could amend the GDPR text, and the Data Act switching rights that apply from 12 September 2025. Each review updates the register, records whether any transfer conditions have changed, and triggers a new vendor assessment where needed. Certification and audit reports are not required by the GDPR, so the review evidence is the updated register, decision log and access records. The output is a dated review log that the privacy owner signs.

Evidence a DPO, auditor or regulator will ask for

This table lists the records a data protection officer, auditor or regulator typically asks for when billing and customer data sit on self-hosted infrastructure, and which component in the stack produces each record. Read each row as a question to answer before go-live, not as a document you receive once. DeployOpen prepares this evidence but does not issue audit reports or certifications, and Article 42 certification is voluntary and does not reduce the controller's or processor's responsibility.

Evidence	Component producing it	What the assessor checks
Records of processing (Article 30)	Data map covering Kill Bill or Lago, CRM, payment gateway and accounting sync	Each purpose, data category, recipient and retention period is recorded and matches the live systems
Transfer register with Chapter V basis	Vendor and sub-processor inventory maintained with the billing platform	Every third-country transfer, including remote support access, names its legal basis
Data location map per system	Infrastructure inventory for databases, object storage, backups and logs	Invoice, contact and usage data sit in the EU regions the company has agreed to use
Access logs for support sessions	Bastion or VPN logs, database audit logs and vendor remote session records	Who viewed personal data from outside the EU, when, and under which approval
Encryption configuration	Database, backup, message queue and TLS settings for the billing stack	Data is encrypted in transit and at rest, and key custody is documented
Breach-response runbook for Articles 33 and 34	Incident process owned by the controller and tested against the billing platform	Notification to the supervisory authority and data subjects can meet the Article 33 and 34 timelines
Vendor processing terms	Contracts with the platform vendor, hosting provider and any gateway or tax plugin	Article 28 terms, sub-processor lists and the exposure to third-country law are reviewed

What EU data sovereignty billing projects cost and need from your team

Does self-hosting Kill Bill or Lago remove all transfer risk?

No. Self-hosting removes the vendor-side paths, such as a SaaS provider storing or administering your customer data in a third country, but it does not remove every flow. Payment gateways receive cardholder and billing details, tax engines and e-invoicing services may receive invoice data, and any support provider with remote access to your systems can create a transfer under the EDPB's view that remote access from a third country is a transfer. Under GDPR Article 44, each of these flows needs a documented basis. Map every processor and sub-processor, confirm where each one stores and accesses data, and review each contract before go-live.

What drives the cost of a self-hosted billing project?

Cost is driven by scope rather than by the software license, since Kill Bill and Lago are open source. The main drivers are the hosting region and architecture, the number of integrations (payment gateways, tax engine, accounting ledger, CRM, customer portal), catalog complexity (plans, add-ons, usage metrics, currencies, proration rules), the number of gateways, and the support model you choose. Ask any partner for a quote that itemizes these components separately, and state which items are one-time (design, migration, integration build, hardening) and which recur (hosting, monitoring, upgrades, backups, support retainers). DeployOpen provides no price list, and fixed-scope quotes follow from a written scope.

What does the project need from our team?

Four roles need named owners before work starts. A data protection officer or privacy lead owns the transfer map, the records of processing, the processor contracts and the decisions on gateway and support access. Finance owns the catalog, pricing rules, invoice numbering, tax treatment and the ledger interface. Security owns hosting controls, encryption, multi-factor authentication for administrators and log retention. An engineering owner runs the platform day to day, including deployments, database operations and upgrades. Without these owners, decisions stall, and the project often ends up with unclear accountability for compliance evidence.

How long does an EU data sovereignty billing project take?

Timing depends on the scope, so no general duration applies. The biggest variables are the number of plans and price rules to migrate, whether active subscriptions must move mid-term, how many gateways and tax integrations are in use, and how much the privacy review and processor contract negotiations take on your side. Request a timeline in the written scope, with milestones for design, build, data migration, parallel running and cutover. Ask the partner which milestones depend on your internal approvals, since those are the most common source of delay.

Can our own team run a self-hosted billing platform without a partner?

Yes, if your team has the capacity and skills to operate it. Running Kill Bill or Lago means maintaining the application, its database, job processing, backups, monitoring and security patching, plus planned upgrades and the integration code for each gateway and tax plugin. The key questions are whether you have engineers who can own these tasks continuously, whether you can test upgrades before production, and whether you can respond to an incident during billing cycles. Many teams do the initial build with a partner and then operate internally, or keep a support retainer for upgrades and testing.

How should we treat the pending EU-US framework questions and the Omnibus proposals?

Treat them as open items to monitor, not as settled conditions for the design. The EU-US Data Privacy Framework rests on Commission Implementing Decision (EU) 2023/1795, but an appeal against the General Court's judgment is pending as Case C-703/25 P, so a US processor's adequacy status could change. The Omnibus IV and Digital Omnibus proposals are not adopted, and the GDPR text has not been amended as of October 2026. Design so that the transfer analysis does not depend solely on one adequacy decision, record the assumptions your DPO relies on, and schedule a review each time the legal position changes. Your counsel should confirm the current status before decisions are signed.

Questions to ask an implementation partner before a sovereignty billing project

Start with the transfer register, because it decides whether the project is sovereign at all. Ask the partner how they will map every path that carries billing, customer and usage data, including the Kill Bill or Lago API, the database replicas, the event store, the email and dunning providers, the tax engine, the accounting sync and the support tooling. Each path should be tied to a named data location, a legal entity and a documented transfer assessment. Under the EDPB's Guidelines 05/2021, remote access from a third country, even only displaying data on a screen for support, counts as a transfer, so ask how support tickets and vendor consoles are covered. Ask for the register as a deliverable with an owner and a review date, not as an appendix.

Next, ask how remote and vendor access is locked down. Request the written access model: which roles can reach the billing database, the secrets store and the admin consoles, from which countries, through which bastion, and under which approval. Ask how break-glass access is logged and who reviews those logs. Confirm how the partner will handle any vendor support session that could show personal data, and whether it can be done without a third-country login. Ask how they will test that the controls work, not only that they are written down. A fixed-scope engagement should name these controls and the test evidence in its deliverables.

Then ask how gateway data flows and PCI boundaries will be drawn. The right answer keeps card numbers out of the self-hosted billing system and stores only gateway tokens, with the gateway or an orchestrator vault holding the card data. Ask the partner to show a data flow diagram listing which components receive payment identifiers, webhooks and card metadata, and where those webhooks land. Confirm which gateway regions process the data and whether any of them move it outside the EEA. Ask for their view on PCI scope, but expect a qualified assessor, not the partner, to make the scope decision. Finally, ask for references only where they can be shared under a signed nondisclosure agreement, and ask for the written scope before any work begins.

How DeployOpen scopes and runs EU sovereignty billing work

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For EU sovereignty billing, that means agreeing in writing where billing, customer and usage data will live, which payment and tax flows leave the EU, and what the evidence file must show before any work starts.

How we scope

Map every system holding invoice, contact, usage and payment data, and where each one is hosted and administered.
Trace each data flow to a payment gateway, tax engine, CRM or accounting system, and flag any transfer outside the EU.
Agree a fixed scope, deliverables and timeline in writing before work starts, with a separate quote for any ongoing retainer.

How we build

Deploy Kill Bill or Lago in the client's chosen EU cloud account, data center or private network, with infrastructure as code.
Configure gateway integrations so cardholder data stays with the processor, and confirm that support access is limited to the EU.
Test access controls, encryption in transit and at rest, backups and invoice generation before any live customer data is loaded.

How we hand over

Document the architecture, data location map, transfer assessment inputs and access model for your privacy and security teams.
Provide runbooks for upgrades, backup restores, key rotation and incident response, written for your own operators.
Train your administrators and agree which records, logs and configuration exports your auditors or supervisory authority may request.

How we support

Offer ongoing support, upgrades and continuous security testing as a retainer, scoped separately from the implementation.
Review platform releases and plugin changes against the data location and transfer map before they reach production.
Confirm with your legal counsel whether any third-country access exposure needs assessment, since DeployOpen does not issue legal opinions or audit reports.