# killbill/killbill: an open source subscription billing and payments platform in Java > Kill Bill is an Apache-2.0 billing engine split across many modules, from account and catalog to invoice and payment. It gives you the billing stack to run yourself, and the operational work that comes with that. **killbill/killbill** — Open-Source Subscription Billing & Payments Platform - Repository: https://github.com/killbill/killbill - Website: https://killbill.io - Stars: 5,771 · Forks: 968 - Language: Java - License: Apache-2.0 - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/killbill-killbill ## What killbill/killbill is for, and who ends up running it The repository describes itself as an open source subscription billing and payments platform. The problem it addresses is the recurring one: a business sells subscriptions, and then has to track who is entitled to what, when to charge them, what happens when a payment fails, and how to produce financial reports from all of it. Kill Bill puts that logic in a platform you host rather than in a vendor's system. The README frames the benefit in terms of control: because you run the stack, you are not depending on a third party's uptime or processing speed, and you avoid vendor lock-in on your business and client data. The audience is narrower than the tagline suggests. This is Java software assembled from Maven modules, and the top-level entries in the repository read like a list of billing concerns rather than an application: account, catalog, entitlement, invoice, payment, subscription, usage, overdue, currency, tenant, junction, jaxrs, beatrix, util. Someone evaluating Kill Bill is usually an engineer or a platform team at a company that has outgrown a simple payment integration and wants the billing model itself to be theirs. The README is explicit that this is not an all-in-one product: it is modularized so you can disable functionality you do not need or replace it with an existing system of your own. ## The module layout is the architecture The clearest description of how Kill Bill works is the directory listing. Each top-level module owns one part of the billing domain. account holds customer accounts. catalog holds the products, plans and pricing rules that subscriptions are built from. subscription and entitlement cover what a customer has signed up for and what they are allowed to use. invoice turns subscription state into charges. payment handles the money movement. usage covers metered billing. overdue handles the collections problem: what to do when an invoice is not paid. currency and tenant cover multi-currency and multi-tenancy concerns. junction and beatrix are integration and deployment pieces, and jaxrs is the HTTP surface. That split matters for adoption because it is also the failure surface. A billing platform that separates entitlement from invoicing means a bug in one module can produce a customer who is entitled to a service but never invoiced for it, or the reverse. The modularity that the README presents as flexibility is the same property that makes the system harder to reason about than a single billing service. If you plan to replace one module with an existing system, you are taking on the contract between that module and the rest, and the README does not describe those contracts. The technical documentation lives on docs.killbill.io, with sources in the killbill/killbill-docs repository, which is where the module boundaries are actually explained. ## Installing Kill Bill and getting to a first invoice The README does not give a local install procedure. It points to three places instead: docs.killbill.io for technical documentation, a one-click deployer for AWS described at docs.killbill.io/latest/aws.html, and cloud.killbill.io for free hosted sandboxes and developer tools. If you want to evaluate the billing model before running anything, the hosted sandbox is the lowest-effort route, and it is the one the README offers directly. For a self-hosted instance, the repository is a Maven project rooted at pom.xml, so the build path is the usual one for a multi-module Java project. The command below is the standard Maven invocation against that root file; the README does not spell it out, so treat it as the starting point for reading the build rather than a documented procedure. ## Where Kill Bill is the wrong tool The most direct limitation is operational. The README's pitch is that you do not rely on a third-party SaaS provider's uptime. The other side of that sentence is that the uptime is now yours. A billing system that invoices customers on a schedule and moves money has a failure mode that a marketing site does not: a failed run is not a blank page, it is a missed charge or a duplicate one. Nothing in the README describes rollback, replay or reconciliation tooling for a bad billing run, and the documentation it points to is where you would have to confirm that. The second limitation is scope. Kill Bill is a billing and payments platform, not a payments processor. It handles the billing model, the invoices and the payment orchestration, but the README does not claim to be a gateway. You still need a payment provider underneath, and the choice of that provider is outside what this repository describes. The third is the modularity itself. If your billing needs are simple, a recurring charge against a card, the account/catalog/subscription/invoice/payment/overdue split is more machinery than the problem requires. The README says the platform can be adopted one business area at a time, which is a reasonable migration story, but it also means you are running a subset of a system whose modules were designed to work together. ## How it compares with a hosted billing service The real alternative for most teams is a hosted subscription billing service, where the billing logic, the invoice generation and the dunning emails live behind someone else's API. The difference in approach is not feature parity, it is where the state lives. With a hosted service you call an API and read back what it decided; with Kill Bill the decision logic is in modules you run, and the invoice and entitlement records are in your own database. That difference shows up in two places. First, customization: the README describes Kill Bill as providing a framework for extensibility, and the module layout backs that up, since replacing or disabling a module is a supported idea rather than a fork. A hosted service gives you configuration options and webhooks instead. Second, cost structure: the README states that the project requires financial backing to sustain maintenance and enhancement, and points to GitHub Sponsors for companies, individual users and contributors. That is a support model rather than a licence fee, and the README also notes that professional services, sponsorships and commercial support packages are available on request. If you need a vendor to be accountable for billing correctness, that is a different relationship than sponsorship. ## Licence, governance and the cost of staying current Kill Bill is licensed under Apache License 2.0, stated in the README and present as the LICENSE file at the repository root. Apache-2.0 is a permissive licence, so the practical implication is that you can run and modify the platform without a copyleft obligation on your own code, but the usual Apache-2.0 conditions still apply and this is not legal advice. Check the LICENSE file and the NOTICE conventions your organisation requires before shipping. Governance is worth reading carefully. The README states that The Billing Project, LLC owns the Kill Bill codebase and trademarks, and that the project was founded independently in 2010 by Martin Westhead, Pierre-Alexandre Meyer and Stéphane Brossier. The project is free to use, and funding comes through sponsorship and commercial support rather than licensing. That is a coherent model, but it means the maintenance you depend on is tied to sponsorship and support revenue, not to a subscription you pay for. On upgrade cost, the repository is a multi-module Maven project, so a version bump is a rebuild across the modules you use, not a binary swap. The release history shows a steady cadence of patch releases in the 0.24 line through 2026, and the NEWS file at the repository root is where the project records what changed between them. The last push to the default branch was on 2026-09-14. ## Conclusion Adopt killbill/killbill if you need subscription billing logic you can run and extend yourself, and you have Java engineers who can operate a multi-module service. Do not adopt it if you want a single installable binary, or if hosted billing is acceptable and you would rather not run the stack. Before committing, verify that the modules you need are present in the repository layout you plan to build, and confirm the one-click AWS deployer is still the path the documentation points to. ## FAQ ### What is killbill/killbill? It is an open source subscription billing and payments platform, licensed under Apache License 2.0 and written in Java. The repository is split into modules such as account, catalog, entitlement, invoice, payment, subscription and usage rather than shipping as one application. ### How do I install killbill/killbill? The README does not give a local install procedure. It points to docs.killbill.io for technical documentation, a one-click deployer for AWS at docs.killbill.io/latest/aws.html, and cloud.killbill.io for free hosted sandboxes and developer tools. The repository root is a Maven pom.xml, so a self-hosted build runs through Maven. ### Is killbill/killbill a payment processor? No. The README describes it as a subscription billing and payments platform, and the module layout separates billing concerns like catalog, invoice and overdue from the payment module. It does not present itself as the gateway that actually moves the money. ### What licence does killbill/killbill use? Apache License 2.0. The README states it, and the LICENSE file sits at the repository root. ### Who owns killbill/killbill? The README states that The Billing Project, LLC owns the Kill Bill codebase and trademarks, and that the project was founded independently in 2010 by Martin Westhead, Pierre-Alexandre Meyer and Stéphane Brossier. ### Is killbill/killbill actively maintained? The repository is not archived, and the last push to the default branch was on 2026-09-14. Recent releases include killbill-0.24.21 on 2026-08-12, killbill-0.24.20 on 2026-08-07 and killbill-0.24.19 on 2026-07-09. ## Sources - [killbill/killbill on GitHub](https://github.com/killbill/killbill) - [License: Apache-2.0](https://github.com/killbill/killbill/blob/master/LICENSE) - [Project website](https://killbill.io) - [README](https://github.com/killbill/killbill/blob/master/README.md) - [Releases](https://github.com/killbill/killbill/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/killbill-killbill