Open-source billing software compared

A billing platform decides what to charge and when, but it does not move the money. Billing work breaks into four stages: metering (recording usage events), pricing (applying plans, tiers and credits), invoicing (producing the bill and its line items), and payment collection (charging a card or bank account and handling retries and failures). Lago's FAQ describes its role as calculating how much to charge and when, then handing that instruction to a payment gateway. The README names Stripe, Adyen and GoCardless as supported providers. Kill Bill covers the same ground with a different shape: it handles subscriptions, invoices and credits, and connects to gateways such as Stripe, Braintree and PayPal through plugins deployed alongside the server. Before you shortlist either tool, map each of the four stages to a system owner in your organization.

The split matters for three reasons. First, scope: the systems that store or transmit cardholder data sit in your PCI DSS scope, and a billing platform that only passes a payment token to a hosted gateway will usually keep that scope smaller than one that handles raw card numbers. Confirm with your assessor which architecture you are proposing, and check whether the gateway's hosted fields or tokenization path is the one you intend to use. Second, contract ownership: the merchant agreement, chargeback liability and settlement reporting belong to whoever holds the gateway account, not to the billing software. Decide that owner before implementation, because switching gateways later means re-pointing plugins or integrations and re-validating retry and webhook behavior. Third, the failure path: when a charge fails, someone must own dunning, retries and reconciliation between invoice status and settlement. Ask each vendor and your own engineers to write down the webhook flow, the stored payment identifiers, and where reconciliation runs. A short illustrative test, such as a declined card in a staging gateway account, will show quickly whether the invoice state, the gateway record and your finance ledger agree.

The open-source core of Lago and Kill Bill carries no license fee, so the money you spend goes to everything around the software. Lago's FAQ describes a forever-free open-source edition with fundamental billing features, and Enterprise plans add premium features on top. Kill Bill is Apache License 2.0 software with no support or SLA included. Before you budget, confirm with Lago which premium features your use case needs and whether they are needed at all. For Kill Bill, assume every production support expectation is a separate purchase, either from a vendor-side support contract or from your own engineers. OpenMeter is also Apache 2.0, but its releases are still beta, so ask its maintainers, or Kong, what support terms apply to the version you pick.

The total cost has five components. Software is zero for these open-source cores, but Enterprise or support contracts are a license-like line item where they apply. Infrastructure is recurring: hosting for the application, PostgreSQL, Redis, and for OpenMeter Kafka and ClickHouse, plus any payment gateway fees, which are charged per transaction by the processor rather than by the billing tool. Implementation is mostly one-time: integrating the gateway, tax and ERP connectors, and migrating existing subscriptions. Support retainers and upgrades are recurring. Internal staff time is the largest and least visible cost, because someone must run upgrades, watch backups and answer billing questions for finance.

Do not estimate these numbers from list prices, because none are published here. Ask each vendor or implementation partner for a quote built on a written scope that lists the deployment topology, the expected event volume, the payment and ERP integrations, the upgrade cadence and the support hours you need. Ask for each line to be marked one-time or recurring, and ask which items change if event volume grows. A quote that leaves out the Enterprise license terms or the gateway integration is not comparable with one that includes them.

The hardest things to move out of a billing platform are the records that carry financial and legal weight, not the code. Customer records, subscription histories, invoice numbering, credit balances and payment gateway tokens all have to survive a migration intact. Invoice numbers must continue without gaps or collisions, credit balances must match the ledger the finance team already reconciles against, and subscription histories determine how proration and renewals were calculated for past periods. Before you commit, ask each vendor for a complete export of these objects, in a documented format, and test a partial export against your own data. Confirm whether gateway tokens are portable at all. Tokens are usually bound to the payment processor account, so moving them may mean asking the customer to re-authorize payment methods, which is a commercial and customer experience cost rather than a technical one.

A clear data model and documented APIs lower exit risk because they let you extract and rebuild this data without relying on the vendor's internal tooling. Kill Bill and Lago both expose their core objects through REST interfaces and run on relational databases you control, which makes a self-directed export a realistic exercise for your own team to scope. OpenMeter's usage data is ingested as CloudEvents and stored in ClickHouse, so the raw event history is a separate asset you should plan to retain outside the billing layer. Kong's acquisition of OpenMeter, announced on September 3, 2025, said the project would remain open source under Apache 2.0 and that metering, entitlements and invoicing would move into Kong Konnect. That may shape the roadmap, so confirm with the maintainers how the self-hosted feature set, release cadence and beta status are expected to change, and get that answer in writing before you build production workflows on it.