Until now, Kill Bill only allowed to configure the Bill Cycle Day (BCD) attached to each subscription through the use of billing alignment catalog rules. As a reminder, the BCD defines the day when a specific subscription gets billed. For instance assuming customers get billed in advance, then creating a monthly subscription on 6/1/2016 with a BCD=1 would generate a first invoice on the 6/1/2016 for the month of June, and then a next invoice on July 1st for the month of July, etc…
In the current scheme, there are 3 different possible billing alignment policies, that are configured using special catalog rules:
ACCOUNT: All subscriptions whose Plan is defined with an ACCOUNT alignment will use the same account level BCD. This allows to group all subscriptions for an account on the same invoice. The BCD is either set using api, or if not set, the system will infer that BCD when the first subscription on the account is created (by looking at the first Phase in the Plan whose recurring price is not 0).
SUBSCRIPTION: The BCD is based on the subscription startDate and by also looking at the first Phase in the Plan whose recurring price is not 0.
BUNDLE: This is similar to the SUBSCRIPTION case but the system will use the start date of the base subscription to compute the BCD.
With the existing mechanism, the administrator configures once the various policies in the catalog and then everything happens automatically. This approach is convenient but rather static (does not allow to change a BCD for an existing subscription). In order to provide a more dynamic (BCD) assignment for existing subscriptions, we just introduced a new feature called Bill Cycle Day Override:
- This allows to change the existing BCD attached to any subscription in the system,
- This allows to change the BCD attached to any subscription multiple times (if required),
- A new api allows to specify the new BCD value along with the date after which this change should become effective
- The system will emit a new type of bus event that can be caught by plugins to take action at the time the BCD change occurs
- By default the invoicing system will need to first create a pro-ration to realign things with regard to old BCD and the new BCD
Let’s look at some possible scenarii by reusing the previous example where a subscription was created on 6/1/2016 with a BCD=1. On 6/1/2016, the system generates the first invoice for the period [6/1/2016, 7/1/2016). Let’s assume that for some reason (customer request, business need,…), the BCD needs to be changed to the 15. There are several possible outcomes based on when this change is triggered and which effective date is specified:
Scenario 1:
Let’s say the change is triggered prior to 6/15/2016 without specifying an explicit effective date or by specifying an effective also prior to 6/15/2016: In that case, on 6/15/2016, the system would generate a credit for the period [6/15/2016, 7/1/2016), and then invoice for a full period [6/15/2016, 7/15/2016) and immediately use the credit generated so the customer would effectively only be billed for the [7/1/2016, 7/15/2016). From then on, he would be billed each month on the 15 for a full period.
Scenario 1: Credit and Realign BCD
Scenario 2a:
Let’s say the change is triggered after 6/15/2016 and prior 7/1/2016 (next scheduled billing date) without specifying an explicit effective date or by specifying an effective also prior to 7/1/2016: In that case, on 7/1/2016, we would have a second invoice for the part [7/1/2016, 7/15/2016) (leading pro-ration), and then on 7/15/2016, the system would generate a third (full) invoice for [7/15/2016, 8/15/2016). From then on, he would be billed each month on the 15 for a full period.
Scenario 2a: Pro-ration and realign
Scenario 2b:
In some cases, it is better to lose a little bit of revenue and avoid confusing customers with pro-ration invoices. Such results can be achieved using the BlockingState abstraction: A first BlockingState event needs to be inserted on 7/1/2016 to block the billing and then a second one 7/15/2016 to unblock the billing. As a result of moving BCD to the 15 and blocking billing, customer would see his first invoice from [6/1/2016, 7/1/2016) and then on 7/15/2016, a second invoice for 7/15/2016, 8/15/2016), essentially skipping the period [7/1/2016, 7/15/2016).
Scenario 2b: Skip billing and Realign BCD
This new feature (along with the BlockingState abstraction) should provide all the flexibility to bill your customers exactly the way you want! The feature will only be available starting with version 0.17.x.
