Why open source subscription billing for SaaS companies needs a different build
Self-hosted open source billing fits a SaaS company when catalog control, data location or cost at scale matter more than vendor convenience. Picture a SaaS company whose plan rules, revenue figures and customer records sit inside a billing vendor it cannot fully control: price changes take a vendor ticket, exports arrive late, and the bill grows with every dollar of revenue. Moving to Kill Bill or Lago changes who owns those decisions, but it also moves the work of running the platform onto the company.
Billing is not only a plans-and-invoices problem. The same system handles card references, personal data for every customer and contact, revenue that flows into the general ledger, and tax calculations on every recurring invoice. That combination pulls the build toward PCI DSS scope, SOX-style change and access controls, GDPR processor obligations and tax handling, so the architecture, the access model and the evidence trail must be designed before the catalog is loaded. Teams that treat these as later add-ons usually rebuild the integrations.
On the open source side, Kill Bill is published under Apache-2.0 and Lago is published under an open source license, and the latest versions we can confirm are killbill-0.24.22 (released September 29, 2026) for Kill Bill. Neither project is the better choice in general. Kill Bill's fit depends on your team's comfort with its Java-based architecture and plugin model, and Lago's fit depends on how your usage metering and event volume are shaped. Confirm the license terms, the current release and the supported features of the exact version you plan to run, along with plugin availability for your gateway and tax engine, before you commit.
Which requirements shape a self-hosted SaaS billing build
This table maps the regulatory and buyer requirements most likely to reach a self-hosted SaaS billing project to the specific part of the build they change. Read each row as a question to answer during requirements work: who the requirement applies to, what evidence it creates, and which catalog, invoice, payment or log decision it forces. Applicability depends on your legal status, customer base and data locations, so confirm each row with counsel and your auditor before design freezes.
| Requirement | Source | What it means for the build |
|---|---|---|
| Encryption in transit and at rest, MFA, and activity logging for customer financial information | FTC Safeguards Rule, 16 CFR 314.4. Applies to covered financial institutions; confirm whether your SaaS company is covered | Encrypt connections between billing, gateways and the ledger, and encrypt database volumes and backups. Require MFA for every operator account and log administrative actions on catalogs, prices and credits. |
| Change management for price, catalog and plan changes | 16 CFR 314.4 change management element; SOC 2 CC8 change management criterion | Route plan, price and tax-rule changes through a reviewed, versioned workflow. Keep effective dates on catalog versions so existing subscriptions keep their contracted prices. |
| Documented instructions for processing invoice and contact data | GDPR Article 28(3) processor contract terms | Where you act as processor for business customers, limit processing to documented instructions, including any transfers. Log which subprocessors receive invoice and contact fields, such as payment gateways and tax engines. |
| Switching rights and the ban on switching charges | EU Data Act, Regulation (EU) 2023/2854, Articles 23, 25, 29 and 50 | If you offer a data processing service to customers, they must be able to export their data and move to another provider. From 12 January 2027, switching charges are prohibited, so export formats for subscriptions, invoices and usage must be designed in from the start. |
| Security common criteria CC1 to CC9 expected by enterprise buyers | AICPA 2017 Trust Services Criteria, security common criteria | Enterprise buyers often ask for a SOC 2 report or its evidence. Plan access reviews, change tickets, vulnerability tracking and incident records across Kill Bill or Lago, the gateway integration and the hosting layer from day one. |
| Record retention for billing and payment records | SEC Rule 17a-4(b) applies to broker-dealers; for other firms, use it as a reference point for invoice retention | If you are a broker-dealer, retain billing records and business communications for at least three years, the first two easily accessible. Otherwise, set a written invoice retention period with counsel and make sure archived invoices and credit notes remain retrievable and unaltered. |
Kill Bill, Lago and the billing SaaS: which fits which SaaS model
Four routes cover most SaaS billing decisions: a self-hosted billing engine with its own data model, a self-hosted usage-based engine, a payment orchestrator that vaults cards behind a billing system, or a hosted billing service. The right choice depends on catalog complexity, metering volume, who will operate the platform and how much data control the company needs.
Kill Bill for complex catalogs
Kill Bill is an open source subscription billing and payments platform licensed under Apache-2.0, and its latest release is killbill-0.24.22, published September 29, 2026. It fits SaaS products with multi-tier plans, add-ons, bundles, custom proration rules and several payment gateways, because its catalog and subscription model is designed for those cases. The trade-off is a data model and plugin system your engineers must learn and operate. Before committing, confirm the plugins you need for your gateway and tax engine, and who will own upgrades to the platform.
Lago for metered products
Lago is an open source usage-based billing platform aimed at products that charge for consumption, such as API calls, seats with overage or compute. It suits SaaS teams whose pricing centers on metered events and whose catalog is simpler than a multi-bundle enterprise contract set. The main trade-off is that event volume becomes an operational concern, since ingestion, storage and aggregation must keep pace with usage. Confirm the current license, release version and event-store options with the project before you publish a plan around them.
Hyperswitch paired with billing
Hyperswitch is an open source composable payments platform licensed under Apache-2.0, and its latest release is v1.128.0, published October 16, 2026. Placing it between the billing engine and your processors keeps card data in a vault, so the billing system holds tokens rather than card numbers. This reduces the card data your billing components handle, which matters for PCI scope. The trade-off is a second platform to run, with its own routing rules, monitoring and upgrade cycle. Confirm which processors and vault features your region requires.
Billing SaaS where volume or staffing favors it
A hosted billing service remains a sound choice when the team has no capacity to run billing infrastructure, when revenue and invoice volume are modest, or when a fast launch matters more than data control. Its cost recurs and tends to scale with revenue, so the comparison should model fees at your projected growth rather than at today's volume. Ask the vendor where customer and payment data is stored, how exports work, what happens to your catalog if you leave, and whether you can move to self-hosted software later without re-keying subscriptions.
Self-hosted operating model and staffing
Self-hosting moves responsibility for uptime, backups, security patches, upgrades and incident response to your organization or your implementation partner. Most of the recurring cost sits in engineering time rather than in software licenses, which are free under the open source licenses. Decide who on-call covers invoice runs, which environments hold production data and how catalog changes are approved before deployment. Ask a partner to document the runbook and the upgrade path in writing before go-live, not after the first incident.
How a SaaS billing rollout moves from catalog to live invoices
This sequence takes a SaaS company from an agreed billing catalog to live invoices on self-hosted Kill Bill or Lago, with each phase ending in a named artifact that the next phase depends on. Parallel running and a defined rollback keep revenue and customer records intact during cutover.
Define requirements and approve the catalog
Finance, product and the engineering owner agree the pricing models, plans, add-ons, seat rules, trial terms, currencies, tax treatment and invoice formats, then map each one to billing objects in the chosen platform. The partner documents the catalog as a versioned design and records which rules live in the catalog and which sit in the application. The step is done when the business owners sign an approved catalog and an open-questions log with named owners.
Build the sandbox with gateway and tax plugins
Engineers deploy the self-hosted billing platform in a non-production environment, connect the sandbox accounts of the payment gateways and any tax engine plugin, and configure webhooks, invoice templates and the customer portal integration. Access follows the least-privilege model the security team approves, and no live card data enters this environment. The step closes with a sandbox build record listing versions, plugin configuration and a passing set of connectivity checks.
Test trials, upgrades and proration
The test team replays a defined set of subscription scenarios, including trial conversion, mid-term upgrades and downgrades, seat changes, cancellations, failed renewals and credits, and compares each computed invoice with the expected result from the approved catalog. Defects go back to the catalog or configuration owner for correction and retest. The output is a test evidence pack that records each scenario, the expected and actual results, the defect log and sign-off by finance.
Reconcile parallel invoices against the current tool
For a defined period, the new platform generates invoices for a copy of live subscriptions while the current billing tool continues to bill customers. Finance compares totals, tax lines, currencies, discounts and revenue entries per customer and per plan, and investigates every variance until its cause is documented. The step ends with a reconciled invoice register that shows matched, explained and open differences, and the finance lead's approval to proceed.
Cut over with a defined rollback
The team moves subscriptions, payment method references and open balances to the new platform in a scheduled window, switches invoice numbering according to the agreed sequence, and disables billing jobs in the old tool. Before the window opens, the partner and the client write the rollback steps, the conditions that trigger them and the person who can authorize them. The output is a signed cutover runbook with a go-live record and a rollback decision point that is closed once invoices are confirmed.
Operate upgrades and monitoring after go-live
Operations staff monitor failed payments, webhook delivery, invoice generation and ledger sync, and they test each platform release in the sandbox before applying it to production under the same change management process. Access reviews and configuration change logs are kept as operating evidence. The step is ongoing and is evidenced by monitoring dashboards, a change log and a periodic reconciliation report that finance reviews.
Deployment patterns for SaaS billing in your own cloud or data center
This pattern runs the billing platform, its database, workers and integration services inside one cloud account and one region, with the company holding administrative control over the account. It is the most common starting point for a SaaS company that wants self-hosted Kill Bill or Lago without managing physical hardware. The application tier, the billing database and the event or job queue sit in private subnets, with only the API and portal endpoints reachable through a managed load balancer and web application firewall.
- Components: The application services, a PostgreSQL database for billing state, a background worker tier, object storage for invoice documents and a secrets manager for gateway and tax credentials.
- Network segmentation: Separate accounts or subscriptions for production, staging and tooling, with the payment gateway callback path and the accounting connector in their own restricted subnet and security groups.
- Backup: Automated database snapshots with point-in-time recovery, plus copies of invoice documents to a second availability zone or a separate backup account, tested by restore exercises.
- Customer and payment data: Contact and invoice data sit in the billing database and storage. Card numbers should not reach this environment at all, because the gateway holds them and the platform stores tokens and references only.
- Operations: Logging of administrative access and configuration changes to a centralized, write-restricted store.
Confirm the chosen region, account structure, backup retention and recovery targets against your own cloud governance and contract terms.
This pattern applies when the company or its customers need billing, contact and usage data to stay on infrastructure located in the European Union. The deployment is the same shape as the single-region pattern, but every component that stores or processes personal data is pinned to EU regions, and the team checks each managed service, log sink and support path for data location. The reasoning is covered in the EU data sovereignty guidance, which this page does not repeat.
- Components: Billing application, database, worker queue, document storage and observability stack all provisioned in EU regions, with a documented list of any non-EU service that touches data.
- Network segmentation: Egress rules that allow outbound calls only to the payment gateway, the tax engine and the accounting endpoint, so that no billing data flows to an unapproved region.
- Backup: Backup copies held in a second EU region or a separate EU account, with encryption keys held under the company's key management policy.
- Customer and payment data: Personal data, invoice history and usage events remain in EU storage. Gateway tokenization keeps card data with the processor, so the team must confirm where each gateway processes and stores data.
- Contracts: Processor agreements with each hosting, plugin and support provider that set out processing instructions and security measures.
Confirm the list of EU regions, the data flow for every third-party connector and any support access from outside the EU with your legal and security teams.
This pattern fits regulated buyers who cannot place billing data in a public cloud or who run their own private data center or isolated network. Everything runs on infrastructure the organization controls, and external connections are limited to a small set of approved gateways, mirrors and update channels. Software packages, container images and plugin updates are staged through an internal repository, because the platform cannot reach public registries directly.
- Components: Virtualized or container hosts, a PostgreSQL cluster with local replication, the billing application and workers, an internal artifact and image registry, and an internal certificate authority.
- Network segmentation: A management zone for administrators, an application zone, a data zone for the database, and a DMZ that hosts only the inbound payment webhook or customer portal endpoints, with firewall rules that log every crossing.
- Backup: Backups written to a separate site or offline media, with restore procedures rehearsed in the isolated environment. The recovery path must not depend on external services.
- Customer and payment data: Stored in the internal data zone only. Where the gateway is external, card capture stays at the gateway, and the internal system keeps tokens. Where the gateway is also self-hosted, its scope must be assessed separately.
- Access and evidence: Multi-factor authentication for administrative access and logs of authorized user activity retained for audit review.
Confirm which gateways, tax services and update channels can be reached through the approved egress path, and which upgrade steps your change management process requires before deployment.
What auditors and enterprise buyers ask for from billing evidence
This table maps the evidence a SOC 2 assessor or enterprise buyer typically requests to the billing component or operating process that produces it. Read each row as a question to answer before the audit window opens, and note where the evidence comes from the platform versus the surrounding identity, gateway and backup tooling. DeployOpen prepares these controls and evidence, but independent auditors issue any SOC 2 report.
| Evidence requested | Where it is produced | What to confirm before the audit window |
|---|---|---|
| Catalog change history and approvals | Kill Bill or Lago catalog and plan configuration, paired with the change ticket system that approves price and plan edits | Each plan, price or proration change has a named approver and a record that links it to the deployed configuration |
| Access reviews for billing administrators | Identity provider group membership and the billing platform's admin accounts | Quarterly or periodic reviews list every operator with write access to catalogs, invoices and credits, with removals evidenced |
| MFA and activity logs for operators | Identity provider MFA enforcement, plus application and database audit logs retained outside the billing host | Operators reach the admin console only through MFA-enforced single sign-on, and logs are centralized and tamper resistant |
| Invoice and credit approval trails | Billing platform invoice and credit records, with approval steps held in the workflow or ticketing tool | Manual credits and write-offs above an agreed threshold show requester, approver and timestamp in one retrievable trail |
| Gateway token inventory with no stored card numbers | Payment gateway or orchestrator vault, plus a scan of billing database tables and logs for primary account number patterns | Billing tables hold only gateway tokens and last-four values, and the scan results are kept for each assessment period |
| Backup and restore tests | Database and object store backups, with restore runs recorded in the operations runbook | A dated restore of invoices and subscription state into a separate environment completes, and the reconciled results are filed |
| SOC 2 Type 1 versus Type 2 scope | Control descriptions, system boundary diagram and evidence over the observation window | Type 1 tests design as of one date, while Type 2 tests operating effectiveness across a period. The auditor decides scope, not DeployOpen |
Questions to ask an implementation partner before signing
Start with production experience. Ask the partner how many Kill Bill or Lago deployments they have run for SaaS companies that bill on a mix of plans, seats and metered usage, and whether any of those deployments still run. Ask them to describe one catalog change they made after go-live, such as a new price book or a grandfathered plan, and how they tested proration and renewal dates before it reached customers. Ask who on the team has operated the payment gateway and tax plugins in production, not only installed them. Vague answers about "billing experience" in general are a signal to keep looking.
Next, ask how the partner will move existing subscriptions and prices onto the new catalog, and how they will prove the migrated invoices match the old ones. Ask which gateway and tax plugins they propose, why, and how each one handles tokens and tax calculation failures. For upgrades, ask how they will track releases such as killbill-0.24.22 or the current Lago version, test them against your catalog in a non-production environment, and roll back if an invoice run fails. Ask how they will produce change management records and privileged access logs for the billing platform, and what those records look like. Ask whether they will sign a data processing agreement that binds them to documented instructions and Article 32 security measures under GDPR Article 28, and who will receive personal data during the project.
Finally, confirm the commercial shape. Ask whether the scope, deliverables, acceptance tests and timeline will be agreed in writing before work starts, and what happens to the plan if a requirement changes mid-project. Ask what is excluded, such as tax rule maintenance, gateway certification or ongoing support, and whether those are priced as a separate retainer. Ask which costs recur after handover and which are one-time, and request a quote that breaks out implementation, plugin licensing, hosting and support. A partner who cannot answer these questions in writing before signing will be harder to hold to account once the billing run is live.
How much effort, time and internal input does a self-hosted billing build need?
What drives the implementation cost of a self-hosted billing system?
The cost is driven mainly by how complex the catalog is, how many payment gateways and tax jurisdictions the billing system must serve, how many active subscriptions must be migrated, and how many systems it must integrate with. A catalog with a few plans and one currency is far smaller work than one with usage-based components, add-ons, regional pricing and grandfathered contracts. Each gateway and tax integration adds configuration, testing and reconciliation work. Migration volume matters because every active subscription needs a mapped plan, a valid payment method token and a clean invoice history. Ask any partner to price each of these four areas separately in the written scope, so you can see which assumption moves the quote.
Can a SaaS team build and run Kill Bill or Lago internally?
Some teams can, but it depends on whether they have engineers who understand billing domain logic, payment flows and accounting close, not only general backend skills. Kill Bill is a Java platform licensed under Apache-2.0 and Lago is a self-hosted billing platform, so both need a team that can deploy, monitor and patch them and extend their plugin and webhook points. Most in-house teams underestimate the parts that are not code: catalog governance, dunning policy, invoice numbering, tax rule maintenance and month-end reconciliation. A useful test is whether two or three named people can own the platform for its full lifecycle, including the first upgrade and the first failed payment run. If not, a partner-led build with a documented handover is the safer route.
What costs are one-time and what costs recur after go-live?
One-time costs cover discovery, requirements, catalog design, gateway and tax integration, data migration, testing and cutover. Recurring costs cover infrastructure to host the platform, database and backup capacity, monitoring, security patching, version upgrades, plugin maintenance, tax rule updates when jurisdictions change, and the people who run the system. Support is a separate decision: an ongoing retainer, a vendor support contract for an enterprise edition, or an internal on-call rota. Ask each partner to split the quote into one-time and recurring lines, and to state what the recurring line includes, such as response expectations, upgrade windows and how security fixes are delivered. Confirm whether hosting and third-party plugin licenses are billed to you directly.
When does a billing SaaS stay cheaper than self-hosting?
A billing SaaS usually stays cheaper when your revenue is modest, your pricing is standard, your team has no spare billing engineers and you do not face strict data location or audit constraints. Many SaaS billing products charge fees that rise with revenue or invoice volume, so the comparison changes as the business grows. Self-hosting shifts cost from recurring fees to fixed build, hosting and staffing costs, which can make sense at higher volumes, with unusual pricing models or with data residency rules. Build a three-year total cost model with revenue growth, invoice volume, gateway fees, tax tool fees, staff time and support, then compare it with the SaaS vendor's written pricing for the same scope. Do not rely on rules of thumb.
What does the billing project need from finance and engineering?
Finance must own the commercial and accounting rules: plan definitions, proration policy, credit and refund approvals, revenue recognition treatment, tax setup and the general ledger mapping. Engineering must own deployment, integrations, security configuration, observability and the upgrade process. Both teams need to sign off on the catalog before build starts, because catalog changes after go-live affect invoices and reporting. In practice, expect finance to spend time on decision workshops, test invoice reviews and month-end parallel runs, and expect engineering to spend time on environment setup, webhook handling and incident response. Name one business owner and one technical owner in the statement of work so decisions do not stall.
How do EU Data Act switching rules affect exit planning for self-hosted billing?
The EU Data Act, Regulation (EU) 2023/2854, has applied since 12 September 2025 and requires data processing service providers to let customers switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transitional period. From 12 January 2027, providers may not impose switching charges, and until then reduced charges may not exceed the costs directly linked to switching. This matters when you choose a billing SaaS, because the contract should let you export catalogs, subscriptions, invoices and usage data in a usable format. For a self-hosted build, the Act's rules apply to the providers you use, so your exit plan should still cover data export formats, schema documentation and a tested restore into another system. Confirm these terms with your legal team and each vendor.
What should a written quote for a self-hosted billing build include?
A useful quote states the scope in writing, including the catalog, the payment gateways, tax integrations, accounting sync, customer portal, data migration volume and the environments to be delivered. It should list deliverables, acceptance criteria, the team roles involved, your responsibilities and any assumptions about your data quality or existing systems. It should also separate one-time work from recurring services, name any third-party licenses or plugin costs, and describe how changes after sign-off are priced. Because DeployOpen works on fixed-scope engagements agreed in writing before work starts, ask for the scope document and timeline first, then request a quote against it. DeployOpen does not publish a price list.
How long does a self-hosted billing implementation usually take?
Duration depends on the number of plans and pricing models, the gateways and tax jurisdictions in scope, the volume and state of migrated subscriptions and how quickly decisions are made by finance. A single-currency subscription product with one gateway will move much faster than a multi-entity business with usage metering and several regions. Ask any partner for a timeline built from the agreed scope, with milestones for catalog sign-off, integration testing, parallel invoice runs and cutover. Be cautious of any timeline quoted before the catalog and migration volume are known. Confirm the dependencies on your gateway and tax provider onboarding, since those often set the critical path.
When a billing SaaS remains the cheaper choice
A billing SaaS usually stays the cheaper option when your revenue is modest, your pricing model is standard, and your team has no appetite for running a billing platform. The core comparison is simple to state: a SaaS charges a fee that grows with the revenue or invoice volume it processes, while self-hosting replaces that fee with fixed and people costs that grow more slowly. Build the model around five components: the recurring SaaS fee at your projected revenue for the next two to three years, the one-time implementation work for catalog design, gateway and accounting integration, and data migration, the hosting and database operations you would carry, any paid plugins for tax or payment connectors, and the engineering hours spent on upgrades, incident response and on-call. Ask each billing SaaS vendor for its pricing tiers in writing, including how it counts invoices, subscriptions and usage events, and whether its fee rises as you cross tier boundaries.
Self-hosting tends to win when the SaaS fee would grow faster than your platform costs, when your catalog depends on pricing logic that a SaaS cannot express, or when data residency and audit constraints already require you to run infrastructure in your own accounts. Kill Bill is published under Apache-2.0 and Lago is also open source, so neither carries a license fee, but the decision still depends on whether you buy optional enterprise support. Kill Bill Aviate is an optional commercial offering, so its price, scope and support terms must be confirmed directly with the vendor before you add it to the model. Plugins for tax and payment connectors may be open source, commercial or built in-house, and each one needs its own maintenance line. Treat the engineering estimate as the largest uncertainty: write down who will own the platform, how many hours a month that ownership requires, and what that person would otherwise be building.
Before deciding, run the model at three revenue levels and under two scenarios: your current pricing model and the one you expect to need in 24 months. For each scenario, record the total cost of ownership for the SaaS and for self-hosting, separating one-time costs from recurring ones and listing what drives each up or down. Then test the assumptions that most often break these models: the number of billing events per customer per month, the number of currencies and gateways in use, the frequency of catalog changes, and the cost of a billing outage to revenue. If the self-hosted option only wins because you assume near-zero engineering time, the SaaS is likely the better choice. Confirm these inputs with your finance and engineering leads and with the vendors, not with a generic estimate.
How DeployOpen scopes and supports a self-hosted SaaS billing build
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For SaaS billing, that means a written scope covering your catalog, gateways, tax and accounting links, and the evidence your auditors will ask for.
How we scope
- Map your plans, add-ons, seats, trials, upgrade and proration rules into a written catalog specification before any build starts.
- Confirm the gateways, tax engine, general ledger and customer portal options your team will run, and which of them sit in PCI scope.
- Agree deliverables, timelines and exclusions in writing, since most engagements are fixed-scope with ongoing support available as a retainer.
How we build
- Deploy Kill Bill or Lago in your own infrastructure and configure catalog, invoicing, dunning and payment gateway connections to your specification.
- Build and test accounting sync and tax integrations, including proration, credit notes and invoice numbering, against sample subscription scenarios.
- Run security testing of the billing APIs and portal, and document the access and change controls that support your compliance assessments.
How we hand over
- Deliver architecture, runbooks, catalog change procedures and configuration records so your finance and engineering teams can operate the system.
- Document the evidence trail for price changes, invoice approvals and general ledger interfaces that your compliance readiness work will need.
- Walk your team through upgrade, backup and restore procedures, and confirm ownership of each component before the engagement closes.
How we support
- Offer retainers for upgrades, ongoing security testing and support after go-live, scoped separately from the initial build.
- Plan Kill Bill and Lago version upgrades and plugin updates as a recurring activity, with each change tested before it reaches production.
- Prepare systems and control evidence for independent auditors and certification bodies, which issue the reports and certifications themselves.
