Revenue and Cost Calculation for Subscription Change Scenarios

This article is mostly useful for CloudBlue Commerce support.

Charge Calculation Logic from the recurring_strategy Value Prospective

The charge calculation logic below is relevant when the settings in the Billing Terms tab of the service plan profile are set to their default values:

• Charges for limit changes
  • Upsizing: Actual amount (prorated charges)
  • Downsizing: Actual amount (prorated charges)
• Charges for service plan or subscription period changes
  • Upgrading: Actual price (prorated charges)
  • Downgrading: Actual price (prorated charges)

Charge calculation logic for changes to subscriptions to service plans with and without volume pricing is implemented through a calculated parameter (Enum), recurring_strategy, which can have one of these values:

• prorate_only: when a resource quantity is changed, a single prorated charge is calculated: either an additional charge for upsize, or a refund for downsize.

• refund_based: when a resource quantity is changed, three charges are calculated: the full refund for the current billing period, a prorated charge for the old quantity before the change, and a prorated charge for the new quantity for the billing period part after the change.

  Note: This option is useful when implementing Microsoft's upsize/downsize and upgrade/downgrade policies.

Charge Calculation Logic from the Service Pricing Model Prospective (Volume Pricing On/Off)

When changes are made to a subscription - a resource quantity is changed (upsized or downsized) or the service plan or subscription period is switched (upgraded or downgraded) - applicable charges are calculated depending on the service type:

• For service plans with volume pricing: Recalculations are based on volume-based unit price changes.
• For other service plans: Recalculations are based on proration.

Note: In both cases, actual sales price changes are also a factor.

When a subscription is upsized (downsized) or upgraded (downgraded), Rating Engine calculates revenue and costs in the following way depending on whether the service plan uses volume pricing:

• If the service plan uses volume pricing, recurring_strategy = refund_based for both revenue and cost calculation.
• If the service plan is not based on volume pricing:
  • For cost calculation: Rating Engine will search for a hard-coded mapping to a billing rule, which defines billing rules for an application.
    • If Rating Engine finds a hard-coded mapping to a billing rule: Rating Engine uses the recurring_strategy value from the mapping and ignores values set elsewhere.
    • If no mapping to a billing rule can be found: Rating Engine uses the default value defined by the defaultrecurringstrategy parameter in Rating Engine Helm values. If the defaultrecurringstrategy value is prorate_only (or null) or not defined, Rating Engine uses recurring_strategy = prorate_only.
  • For revenue calculation: Rating Engine uses the default value defined by the defaultrecurringstrategy parameter in Rating Engine Helm values. If the defaultrecurringstrategy value is prorate_only (or null) or not defined, Rating Engine uses recurring_strategy = prorate_only.

Example

This table displays calculation differences for recurring payments depending on the recurring_strategy value:

Use Case	recurring_strategy = null/prorate_only (default)	recurring_strategy = refund_based (useful for Microsoft services)
01-Apr: 1 seat of O365($10/month) is purchased 15-Apr: +1 seat is added	The change order contains 1 order detail: $5 = 1 seat * $10 * 0.5 month, for the period [15-Apr;  30-Apr] Total: $5	The change order contains 3 order details: -$10 full refund for 1 seat, for the period [01-Apr;  30-Apr] $5 = 1 seat * $10 * 0.5 month, for the period [01-Apr;  15-Apr] $10 = 2 seats * $10 * 0.5 month, for the period [15-Apr;  30-Apr] Total: $5