When Zuora or Kill Bill fits a complex catalog
If you are facing a Zuora renewal, a data residency requirement or a catalog that has outgrown your current billing setup, the question is whether to keep a vendor-supported contract or to self-host Kill Bill and own the billing logic and data yourself. Zuora fits teams that want a vendor-backed contract, a supported product and limited in-house billing engineering, and that accept the vendor's roadmap and commercial terms. Kill Bill fits teams that have Java engineering capacity, want the subscription, invoicing and payment logic inside their own infrastructure, and are prepared to operate it as a product they maintain. Kill Bill is a standalone Java server typically run in Tomcat, so the decision is less about feature checklists and more about who will run it.
Four factors usually decide it. The first is engineering staffing: count the engineers who can build, deploy and patch a Java service with its plugins, and who will be on call for invoice runs. The second is support needs. Kill Bill is Apache 2.0 licensed with no support or SLA included, so you must either staff that support internally or contract it separately, and you should confirm what your finance and audit teams will accept as a support model. The third is catalog complexity. Map your product catalog, bundles, add-ons, usage rating and proration rules against Kill Bill's model before deciding, because the more of your catalog that is custom, the more engineering the migration takes. The fourth is the cost of plugin and migration work, covering payment gateway, tax and fraud plugins and the data move. Ask for each of these as a separate line in your evaluation, and do not assume a Kill Bill plugin exists for every gateway or tax engine you use.
Which scenarios favor each option
This table maps common buying situations to the option that usually fits better, with the condition that drives each answer. Read each row as a test: if the condition describes your organization, the right-hand column shows which way to lean. Most rows turn on in-house Java engineering, data location, catalog complexity and whether a contracted support obligation is required.
| Scenario | Lean toward Zuora when | Lean toward Kill Bill when |
|---|---|---|
| Renewal with a rising quote | The contracted scope still matches your catalog and the internal cost of running a self-hosted stack exceeds the uplift | You can staff Java operations and plugin work, and the renewal uplift is larger than the cost of hosting and support you would take on |
| Data residency mandate | Your regulator accepts the vendor's hosting regions and contractual data terms for billing records | Billing data, invoices and customer records must stay in a specific country, data center or air-gapped network you control |
| Multi-tenant SaaS catalog | Your catalog is modest and one billing configuration serves all customers with little per-tenant variation | You run many isolated tenants or product lines and need separate billing configuration per tenant inside one platform, which Kill Bill supports as a multi-tenant design |
| Team without Java engineers | You have no Java developers and no appetite to hire or contract for them, so a managed service is the practical option | Null |
| Need for a vendor SLA and support contract | A contractual uptime commitment, named support escalation or indemnity is a procurement or regulator requirement | You can accept that Kill Bill's open-source license carries no support or SLA, and you will buy support from a third party or staff it yourself |
| Complex plugin ecosystem with niche gateways | Your gateways and tax engines are already supported by the vendor's connectors and you do not want to own integrations | Your gateways, tax or fraud providers need plugins you can write or commission, and you want to control their release cycle |
| Need for an internal back office | Your finance and support teams are satisfied with the vendor's built-in administration and reporting | You want role-based back-office access for support, product configuration and finance reporting through Kaui, and you accept building the surrounding reports yourself |
How Kill Bill runs inside your infrastructure
Kill Bill is a standalone Java server packaged as a WAR file and typically run in Tomcat. Your applications, billing operations and integrations call it through REST APIs, and the system is event-driven and multi-tenant, so one deployment can serve several isolated tenants. Because it runs as ordinary Java application code, the hosting model is yours to choose: a virtual machine, a container platform or a bare-metal host inside your own data center or air-gapped network.
- Application server: Operations staff manage Tomcat, the JVM and the WAR deployment, including heap sizing, garbage collection and restarts.
- Java version: The Tomcat installation guide requires JDK 11, so confirm the JDK version against the release you plan to run before you build images.
- Container option: Official Docker images exist for the server, the Kaui UI and MariaDB, which helps teams standardize on Kubernetes or a similar scheduler.
- API surface: Account, subscription, invoice and payment calls all go through REST, so integrations with your CRM, ERP and product systems need their own authentication and rate controls.
- Upgrades: Each release is a new WAR and possibly new plugin builds, so plan a regression run in a staging tenant before every upgrade.
Before committing, ask your platform team to confirm how they will run a JVM-based service alongside your existing monitoring, logging and secret handling.
The database is the part of the stack with the largest effect on operations. The Kill Bill core team uses MySQL and runs regression tests against MariaDB 10 and PostgreSQL 12. The getting started guide also notes that users have deployed it with Oracle, Percona and Aurora. Those reported deployments are not the same as core-team testing, so the choice carries a different level of assurance for each option.
- MySQL: This is the core team's own database, so it is the best-trodden path for upgrades and community troubleshooting.
- MariaDB 10 and PostgreSQL 12: These are regression-tested by the core team, which makes them defensible options if your database standard is already set.
- Oracle, Percona and Aurora: Users have reported running these, but you should test them yourselves and confirm version support with the project before relying on them.
- Backups and replication: Your DBAs will own point-in-time recovery, replication and failover, and these must be tested against billing runs, not only the schema.
- Licensing: Oracle licensing and managed Aurora charges are recurring costs that change the total cost of ownership.
Ask your DBA team which engine they can support for the next several years, and request the exact versions the project tests before you choose.
Kill Bill keeps the core billing engine separate from the providers around it. Payment gateways, tax engines and fraud services are connected through plugins, which are deployed as JARs in the same Tomcat environment as the server. Documented examples include Stripe, Braintree and PayPal for payments, so you can choose the gateway set that matches your processor contracts and regions.
- Plugin deployment: Each plugin JAR is loaded alongside the server, so a plugin change usually means a server restart and a regression check.
- Gateway connections: Payment plugins hold provider credentials, so they belong in your secret management process, not in configuration files on shared hosts.
- Tax and fraud: You may need to write or adapt a plugin for a tax or fraud provider that is not already available, which is in-house engineering work.
- Version pinning: Plugin versions must match the server release, so track both in your change records.
- Testing: Sandbox credentials from each provider should drive automated tests before production traffic moves.
Confirm with your payments team which gateways and tax engines are in scope, and whether each one already has a maintained plugin.
Kaui is Kill Bill's back-office UI for internal teams. It provides role-based access control for support staff, product configuration, finance reporting and testing. It runs as a separate application from the core server, so you can decide who can reach it and where it sits on your network, which matters for segregation of duties in a regulated environment.
- Role separation: Use the built-in roles to keep support, product configuration and finance reporting apart, and review the assignments regularly.
- Network placement: Keep Kaui on an internal network or behind your existing access gateway, since it is not designed as a customer-facing portal.
- Authentication: Confirm how Kaui sessions and user accounts integrate with your identity provider, because access reviews will depend on it.
- Audit evidence: Reviewers will ask who changed a catalog or adjusted an invoice, so confirm what Kaui and the server log and where those logs are retained.
- Customization: Any screen or report you need beyond the standard set is additional development work, which should appear in the written scope.
Ask your finance and support leads to walk through the roles they need before you configure access, so the permissions match real duties.
What self-hosting changes for data location and compliance
Moving billing from Zuora to Kill Bill changes where customer and payment data sits and who can reach it. The cards below cover the decisions that shift with that move, from database access to PCI scope, and what an assessor will ask to see.
Where billing data sits
With Zuora, account, subscription and invoice records live in Zuora's hosted environment, and the region and hosting arrangement are set by the vendor contract. With Kill Bill, the WAR file, the Tomcat servers and the MySQL, MariaDB or PostgreSQL databases run in the infrastructure you choose, such as your own cloud account or data center. Confirm with Zuora in writing where each data type is stored and processed, including backups and support access, before you map the target region.
Who holds database and backup access
Kill Bill's event-driven design means billing state is spread across the application database, event tables and any plugin stores. Your team, not a vendor operations group, will decide who can run queries, restore snapshots and read backup copies. Write down named roles for database administrators, backup operators and Kaui users, and separate production read access from finance reporting access.
How PCI scope changes
PCI scope depends on whether card numbers pass through Kill Bill or stay with a payment gateway or external vault. Kill Bill stores payment references and connects to gateways such as Stripe, Braintree and PayPal, so the design decision is whether your servers ever receive raw card data. If they do, your environment falls into the card data environment and needs a full assessment. Document the data flow and have a qualified assessor confirm the scope.
Plugin and integration data flows
Payment, tax and fraud plugins are JARs deployed in the same Tomcat environment as Kill Bill, so each plugin is code running inside your billing boundary. Record which plugins handle customer personal data, which call external services, and what logs they write. Confirm the outbound network paths and the secrets each plugin needs, and review them as part of the same data location map.
What an audit will ask for
Assessors typically ask for documented controls, change records, access reviews, backup and restore test evidence, and logs that show who changed a product catalog or an invoice. Kill Bill provides the software, not the evidence, so you must produce it from your own logging and ticketing. DeployOpen prepares controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or attestation. Ask Zuora for its current attestation reports and their scope before you compare.
What drives the cost of running Kill Bill
Kill Bill carries no license fee for the software itself. It is Apache License 2.0 licensed, and the Billing Project, LLC owns the codebase and trademarks. The cost sits in running it. Kill Bill is a standalone Java server packaged as a WAR file and typically run in Tomcat, so your team pays for JDK and Tomcat operations, patching, JVM tuning and the database that backs it. The Kill Bill core team tests against MySQL, MariaDB 10 and PostgreSQL 12, and the Tomcat installation guide requires JDK 11, so confirm which database and JDK your platform team will support before sizing the hosting. Kill Bill's getting started guide notes that Oracle, Percona and Aurora have also been used, which may matter if your DBA standards are fixed.
Recurring costs are the ones that persist after go-live. They include hosting and database administration, plugin upkeep for each payment gateway, tax and fraud provider you connect, and upgrades to new releases such as 0.24.22, published on September 29, 2026. Kaui, the back-office UI, also needs internal owners for role configuration and finance reporting. Plugin work is often the largest variable: every gateway change, new tax rule or fraud integration is code your engineers write, test and maintain. Support is not included in the open-source license, so decide whether you will staff this in-house or buy a support retainer from a vendor or implementation partner, and get that retainer's scope and response terms in writing.
One-time work is different. Building the product catalog in Kill Bill, migrating accounts, subscriptions and invoices, reconnecting payment gateways and reconciling the first invoice runs are project costs that end at cutover. Ask any implementation partner for a fixed-scope quote that separates these items from the recurring run cost. Zuora's subscription price is not published, so you cannot compare directly from public figures. Request a written Zuora renewal quote covering every component you pay for today, then set it beside your own estimate of staff time, hosting, plugin maintenance and support. Confirm with Zuora which services, usage tiers and implementation fees are included, because those define the baseline you are replacing.
Cost of ownership by component
Zuora's cost is one subscription plus its implementation, while Kill Bill's software is free but its cost moves into engineering, hosting and support. The cards below separate each component so you can ask a vendor or partner for the same line items on both sides before comparing totals.
Software license
Zuora charges a subscription under a contract whose price is not published, so the figure to request is the annual subscription, its volume or usage tiers, and renewal uplift terms. Kill Bill is licensed under the Apache License 2.0, so the software itself carries no license fee. Ask Zuora what happens to pricing if your subscriber count or event volume grows during the term, since that is where renewal surprises usually come from.
Zuora subscription or Kill Bill software
On the Zuora side this line is the subscription itself, usually recurring. On the Kill Bill side the software is free, but the plugins for your payment gateways, tax and fraud providers are separate work items that you either build, buy or commission. Confirm which Zuora modules your contract includes and list each Kill Bill plugin you need before comparing the two lines.
Implementation and migration
This is largely one-time cost. Zuora typically involves an implementation partner for catalog setup and data loads, and Kill Bill involves the same work done by your team or a contracted partner, including translating the product catalog and reconciling the first invoice runs. Ask for a fixed-scope statement of work that names the data objects, the catalog size, the number of payment gateways and the reconciliation period, because these drive the effort more than the platform does.
Hosting and databases
Kill Bill runs in your own cloud account or data center, so compute, storage, backups, high availability and database licensing or managed database fees become your recurring costs. Kill Bill's core team tests against MySQL, MariaDB and PostgreSQL, and users have also run it on Oracle, Percona and Aurora. Choosing an engine your team already operates, and a managed service where it fits your policy, lowers this line. Request the environment sizing you assume for production, staging and disaster recovery.
Java and Tomcat operations
Kill Bill is a Java server packaged as a WAR file and typically run in Tomcat, and the Tomcat installation guide requires JDK 11. Someone must patch the JDK, Tomcat and Kill Bill releases, tune the JVM, and monitor the event-driven pipeline, which is recurring staff time. Plugins deployed as JARs share the same runtime, so each upgrade must be regression tested across them. Ask your team who owns this runtime and how many hours per month they expect it to take.
Plugin development
Each payment gateway, tax engine or fraud provider that Zuora supports natively may need a Kill Bill plugin written, tested and maintained in-house or by a contractor. This cost is one-time for the first build and recurring whenever a provider changes its API or your tax rules change. Ask for a list of plugins required at launch, which of them already exist as open-source work, and who will maintain each one after go-live.
Support and staff time
Kill Bill is published without support or an SLA, so vendor support in the Zuora sense is replaced by a retainer with an implementation partner, an internal on-call rota, or both. Staff time for billing operations, Kaui configuration, finance reconciliation and audit evidence recurs every month. Ask any partner for a written support scope with response targets, and ask Zuora for its support tier and whether it includes the upgrade effort you would otherwise carry yourself.
What a move from Zuora to Kill Bill involves
The sequence turns Zuora accounts, subscriptions, catalog and invoice history into a Kill Bill tenant that has been checked against real billing cycles before the Zuora contract ends. Each step closes with evidence that the next one can rely on.
Confirm scope, catalog and export rights
Agree in writing which Zuora products, currencies, legal entities and payment gateways are in scope, and list every Zuora object the business relies on, including custom fields, usage rating rules and credit balances. In the same exercise, ask Zuora in writing what data source exports are available, how long downloads remain open and whether any legacy exports have been retired. Your finance and billing owners sign off on the scope document. Done means every in-scope object has a named owner and the vendor has confirmed the export window in writing.
Export accounts, subscriptions and invoices
Run the Zuora data source exports for accounts, subscriptions, rate plans, invoices, payments and usage, and store the files in an encrypted location inside your own environment. Keep the original files unchanged so that every later transformation can be traced back to source. Your data engineers record row counts and control totals for each object. Done means each export has been checked against Zuora's own totals, and the export inventory has been archived with the contract records.
Translate the product catalog into Kill Bill
Map Zuora products, rate plans, charges, price books and usage units to Kill Bill's catalog model, which is defined in configuration and loaded through its APIs. Decide how each Zuora charge type, proration rule, trial and ramp will be expressed, and flag any Zuora behavior that has no direct equivalent so that it is designed deliberately. Your billing architect and product owner review the mapping line by line with sample subscriptions. Done means every catalog item has a Kill Bill definition and each mapping decision is recorded with its reason.
Build or configure payment and tax plugins
Kill Bill connects gateways, tax and fraud providers through plugins deployed as JARs alongside the server, so each provider your billing depends on needs a configured plugin or a custom build. Your Java engineers set up the plugin configuration, test payment authorization, capture, refund and tax calculation against sandbox accounts, and document the operational runbook. Confirm which plugins are community maintained and which your team must own. Done means every gateway and tax integration has passed sandbox tests and has a named owner for upgrades.
Import accounts and subscriptions through the APIs
Load accounts, payment methods references, subscriptions and opening balances into a non-production Kill Bill tenant using its REST APIs, with a script that can be rerun from the same source files. Payment card data is not moved by this step unless your PCI DSS scope and the receiving gateway explicitly allow it. Keep an import log that records every rejected record and the fix applied. Done means a full import completes repeatably and the rejected records list is empty or fully explained.
Run parallel invoice cycles
Run Kill Bill's invoice generation for the same billing periods that Zuora produces, without sending invoices to customers, and compare the outputs line by line. Pay particular attention to proration, credits, taxes, usage rounding and multi-currency amounts, because these are where differences usually appear. Finance reviews the variance report and the engineering team fixes the mapping or plugin logic that caused each difference. Done means the variance report is explained item by item and the remaining differences are accepted in writing by finance.
Reconcile the first live runs before cutover
Switch one controlled segment of customers to Kill Bill, then reconcile the first live invoice runs against ledger postings, payment gateway settlements and tax reports before moving the rest. Keep Zuora available for read access and for any re-export until reconciliation has been signed off. Operations and finance agree the cutover criteria in advance, and a rollback plan is tested. Done means the reconciled runs balance, the agreed cutover criteria are met, and Zuora read access is confirmed to remain open until the contract ends.
Questions buyers ask before moving off Zuora
What does it cost to run Kill Bill compared with Zuora?
Kill Bill's software is free under the Apache License 2.0, so the cost sits in what you pay people and infrastructure to run it. Zuora's subscription is an unpublished, recurring contract, and its cost is usually paid annually. With Kill Bill, the recurring costs are your servers, the Tomcat and Java runtime, the database, plugin maintenance, upgrades and staff time. The one-time costs are migration, catalog translation, plugin development and testing. Ask any partner for a quote built from a written scope that separates these components, and ask your Zuora account team for the full renewal terms, including any implementation partner fees you currently pay indirectly.
How long does a migration from Zuora to Kill Bill take?
The duration depends mainly on how complex your catalog is, how many accounts and open subscriptions must move, how many payment gateways must be reconnected, and how many custom integrations depend on Zuora's data. Kill Bill is a standalone Java server exposed through REST APIs, so the import path runs through those APIs and any custom plugins. Plan the work in phases: extraction, catalog translation, test imports, gateway reconnection and reconciliation of the first invoice runs. No fixed timeline is supplied for this work, so ask for a timeline in the written scope and confirm it against a test import of your own data.
What does the in-house team need to run Kill Bill?
Kill Bill is a Java application that runs in Tomcat and needs a JDK, which the Tomcat installation guide specifies as JDK 11, along with a supported database. The Kill Bill core team uses MySQL and runs regression tests against MariaDB 10 and PostgreSQL 12, and users have also deployed it with Oracle, Percona and Aurora. Your team needs people who can operate a JVM service, manage database backups and upgrades, write or maintain plugins in Java, and run the Kaui back office for finance and support. Confirm the exact skills gap with your engineering leads before deciding on internal ownership.
Can we move to Kill Bill without an outside implementation partner?
Yes, it is possible for a team with strong Java and billing domain knowledge, because Kill Bill is open source and its documentation covers installation and the core APIs. Most teams still underestimate the parts that take the most effort: catalog translation, data extraction, reconciling invoices and building payment and tax plugins. An outside partner can take a fixed scope for those pieces while your team keeps ownership of the platform. DeployOpen plans, implements, customizes, integrates, backs up, upgrades and documents self-hosted open-source platforms in your own infrastructure, under fixed-scope agreements. Decide internally which parts you will carry and which you will buy.
What happens to our payment gateway connections during migration?
Kill Bill connects to payment gateways through plugins deployed as JARs alongside the server, and it supports gateways such as Stripe, Braintree and PayPal. Your existing Zuora gateway connections do not transfer automatically. You need to configure the matching Kill Bill plugin for each gateway, test it in a non-production environment, and confirm that payment method references and tokens can be used without re-collecting card data. Check with each gateway whether your tokens are portable, and confirm the handling of card data with your PCI DSS scope owner before cutover. Reconcile the first live payment runs against both systems before you retire Zuora.
What support does Kill Bill offer without a contract?
Kill Bill is released under the Apache License 2.0, and the project includes no support or SLA. Community resources such as the project's documentation, GitHub releases and repository are available to everyone. If you need response times, defect fixes on a schedule, security advisories handled to your timetable or help with upgrades, you must arrange that separately with a vendor, a partner or your own team. Kill Bill 0.24.22, published on September 29, 2026, is the latest release in the 0.24.x line, so check which version you deploy and plan upgrades as a recurring task. Ask any provider to state its response commitments in writing.
What should we ask for in a Zuora renewal before deciding?
Ask Zuora for the full list of components in the renewal, including subscription tiers, usage volume bands, environment counts, support levels and any implementation partner work your team currently depends on. Ask how data export works and which objects you can extract before the contract ends, because a complete extraction plan is the first step of any move. Also ask what happens to historical invoices and payment data at termination. Use those answers as the baseline in a cost-of-ownership comparison with Kill Bill, and treat any figure you have not received in writing as unconfirmed.
How do we keep billing data under our own control after leaving Zuora?
Kill Bill runs as a standalone server in your own cloud account, data center or air-gapped network, so accounts, subscriptions, invoices and credits stay under your infrastructure controls. You are responsible for database encryption, access control, backups, logging and retention, and for documenting how those controls meet your regulator's expectations. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications, which independent auditors and certification bodies provide. Confirm your data residency and retention obligations with your compliance lead before choosing a hosting location.
How DeployOpen helps evaluate, implement or migrate Kill Bill
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 a Zuora to Kill Bill decision, the work usually starts with a written scope that tests your catalog, payment and tax needs against Kill Bill before any migration commitment is made.
How we scope
- Fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts
- Catalog review covering plans, add-ons, usage metrics and pricing rules that Kill Bill must model
- Inventory of payment gateways, tax providers and fraud tools that need Kill Bill plugins or replacements
- Decision on whether Kill Bill, Lago or a hybrid fits your usage volumes, invoicing and accounting needs
How we build
- Deployment of Kill Bill in Tomcat with MySQL or MariaDB, using the database engines your team already runs
- Kaui back-office configuration with role-based access for support, product configuration and finance reporting
- Plugin integration for your payment gateways and tax providers, tested against sandbox accounts
- Test migration runs that reconcile invoices, credits and balances before any cutover date is set
How we hand over
- Written documentation of the deployment, configuration, catalog, plugins and operational runbooks
- Backup and restore procedures tested against your database and recovery objectives
- Knowledge transfer so your internal Java and database staff can operate and upgrade the platform
- Evidence packs to support your compliance team, prepared for review by independent auditors who issue any opinion
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Upgrade planning for each Kill Bill release, including plugin compatibility checks before rollout
- Recurring security testing of the billing application, APIs and hosting environment on request
- Quotes built from the written scope, so you can compare the one-time and recurring costs directly
