Build or buy a billing system? A decision checklist for engineering and finance
Last updated: November 2026
Should you build or buy a billing system?
Three ways to get a billing system
For a side-by-side table on time to start, control, data, cost model and lock-in, see how to choose a billing system. That page also lists 24 criteria to compare vendors once you have picked a path.
What “build” really includes
A first version that creates subscriptions and sends invoices can look close to done. The hard parts show up once customers change plans and payments fail. Here is what a billing system has to get right.
| Part | Why it is harder than it looks |
|---|---|
| Catalog and price versions | Prices change. Existing customers often keep their old price while new customers get the new one, so the system has to keep every version and know which one applies to whom. |
| Proration | When a customer changes plan in the middle of a period, you credit the unused part and charge for the new plan. The rules differ for upgrades and downgrades, for monthly and annual terms, and for two changes in the same period. |
| Plan changes | Upgrades often apply now and downgrades at the end of the term. Trials, add-ons, pauses and cancellations all change what the next invoice says. |
| Payment retries and dunning | A failed payment needs a retry schedule, reminder emails and a point where access stops. When a gateway times out after the payment went through, a retry must not charge the customer twice. |
| Invoicing and numbering | Finance expects invoice numbers in sequence, without gaps. An issued invoice should not change: you correct it with a credit or an adjustment, and both must stay traceable. |
| Tax | Rates depend on where the customer is and what you sell, and they change. You either keep rates up to date yourself or connect a tax engine, which is one more integration to maintain. |
| Usage aggregation | Usage events can arrive late, twice or out of order. You have to remove duplicates, total them per customer and period, and decide what happens to an event that arrives after the invoice went out. |
| Multi-currency | Each account pays in its own currency. Rounding has to happen at the right step, or the invoice lines will not add up to the total. |
| Audit trail | Finance and auditors will ask who changed a price, an invoice or a payment, and when. Every change needs a record you can query later. |
| Migrations | You have to move live subscriptions, unpaid invoices and payment tokens from your current system without billing anyone twice or skipping a cycle. Read what a billing migration involves. |
| Upgrades and on-call | Billing runs on a schedule, at night and at month-end. Someone has to be on call when a run fails, and someone has to keep libraries, gateway APIs and security patches up to date. |
Cost items to put in your estimate
If you build, the first release is only part of the cost. Put each of these in your estimate, with your own team's numbers:
- The engineers who build the first version, and the product work they do not do in the meantime.
- Every pricing change. A new plan, trial or discount becomes a code change and a release.
- Updates when a payment gateway or a tax engine changes its API.
- Hosting, the database, backups and monitoring.
- On-call for billing runs and failed payments.
- Requests from finance: reports, exports, corrections and audit questions.
- Data fixes when an invoice goes out wrong.
- Knowledge transfer when the people who wrote the billing code move on.
What “buy” means, and what you give up
Buying usually means a SaaS billing system. The vendor hosts it, runs upgrades and keeps it up. You can often start billing quickly, and you have no billing servers to run. This helps most when your team is small. Check these points before you sign.
Pricing model
Some vendors charge a share of the revenue they bill, or a fee per transaction or per event. The fee then grows each time your business grows. Work out what it costs at your volume today and at three times that volume. The fixed fee vs percentage of revenue calculator helps with the arithmetic.
Lock-in
Subscriptions, invoices, payment tokens and history live in the vendor's system. Leaving means a migration on the vendor's terms. Ask how you export your data, in what format, and whether your payment tokens can move to another system.
Customization limits
You get the features the vendor ships, on its roadmap. When a pricing idea does not fit, the workaround often ends up in your own code, outside the billing system, where finance cannot see it.
Data location
Your billing and customer data sit in the vendor's cloud, in the regions it offers. Check this with your security and legal teams early.
The work that stays with you
Buying does not remove all engineering work. You still connect sign-up, entitlements, your CRM and your accounting system, and keep them in sync when plans or payments change.
The third option: build on an open-source engine
An open-source billing engine already handles the parts in the table above. You deploy it in your own infrastructure, connect it to your systems, and add your own rules as plugins or integrations. The code and the data stay under your control, and you do not start from an empty repository.
You still own some of the work. Your team hosts and operates the engine, upgrades it, and builds the integration with the rest of your company. If you have no one to run a production service, this option is harder to justify than SaaS.
Where Kill Bill and Aviate fit
Kill Bill is an open-source billing and payments engine, free under the Apache 2.0 license and in production since 2010. You run it yourself, with community help only. It comes with no support and no SLA.
Aviate is a separate commercial product built on Kill Bill. It runs in your infrastructure and adds ready-made modules, so you have less to build yourself: a catalog UI with an AI assistant, metering from raw events, a wallet for prepaid credits, coupons, tax, invoice numbering, invoice and email templates in 6 languages, Health, and quotes and orders. It includes Premium support, with an answer within 2 business days for critical production issues. For the price, see the pricing page.
If you need help with plugins or implementation, the partners page lists who works with Kill Bill.
The decision checklist
Tick each statement that is true for you today. Each one points to a path, shown under the statement. Ask engineering and finance to answer together: the last group is mostly for finance. Nothing you tick leaves your browser.
When building is the right call
Building your own billing system is sometimes the best choice. It usually is when one of these is true:
- Billing is what you sell, or the way you price is how you win customers.
- You tested existing systems and engines against your real pricing, including their extension points, and none of them could model it.
- You have engineers who have built billing or ledgers before, and you can keep them on it for years.
- Your policies rule out third-party billing code, open source included.
Also consider whether you need a billing system yet. If you sell one plan and charge it through your payment provider's recurring payments, that may be enough for now. Revisit the question when plan changes, usage or invoices start to take your team's time.
If you do build, plan for the cost items above from the first day. On-call and finance requests are easy to forget when you plan the first release.