G2

TAMIL THENDRAL M.

Software Engineer

Information Technology and Services

Small-Business (50 or fewer emp.)

8/30/2026

"Real billing engine — you must own the dates"

4/5

What do you like best about Kill Bill?

I run Kill Bill in production as a real subscription engine, not a checkout wrapper. Catalog XML, plan phases, IN_ADVANCE / IN_ARREAR (postpaid), usage, add-ons, invoices, auto-renewal, and overdue / block-unblock are first-class — not a bolt-on. Multi-tenant works for a platform with many customers.

I also love the plugin system. Payment, invoice, and entitlement hooks let me extend Kill Bill without forking the core. The one I use most: an invoice plugin that changes line items at generation time, so we can apply discounts when the invoice is built — not in a messy after-the-fact patch.

On my team I was the person who actually learned how Kill Bill behaves (catalog versions, charged-through dates, requestedDate, blocking states) and then introduced most of those billing features — auto-renewal, add-ons, postpaid, block/unblock, runtime invoice discounts — because nobody else here knew the engine that well. I can read the source, prove a charge or a date, then post a full repro on killbilling-users. People there (and on GitHub) answer with code and issues, not marketing. I am still learning it. That is the point: it is deep enough that there is always more to understand. We are not paying Kill Bill a SaaS bill. The price is engineering time: I had to own catalog, requestedDate, overdue, and plugins before the invoices were trustworthy. Stripe Billing would have been more features on day one and a real invoice to Stripe every month. I would rather pay that time and keep the BSS than rent a prettier stack and lose the source. For what we actually pay (hosting + my hours, not a license), the value is there — if someone on the team will sit with the dates. If you only count the sticker price and ignore that learning, it looks “free” and then it is not. Review collected by and hosted on G2.com.

What do you dislike about Kill Bill?

The hard parts are not “create a subscription.” They are dates, catalog pinning, and overdue edges. You have to understand the system first or it will not do what you expect.

Block / unblock and auto-renewal dates will not do the job if you treat requestedDate as optional decoration. Auto-renew end is an exact invoice-generation day, not a random calendar pick. If that date is wrong, the block lands on the next day: you get proration you did not want, or the next invoice still charges, or entitlement stops a day late. The docs are correct that a block with no requestedDate is immediate. You can pass the date you want — but it has to be the real generation / period-end date, not “today” and not “whatever.” I use a few different API call shapes (endpoint + params) so the effective day matches that invoice date. I learned that from clock tests and invoices, not from the happy-path doc. A new engineer who blocks blindly will ship a date that looks fine and a bill that is wrong.

Overdue can skip WARNING. After a customer pays some invoices but not all, the earliest unpaid date shifts. The next check can fire late and jump CLEAR → BLOCKED, so no grace email. We posted a repro; the team tracked it (GitHub #2297). Some balance / invoice-count jumps they treat as expected if your XML gaps are too small. Turning overdue on late, when old invoices already blow every threshold, can go straight to cancellation unless you plan tags or temporary day values.

New add-ons vs existing subscriptions: catalog V2 adds an add-on, old subs still fail with 1019. Plan-change-to-same-plan unlocks it but can rebill on MONTHLY mid-cycle (#2261). Painful when the catalog evolves.

IN_ARREAR cancel after an upgrade used to invoice recurring immediately vs end-of-term depending on whether a cycle had already closed. I hit that on 0.22.33, then walked the releases and found the change around 0.24.5 (a condition in the invoicing path). After we moved to that line, the cancel timing matched what we expected. Daily unblock is still a design limit: a few minutes before midnight can bill a full previous day, because Kill Bill does not invoice below a day — you design the clock, the engine will not split the day for you.

I am still learning the behaviour. That time is the real cost. Buyers should budget an engineer who will sit with the dates — not only an integration ticket. Review collected by and hosted on G2.com.

What problems is Kill Bill solving and how is that benefiting you?

Before Kill Bill, our billing work struggled on what customers actually ask for: auto-renewal, add-ons, postpaid (IN_ARREAR), discounts on the invoice, and block / unblock when service should stop or resume. A checkout tool does not own that. Building it from scratch is years of invoice math.

Kill Bill is the BSS. Our app stays product and UX; Kill Bill generates invoices, tracks charged-through dates, applies catalog rules, and drives blocking states. I introduced most of those capabilities here by learning how the engine behaves and wiring the right calls and plugins.

Two concrete wins. Discounts: an invoice plugin lets us change line items at generation time, not after the invoice already exists. Auto-renewal / block: the end date is an exact invoice-generation day. If requestedDate is wrong, the block lands on the next day and you get proration or an extra charge. If you omit the date, it is immediate — as the docs say. I use a few API shapes so the effective day matches that generation date.

The benefit is we can ship those features at all, prove them from invoices and source, and extend via plugins without forking the core. I am still learning. The engine is worth it if someone on the team will own the dates. Review collected by and hosted on G2.com.