Downgrade¶
What is a downgrade?¶
When a customer asks to stop using products or move to less expensive packaging this can be seen as a “downgrade”. This is another common contract lifecycle event that requires a change in packaging. Let’s go through an example where a customer on the enterprise Wikipedia pricebook will downgrade to the standard plan:
As of 5/15/2024, “Don-vip” currently is using the “Enterprise” plan and is going to move to the “Standard” plan in the future.
customers.id |
customers.name |
contracts.durable_id |
contracts.started_at |
contracts.ended_at |
contracts.pricebook_id |
contracts.version |
|---|---|---|---|---|---|---|
1541 |
Don-vip |
Don-vip_contract |
2023-11-01 12:51:15 |
2024-11-01 00:00:00 |
b |
0 |
products.id |
products.name |
list_prices.id |
list_prices.price |
pricebooks.durable_id |
pricebooks.name |
invoice_delivery |
invoice_schedule |
list_prices.created_at |
|---|---|---|---|---|---|---|---|---|
1 |
Updates |
4 |
0.05 |
b |
Enterprise |
ARREARS |
1 |
2023-11-01 |
2 |
Creates |
5 |
0.04 |
b |
Enterprise |
ARREARS |
1 |
2023-11-01 |
4 |
Enterprise platform fee |
6 |
5000.00 |
b |
Enterprise |
ADVANCED |
12 |
2023-11-01 |
products.id |
products.name |
list_prices.id |
list_prices.price |
pricebooks.durable_id |
pricebooks.name |
invoice_delivery |
invoice_schedule |
list_prices.created_at |
|---|---|---|---|---|---|---|---|---|
1 |
Updates |
1 |
0.10 |
a |
Standard |
ARREARS |
1 |
2023-11-01 |
2 |
Creates |
2 |
0.05 |
a |
Standard |
ARREARS |
1 |
2023-11-01 |
3 |
Platform fee |
3 |
1000.00 |
a |
Standard |
ADVANCED |
12 |
2023-11-01 |
How to model a downgrade¶
The company’s refund policy determines the way a downgrade is modeled. Unlike an upgrade, the customer is not “purchasing” a new package. They are requesting a lower tier package to be swapped out for their, often more expensive, existing packaging. In some circumstances, this can be seen as a breach of contract and will result in a disgreement between the customer and vendor. An example of this could occur when a customer intends to downgrade in the first year regardless of the two year contract agreed upon. An even more complex situation could occur if the customer demands a refund for the upfront platform fee that was paid at the outset of the agreement.
Many vendors lean towards a more customer friendly stance and would be happy to cancel and a two year agreement. Refunding an already paid invoice on the other hand is more extreme, and is more rarely seen unless the situation absolutely calls for it. With this in mind, two demonstrations will be created to model each scenario.
Downgrade without refund¶
When downgrading a customer without a refund it’s important to maintain the products they have already purchased. In the case of “Don-vip” they have already purchased a 1 year enterprise platform fee. Moving them to the lower tiered “Standard” plan immediately would be taking away what they’ve already paid for. This means leaving the current contract in place until it expires. Once expired, the “Standard” plan packaging will take the “Enterprise” plans place.
customers.name |
pricebooks.durable_id |
pricebooks.name |
contracts.durable_id |
contracts.started_at |
contracts.ended_at |
contracts.version |
|---|---|---|---|---|---|---|
Don-vip |
b |
Enterprise |
Don-vip_contract |
2023-11-01 12:51:15 |
2024-11-01 00:00:00 |
0 |
Don-vip |
a |
Standard |
downgrade_contract |
2024-11-01 00:00:00 |
2025-11-01 00:00:00 |
0 |
Results of a downgrade without refund¶
Given the contract lifecycle hasn’t been ammended there is no change to the invoice schedule. This is a nice outcome since the new contract will automatically take affect at the specified time leaving the operator with little do other than communicating with the customer how the new change will go into effect.
Downgrade with refund¶
When downgrading a customer with a refund the process is treated just like an upgrade. The existing contract is edited to end effective immediately and the downgrade contract is issued at the same time. A refund is required since only a portion of the “Enterprise platform fee” has been used. This refund will be represented as an ad hoc contract_price attached to the downgrade contract.
customers.id |
customers.name |
contracts.durable_id |
contracts.started_at |
contracts.ended_at |
contracts.pricebook_id |
contracts.version |
|---|---|---|---|---|---|---|
1541 |
Don-vip |
Don-vip_contract |
2023-11-01 12:51:15 |
2024-11-01 00:00:00 |
b |
0 |
1541 |
Don-vip |
Don-vip_contract |
2023-11-01 12:51:15 |
2024-05-15 00:00:00 |
b |
1 |
1541 |
Don-vip |
downgrade_contract |
2024-05-15 00:00:00 |
2024-11-01 00:00:00 |
a |
0 |
Similar to the prior upgrade example, it can be seen in the rows above that there are two versions of the Don-vip_contract. The first version is the original contract, the second version has a backdated end date to the middle of the current period: 5/15/2024. Since the end date is within the current billing period of May 2024 we do not need to void or adjust any past arrears invoices. As mentioned prior we need to handle invoices that were issued in advance, specifically the “Enterprise platform fee”.
products.id |
products.name |
prices.contract_price_uid |
prices.list_price_uid |
prices.price |
prices.prorate |
contracts.customer_id |
contracts.durable_id |
contracts.pricebook_id |
prices.started_at |
prices.ended_at |
|---|---|---|---|---|---|---|---|---|---|---|
1 |
Updates |
1 |
0.10 |
true |
Don-vip |
downgrade_contract |
a |
2024-05-15 |
2024-11-01 |
|
2 |
Creates |
2 |
0.05 |
true |
Don-vip |
downgrade_contract |
a |
2024-05-15 |
2024-11-01 |
|
3 |
Platform fee |
3 |
1000.00 |
true |
Don-vip |
downgrade_contract |
a |
2024-05-15 |
2024-11-01 |
|
4 |
Enterprise platform fee |
5 |
-5000.00 |
true |
Don-vip |
downgrade_contract |
a |
2024-05-15 |
2024-11-01 |
The newly created downgrade_contract has inherited the standard packaging, included in pricebook a, and has included an ad hoc contract price, prices.contract_price_uid = 5, to account for the refund. The price for the ad hoc contract price is negative since this is a credit to the customer.
Results of a downgrade with refund¶
The changes result in two additional invoices being generated. One invoice in arrears and the other in advanced.
products.id |
products.name |
line_items.price |
line_items.quantity |
line_items.amount |
invoices.total |
invoices.invoice_delivery |
invoices.status |
invoices.contract_id |
invoices.started_at |
invoices.ended_at |
|---|---|---|---|---|---|---|---|---|---|---|
1 |
Updates |
0.10 |
2073.0 |
207.3 |
369.3 |
ARREARS |
DRAFT |
downgrade_contract |
2024-05-15 00:00:00 |
2024-06-01 00:00:00 |
2 |
Creates |
0.05 |
3240.0 |
162.0 |
369.3 |
ARREARS |
DRAFT |
downgrade_contract |
2024-05-15 00:00:00 |
2024-06-01 00:00:00 |
products.id |
products.name |
line_items.price |
line_items.quantity |
line_items.amount |
invoices.total |
invoices.invoice_delivery |
invoices.status |
invoices.contract_id |
invoices.started_at |
invoices.ended_at |
|---|---|---|---|---|---|---|---|---|---|---|
3 |
Platform fee |
1000.00 |
1.0 |
465.75 |
-1863.02 |
ADVANCED |
FINALIZED |
downgrade_contract |
2024-05-15 00:00:00 |
2024-11-01 00:00:00 |
4 |
Enterprise platform fee |
-5000.00 |
1.0 |
-2328.77 |
-1863.02 |
ADVANCED |
FINALIZED |
downgrade_contract |
2024-05-15 00:00:00 |
2024-11-01 00:00:00 |
The invoices with invoice_delivery=ADVANCED require proration since they are annual charges. To calculate the proration factor we take the difference between the start_date and end_date, 170 days, and divide it by the term of the annualized platform fee, 365 days. This gets us a proration factor of 170 / 365 = 0.47 which we multiply by the price to get the prorated value, for example the standard platform fee is 0.47 * 1000 = 465.75. This value can be seen on the line item as the amount.
The new invoice_delivery=ARREARS invoice created from the downgrade contract has a shortened period. Additionaly, the invoice tied to the previous contract, durable_id='Don-vip_contract', must also be cut short. This results in two invoices during the month of May, one for the prior contract and the other for the downgraded contract.
invoices.contract_id |
products.id |
products.name |
line_items.price |
line_items.quantity |
line_items.amount |
invoices.total |
invoices.invoice_delivery |
invoices.status |
invoices.started_at |
invoices.ended_at |
|---|---|---|---|---|---|---|---|---|---|---|
Don-vip_contract |
1 |
Updates |
0.05 |
140765.0 |
7038.25 |
7135.53 |
ARREARS |
FINALIZED |
2024-05-01 00:00:00 |
2024-05-15 00:00:00 |
Don-vip_contract |
2 |
Creates |
0.04 |
2432.0 |
97.28 |
7135.53 |
ARREARS |
FINALIZED |
2024-05-01 00:00:00 |
2024-05-15 00:00:00 |
downgrade_contract |
1 |
Updates |
0.10 |
2073.0 |
207.3 |
369.3 |
ARREARS |
DRAFT |
2024-05-15 00:00:00 |
2024-06-01 00:00:00 |
downgrade_contract |
2 |
Creates |
0.05 |
3240.0 |
162.0 |
369.3 |
ARREARS |
DRAFT |
2024-05-15 00:00:00 |
2024-06-01 00:00:00 |
There are only a couple differences between a refund occurring with a downgrade versus one with an upgrade. The largest difference is the creation of a negative invoice. This result is due to moving from an expensive set of packaging to a cheaper one. From a business modeling perspective there isn’t much to handle, but from an administration perspective it can depend on the billing implementation. Most invoicing systems do not allow for negative invoices and require a credit memo or a refund object to be created. Since business modeling and administration are separate in bframe this process only occurs when preparing the revenue documents for invoicing at a later step. Ultimately, the negative invoices or lines items are transformed and separated based on the billing system that has been integrated. Once the refund is completed, the downgrade process would be considered complete.