When thinking of subscriptions, the first thing that comes to mind is the idea of receiving a service: You subscribe to your phone company which allows you to make use of your brand new shiny iPhone, or receives your monthly box of organic fair trade certified veggie box,… Now, along with receiving a service, comes the bills! These two sides of the subscription, the entitlement (the service) and the billing (the periodic invoices) are related and yet, they need to have a life of their own to create enough flexibility:
For instance, a user may decide to cancel his subscription, and the user (or the company providing the service) may decide that the service should be stopped immediately; the company’s policy may be to avoid any pro-ration credit, requiring the billing to continue until the service period ends, and so entitlement and billing do not stop at the same time. Another example would be to start providing a service in beta mode and only start charging the customer later after enough feedback have been gathered, in which case, entitlement would happen prior billing really starts. Those are two of the use cases to illustrate why entitlement and billing need to be kept separate.
Now, there is another set of challenges coming from the recurring payments associated with the invoices: For each invoice (with a balance), there will need to be a payment. The recurring payment could be automatic or the customer could be notified and be responsible to make the payment happen. Some of these payments will fail (CC expired, stolen, insufficient funds,…) and so there is a question of what happens to the service associated with a customer that does not pay (or missed previous payments). This is often refrerred to as dunning or overdue, and this will also have an impact on both the entitlement and the billing:
For instance, a company could decide that in some payment failure scenarios and or after some amount of time, the service should first be degraded, and the billing should be kept untouched, and if payments are still not met, then service should be suspended and billing should be blocked until the payment resumes. Finally, if after some time payments are still not met, service and billing would become cancelled. The dunning scenarios create additional use cases for when entitlement and billing need to be kept separate
The figure below summarizes the relationship between the entitlement and the billing after the subscription was created:
Traditional Billing solutions tend to focus on the invoicing aspect and either leave the management of the entitlement piece to some other system, or do not create enough flexibility for the management of those two aspects.
Kill Bill was designed to allow both views of the subscription to be part of the same system and yet provide enough flexibility to control the behavior through flexible xml configuration files or through powerful APIs where one can specify policies.
