Did you know that if you define your pricing model with pricing schemes, you can configure aggregations for usage-based charges? This way, you can aggregate usage data across multiple rating periods within one billing cycle. Particularly with tiered and volume-based price conditions, this allows you to calculate the aggregated total quantity and determine the price for the billing cycle.
In this blog post, we’ll have a look at an example use case to see how aggregations can be of advantage to your subscription business.
In our example use case, the product in SAP Subscription Billing represents a subscription for leasing an X-ray machine. Separate price components are covered by separate charges, for example a one-time charge for the installation fee and a monthly recurring charge for each named user operating the machine. For our scenario though, we’ll take a closer look at the usage-based charge, which is configured with a tiered price condition. The number of images is billed each month according to the defined tiered pricing. The technical resource ID is the serial number of the X-ray machine. The fee is charged in arrears and all usage charges are accumulated.
Charge Type | Rate Element | Unit of Measure | Price |
Usage-Based (Tiered) | IMAGES Rate Subelements:
| EA (Each) | Highres:
Lowres:
|
For our example, let’s imagine that there’s a warranty case for which the X-ray machine needs to be replaced with a new one with a different serial number. This is reflected in the subscription by a new subscription snapshot effective from the replacement date (July 15) with a changed technical resource ID (the new serial number of the replacement X-ray machine).
The new snapshot causes a split of the respective billing cycle into two rating periods, resulting in two charges per rate element and rate subelement on the bill. Each rate element, with the respective rate subelements, uses the number of images produced by the respective machine as the quantity.
The total number of images within a billing cycle is used to determine the price. For the calculation of the usage-based charge, it’s thus irrelevant which machine produced the image.
The data used for the calculation of prices is collected in a priceable document, which contains priceable items. For every charge defined in a rate plan of a subscription item and for every rating period, a priceable document item is composed. It contains all fields relevant to calculate the price for a charge in a specific rating period. In our example use case, the following priceable document items are created:
Item | rateElement | rateSubElement | billingCycleStart | ratingPeriodStart | ratingPeriodEnd | quantity |
1 | IMAGES | Highres | 2023-07-01 | 2023-07-01 | 2023-07-15 | 285 |
2 | IMAGES | Lowres | 2023-07-01 | 2023-07-01 | 2023-07-15 | 498 |
3 | IMAGES | Highres | 2023-07-01 | 2023-07-16 | 2023-07-31 | 315 |
4 | IMAGES | Lowres | 2023-07-01 | 2023-07-16 | 2023-07-31 | 522 |
*For simplicity, the productCode and other attributes are not listed in the table.
While a split of a billing cycle into several rating periods has no effect on the calculation of linear prices, it’s especially important with tiered and volume-based price conditions.
Without a new subscription snapshot (that is, no new technical resource, no split of the billing cycle), the price would be calculated in the following way:
The total quantity for July is 600 high resolution images (285 + 315) and 1020 low resolution images (498 + 522). This would result in the following net amounts:
Now, in our warranty scenario, the new subscription snapshot impacts the calculation of the price. With the split of the billing cycle into two rating periods, the net amount is distributed across the corresponding charges as follows:
To achieve this kind of price calculation when a billing cycle is split into several rating periods, the pricing configuration in your price element specification needs to consider the aggregation of quantities across multiple rating periods. We enable this by defining an aggregation in the Manage Aggregation Catalog app.
First, we define grouping criteria to group our items for aggregation. All items within a group share grouping criteria with the same value. For our example, we use the following fields as grouping criteria:
As the item contribution, we select quantity. This defines the quantity as a source field used in the calculation step in the price element specification.
In our example scenario, we don’t require any additional conditions defined in business rules, so we leave it as None.
Then, we can use this aggregation in the pricing tree of our price element specification. First, the system checks if there is an aggregation defined. Then, it uses the calculated aggregation total as the scale value and the item contribution as the quantity to be priced in the Calculate price element function.
Finally, in the Manage Billing Data app, we can see all the charges for the respective rating periods and the calculated net amount in the bill item.
So, this is how you can define aggregations for usage-based charges. If you’d like to learn more about aggregations, check out this blog post, in which we’ll explain how you can configure aggregations with included quantities. Also, have a look at our Pricing with Pricing Schemes: Configuration Guide for more information about usage aggregation.
We recommend using aggregations to ensure that if a billing cycle is split into several rating periods, the total aggregated quantity across all rating periods within the billing cycle can be determined to calculate the price. This is especially important if you use volume-based and tiered price conditions.
If you find this post helpful, please like it and stay tuned for more updates following the tag SAP Subscription Billing.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
2 | |
2 | |
2 | |
1 | |
1 | |
1 |