Subscriptions and recurring revenue patterns have become a hot topic for many customers and across all industries. The scenarios range from the sales of digital assets such as the right to use software to the sales of physical goods such as consumables.
Subscription models offer benefits to both the provider of the subscription and the end customer: The provider can set up a steady, predictable revenue flow, and the end customer can spread an upfront investment over time, allowing for a predictable budgeting and flexibility to adapt the right level of service and features over time.
The integration of SAP Subscription Billing with S/4HANA Cloud, public edition (in the following referred to as S/4HANA Cloud) enables you to support subscription-based business models linked to a powerful Finance solution. In this blog, we'll take a deep dive into the integration with a special focus on the aspects of revenue recognition and margin analysis.
SAP Subscription Billing offers numerous capabilities which are well described in many blogs or in the user assistance. For instance, you can find a great set of resources here. Subscription Billing has been designed as a set of microservices that can be integrated also with non-SAP solutions. The real power, however, comes with the integration into S/4HANA Cloud, which we want to explore here.
The integration is based on two integration scenarios: Integration with Sales Billing and the integration with Contract Accounting and Invoicing in S/4HANA Cloud.
In this blog we want to focus on the integration with Sales Billing with the special focus on Finance. Well, in fact it's even more than that as we'll talk about the full end-to-end scenario starting with the integration into the solution order on one side and controlling and accounting at the other end of the spectrum. If your business requires a bundling of subscriptions with other sales types, such as projects, service documents and sales orders, the solution order is a perfect fit. And the tight integration into accounting and controlling allows you to do a combined margin analysis of revenues and costs on the aggregated level of the solution order.
Interested? OK, then let’s get started. Before we get into a little system-based scenario, some fundamental aspects first.
SAP Subscription Billing is based on SAP’s Business Technology Platform. Integration with S/4HANA Cloud is done via services, enabling the applications to run decoupled from one other.
Each subscription in Subscription Billing is replicated to a provider contract in S/4HANA, which represents the accounting view. This means the provider contract holds additional attributes that are relevant for the follow-on processes in Finance. For example, it holds the revenue recognition key for event-based revenue recognition, or the profit center. The provider contract becomes part of the market segment and the Universal Journal and, simply speaking, is the basis for profitability reporting in S/4HANA Cloud when it comes to subscriptions.
We must also explore the underlying data model a bit further. Firstly, the products defined in Subscription Billing are synchronized with the materials in S/4HANA Cloud. The subscription product holds a rate plan with rate elements, which could represent, for example, a one-time fee or a recurring charge based on usages or number of licenses. Essentially a product entered in a subscription item could be broken down into 1 to n rate elements. In this setup, not only is the top-level product mapped into a material in S/4HANA but also the underlying rate elements refer to materials. Usually, you want to understand how well a product sells. Consequently, in Finance the top-level product is mapped into the product sold, while the sub level materials are passed through as “consumption” materials.
Another important element in the data model is the billing forecast and billing plan. A common requirement, especially in subscription scenarios, is to recognize revenue independently from billing – which is a fundamental requirement of the revenue accounting standard IFRS 15. For this purpose, the billing forecast in Subscription Billing provides estimates of expected billing amounts for a given time frame. The billing forecast is mapped to the billing plan in Convergent Invoicing in S/4HANA. While the billing plan is a standalone business object (in contrast to the billing plan in service contracts, for example), here it can be seen as an attachment to the provider contract, which is used by event-based revenue recognition to accrue revenue independently of the actual invoice amount and dates.
To complete the picture, we need to talk about billing. Subscription Billing is responsible for the rating and pre-billing of subscriptions. For the pre-billing, Subscription Billing collects all relevant information, such as usages, up to the billing due date. Once the pre-bill is closed it's transferred to S/4HANA and translated into so-called billing document requests (BDRs). BDRs are invoiced in Sales Billing which creates the corresponding journal entries in accounting. If event-based revenue recognition is used, the billed revenue from the invoice is deferred.
The following provides an overview of these fundamental integration concepts:
You may want to follow the link to the user assistance for a more interactive example.
Now, what’s better than a little example? Let’s imagine our company is selling CAD software combined with a quick start implementation service. The software is billed upfront annually and the pricing is based on the number of licensed users. The implementation project is a fixed-priced project – we'll only touch on this briefly. We start our process from the solution order that allows the combination of sales types for coherent reporting.
In the solution order for our customer, we've entered the subscription billing item with the product CAD_GROUPBOX_TIER. In addition, a project item for the quick starter implementation service has been added with product CAD_IMP_PROJECT.
For the subscription billing item in the solution order, additional information has been entered, such as the dates and other subscription parameters. In our case the subscription starts on Jan 1st, 2023, with an expected term of 12 months.
For the product (sold) CAD_GROUPBOX_TIER, two rate elements have been defined: a one-time charge and a recurring charge. The rate elements are also mapped to products, in our case this is the product LICENSES for the recurring charge and ONETIME for the one-time charge.
In the solution order you can also find the relevant subscription parameters from the rate plan configuration in SAP Subscription Billing. In our case this is the number of licenses. If you create the subscription from the solution order manually you could run a simulation (button Simulate) which utilizes the rating functions in SAP Subscription Billing and considers the current parameters in the solution order subscription item. Using the Price Calculation service, we could have applied discounts as well, but this will be a topic of another blog.
Note that once the subscription billing item in the solution order has been released, you currently cannot change the parameters anymore in the solution order. You therefore need to make the changes in the follow-up items, in this case for example the subscription in SAP Subscription Billing.
Once the items in the solution order get released, this creates the follow-up items. In our case this is the project in CPM (Commercial Project Management) and the subscription in SAP Subscription Billing. In the solution order you can monitor these follow-up transactions from the solution order progress overview. As you can see in the figure below, subscription SB1406 has been created from the solution order. You can also see that further transactions have been processed, such as the billing document request, invoice and corresponding journal entries, which we'll discuss later.
From this overview you can also navigate directly to the subscription in SAP Subscription Billing where you can trigger follow-up steps such as adding more user licenses or renewing the subscription.
In the figure above you can see that the Price Calculation service is used for more sophisticated pricing options. As a result, the conditions on the rate elements can be customized, for example by applying an additional discount. You could do the same also from the solution order item representing the subscription.
Usually customers use S/4HANA Cloud as their Finance backbone. This has various implications when a subset of the data in the subscription is also needed in S/4HANA. For example, if we want to analyze revenues and costs related to a subscription, or if we need information such as the profit center that's not available in the subscription system. Also, if we want to recognize revenue as the service is consumed and only invoiced in arrears. For all these use cases an accounting view of the subscription in S/4HANA is required. This accounting view is the provider contract.
When the subscription in SAP Subscription Billing is created this can automatically trigger the creation of a provider contract. To enable this, you maintain the subscription settings as shown below (<Replicate Subscriptions to Provider Contracts>).
From a content perspective you will need to activate and configure scope item 57Z: Subscription Management with Sales Billing. For example, you need to set up Event Mesh and configure the communication arrangement.
Let’s assume that the setup has been done. In S/4HANA you can now find a provider contract replicated from the subscription as shown in the figure below.
It may not be immediately visible, but the provider contract for sales billing has been created in a specific flavor for the sales billing scenario and holds different attributes than the provider contract as utilized by contract accounting. These attributes are, for example, the revenue recognition key, the product sold, and the reference to the solution order item. Creating the provider contract with a special category for sales billing allows a clear separation of the integration scenarios.
Furthermore, you can see that the structure of a subscription billing item with two rate elements is resolved into provider contract items with the product sold CAP_GROUPBOX_TIER from the subscription billing item and the sub-level products from the rate elements. Additionally, a revenue recognition key PPCA and a profit center has been derived.
Let's first talk about the profit center. The profit center maintained on the item will be consistently used for all postings on the provider contract. The profit center currently (CE2308) needs to be derived based on configuration. You can find the configuration in the Manage Your Solution app under Finance > Contract Accounting > Provider Contract > Define Specifications for Derivation of Standard Account Assignment (102679), in the example below the profit center YB900 is derived.
You can find this under Contract Accounting as the provider contract is also used in other scenarios predominantly around Contract Accounting. The profit center in SAP represents a company area for which a separate period-based profit is determined.
In addition, you may need to recognize revenue separately from the invoicing event and spread the recognized revenue over time. In the integration scenario with sales billing, event-based revenue recognition (EBRR) is used. EBRR requires the activation of the scope item 5DQ: Event-Based Revenue Recognition - Subscription Billing and either 5DR: Event-Based Revenue Recognition - Subscription Billing - IFRS or 5DS: Event-Based Revenue Recognition - Subscription Billing - US GAAP.
As per the figure, above the revenue recognition key PPCA has been derived. You can find the configuration in the Manage Your Solution app under Finance > Profitability Analysis > Revenue Recognition > Derivation of Recognition Keys for Provider Contracts (105138).
The revenue recognition key essentially summarizes the calculation and posting rules that are applied for the account assignment of the provider contract item. Before we go into the details of these rules, let's first continue along the process.
Revenue can be recognized as it's earned or in other words as the service is consumed by the customer. This is independent from the invoice and even though there was no billing you can accrue revenue according to the fulfillment progress. For that the expected total contract value needs to be known to revenue recognition in S/4HANA Cloud. For this purpose, Subscription Billing is able to create a revenue forecast that's replicated into a billing plan linked to the provider contract item. In the figure below you can find the corresponding configuration in Subscription Billing.
Our subscription is set up as a subscription with an annual billing cycle. The settings for the billing forecast utilize 3 billing cycles. As a result, you receive a billing forecast from January 1, 2023 to December 31, 2025, which as you can see covers the one-time charge and the recurring charge.
Before we continue with the process of revenue recognition, let's first focus on finishing the billing process from Subscription Billing. Once the billing cycle is closed, the pre-billing information in Subscription Billing is transferred into billing documents requests (BDRs). The BDRs are created with the same structure as the subsequent invoice utilizing provider contract item information. In our invoice the first BDR covers the one-time charge of 1.000 USD against provider contract item SB1406-1 and the recurring charge of 10.000 USD against provider contract item SB1406-2. The BDR is invoiced in Sales Billing creating the corresponding financial documents as shown in the figure below.
Let’s get back to the topic of revenue recognition. In our case the customer is billed in advance. As the subscription can be utilized over time, the billed revenue is deferred real-time based on the revenue recognition key assigned. Real-time means that with the posting of the financial document for the invoice a secondary document for the revenue deferral is posted.
Event-Based Revenue Recognition is based on the individual provider contract item and billed revenue and deferred revenue are posted with reference to the provider contract item.
Revenue is recognized periodically for a monthly financial posting period. EBRR can also recognize revenue real-time, if corresponding events such as time confirmations or goods movements are provided. In the context of Subscription Billing, you recognize the revenue ratably for the time the subscription could be used up to the end of the financial posting period, for example in January up to the 31st. In our case, the recognized revenue reduces the deferred revenue as visible in the figure below. For the one-time rate element the revenue is recognized upfront, whereas the revenue for the recurring rate element is spread over time. The base for this calculation is the planned revenue in the billing plan.
If the customer is billed in arrears, revenue is accrued first up until the billing happens. As such the provider contract item is in either in a deferred revenue position, if the invoiced amount is higher than the recognized revenue to date, or in an unbilled or accrued revenue position, if the recognizable revenue is higher than the billed amount up to date.
Event-Based Revenue Recognition can run fully automated. For the period-end close you usually schedule the batch job Run Event-Based Revenue Recognition – Provider Contracts that typically runs at month end at least.
Revenue is recognized up to the end of the fiscal year period you have entered here. This means that if, for whatever reason, you have not run revenue recognition for a provider contract before in an earlier period, EBRR performs a revenue catch-up. You can also enter a future period, and EBRR then recognizes the revenue up to the end of this period, provided the fiscal period is open. The posting date of any journal entries from this run is the last date of the period you have entered. Clearly the common use case is to run revenue recognition for the current period rather than scheduling the jobs for the distant future.
EBRR in general is self-correcting. This means that if a posting turns out to be not longer accurate, you can run EBRR again for the respective period and it will perform a revenue catch-up for the given period. Just as an example, say you recognized revenue but the subscription was cancelled. If you run revenue recognition again for the given period, the revenue will be adjusted.
Alternatively to the periodic jobs, every EBRR integration scenario also comes with a monitoring application: Event-Based Revenue Recognition – Provider Contracts.
Revenue recognition is performed on the basis of items. As a result, in the app you can find the individual provider contract items. The app shows the individual KPIs per item, for example billed revenue, recognized revenue for P&L and accrued and deferred revenue on the balance sheet side.
The monitoring apps are not intended as reporting apps, although they provide a lot of great information. Their purpose is rather to perform potentially necessary manual activities, such the re-valuation of provider contract items, or the change of revenue recognition keys.
In the app, with Set Parameters you can change the To Fiscal Year Period or the ledger, for example if you want to perform a re-valuation of the provider contract item.
The re-valuation functionality in the monitoring app is especially helpful if you want to perform a testing of the configured functionality. Here, you can directly post the recognized revenue or perform a simulation.
If you have performed a simulation, please also have a look at the explanation of the simulation. It provides some additional insights on how revenue was recognized or even where potential configuration could be missing. A common mistake is, for example, that additional GL accounts or conditions have been added but potentially were not considered in the EBRR configuration.
While the monitoring app provides great information, there are far better apps available for reporting purposes and for slicing and dicing the posting data. For example, the app Product and Service Margins or the app Display Margin Analysis.
In the apps you can filter by provider contract or solution order.
How does that work?
Provider contract and provider contract item as well as solution order and solution order item have been added to the profitability segment in Margin Analysis. These fields are automatically filled, together with the subscription item information during business processes that reference a subscription item.
For example, in the case of SD invoices created from an SD billing document request with reference to a subscription item, the information about the subscription item (provider contract and provider contract item) is transferred to the profitability segment of the SD billing document request created by the subscription billing component. The following SD invoice transfers these profitability segments and the information about the subscription items to the G/L line items created for this invoice.
In the above reports, these fields then can be used as follows:
Conclusion
The integration of SAP Subscription Billing with event-based revenue recognition in S/4HANA Cloud allows you to recognize revenue for subscriptions that are processed as provider contracts. The provider contract and item are available in the profitability segment. In margin analysis this allows reporting of revenues and cost either aggregated across all sales and service transactions in a solution order, or specifically for an individual subscription.
Subscription models offer benefits to both the provider of the subscription and the end customer: The provider can set up a steady, predictable revenue flow, and the end customer can spread an upfront investment over time, allowing for a predictable budgeting and flexibility to adapt the right level of service and features over time.
The integration of SAP Subscription Billing with S/4HANA Cloud, public edition (in the following referred to as S/4HANA Cloud) enables you to support subscription-based business models linked to a powerful Finance solution. In this blog, we'll take a deep dive into the integration with a special focus on the aspects of revenue recognition and margin analysis.
SAP Subscription Billing offers numerous capabilities which are well described in many blogs or in the user assistance. For instance, you can find a great set of resources here. Subscription Billing has been designed as a set of microservices that can be integrated also with non-SAP solutions. The real power, however, comes with the integration into S/4HANA Cloud, which we want to explore here.
The integration is based on two integration scenarios: Integration with Sales Billing and the integration with Contract Accounting and Invoicing in S/4HANA Cloud.
In this blog we want to focus on the integration with Sales Billing with the special focus on Finance. Well, in fact it's even more than that as we'll talk about the full end-to-end scenario starting with the integration into the solution order on one side and controlling and accounting at the other end of the spectrum. If your business requires a bundling of subscriptions with other sales types, such as projects, service documents and sales orders, the solution order is a perfect fit. And the tight integration into accounting and controlling allows you to do a combined margin analysis of revenues and costs on the aggregated level of the solution order.
Interested? OK, then let’s get started. Before we get into a little system-based scenario, some fundamental aspects first.
SAP Subscription Billing is based on SAP’s Business Technology Platform. Integration with S/4HANA Cloud is done via services, enabling the applications to run decoupled from one other.
Each subscription in Subscription Billing is replicated to a provider contract in S/4HANA, which represents the accounting view. This means the provider contract holds additional attributes that are relevant for the follow-on processes in Finance. For example, it holds the revenue recognition key for event-based revenue recognition, or the profit center. The provider contract becomes part of the market segment and the Universal Journal and, simply speaking, is the basis for profitability reporting in S/4HANA Cloud when it comes to subscriptions.
We must also explore the underlying data model a bit further. Firstly, the products defined in Subscription Billing are synchronized with the materials in S/4HANA Cloud. The subscription product holds a rate plan with rate elements, which could represent, for example, a one-time fee or a recurring charge based on usages or number of licenses. Essentially a product entered in a subscription item could be broken down into 1 to n rate elements. In this setup, not only is the top-level product mapped into a material in S/4HANA but also the underlying rate elements refer to materials. Usually, you want to understand how well a product sells. Consequently, in Finance the top-level product is mapped into the product sold, while the sub level materials are passed through as “consumption” materials.
Another important element in the data model is the billing forecast and billing plan. A common requirement, especially in subscription scenarios, is to recognize revenue independently from billing – which is a fundamental requirement of the revenue accounting standard IFRS 15. For this purpose, the billing forecast in Subscription Billing provides estimates of expected billing amounts for a given time frame. The billing forecast is mapped to the billing plan in Convergent Invoicing in S/4HANA. While the billing plan is a standalone business object (in contrast to the billing plan in service contracts, for example), here it can be seen as an attachment to the provider contract, which is used by event-based revenue recognition to accrue revenue independently of the actual invoice amount and dates.
To complete the picture, we need to talk about billing. Subscription Billing is responsible for the rating and pre-billing of subscriptions. For the pre-billing, Subscription Billing collects all relevant information, such as usages, up to the billing due date. Once the pre-bill is closed it's transferred to S/4HANA and translated into so-called billing document requests (BDRs). BDRs are invoiced in Sales Billing which creates the corresponding journal entries in accounting. If event-based revenue recognition is used, the billed revenue from the invoice is deferred.
The following provides an overview of these fundamental integration concepts:
- Subscription > Provider Contract
- Product and Rate Element > Product Sold and Material
- Billing Forecast > Billing Plan
- Pre-Bill > Billing Document Request > Billing Document > Journal Entry.
You may want to follow the link to the user assistance for a more interactive example.
Now, what’s better than a little example? Let’s imagine our company is selling CAD software combined with a quick start implementation service. The software is billed upfront annually and the pricing is based on the number of licensed users. The implementation project is a fixed-priced project – we'll only touch on this briefly. We start our process from the solution order that allows the combination of sales types for coherent reporting.
In the solution order for our customer, we've entered the subscription billing item with the product CAD_GROUPBOX_TIER. In addition, a project item for the quick starter implementation service has been added with product CAD_IMP_PROJECT.
For the subscription billing item in the solution order, additional information has been entered, such as the dates and other subscription parameters. In our case the subscription starts on Jan 1st, 2023, with an expected term of 12 months.
For the product (sold) CAD_GROUPBOX_TIER, two rate elements have been defined: a one-time charge and a recurring charge. The rate elements are also mapped to products, in our case this is the product LICENSES for the recurring charge and ONETIME for the one-time charge.
In the solution order you can also find the relevant subscription parameters from the rate plan configuration in SAP Subscription Billing. In our case this is the number of licenses. If you create the subscription from the solution order manually you could run a simulation (button Simulate) which utilizes the rating functions in SAP Subscription Billing and considers the current parameters in the solution order subscription item. Using the Price Calculation service, we could have applied discounts as well, but this will be a topic of another blog.
Note that once the subscription billing item in the solution order has been released, you currently cannot change the parameters anymore in the solution order. You therefore need to make the changes in the follow-up items, in this case for example the subscription in SAP Subscription Billing.
Once the items in the solution order get released, this creates the follow-up items. In our case this is the project in CPM (Commercial Project Management) and the subscription in SAP Subscription Billing. In the solution order you can monitor these follow-up transactions from the solution order progress overview. As you can see in the figure below, subscription SB1406 has been created from the solution order. You can also see that further transactions have been processed, such as the billing document request, invoice and corresponding journal entries, which we'll discuss later.
From this overview you can also navigate directly to the subscription in SAP Subscription Billing where you can trigger follow-up steps such as adding more user licenses or renewing the subscription.
In the figure above you can see that the Price Calculation service is used for more sophisticated pricing options. As a result, the conditions on the rate elements can be customized, for example by applying an additional discount. You could do the same also from the solution order item representing the subscription.
Usually customers use S/4HANA Cloud as their Finance backbone. This has various implications when a subset of the data in the subscription is also needed in S/4HANA. For example, if we want to analyze revenues and costs related to a subscription, or if we need information such as the profit center that's not available in the subscription system. Also, if we want to recognize revenue as the service is consumed and only invoiced in arrears. For all these use cases an accounting view of the subscription in S/4HANA is required. This accounting view is the provider contract.
When the subscription in SAP Subscription Billing is created this can automatically trigger the creation of a provider contract. To enable this, you maintain the subscription settings as shown below (<Replicate Subscriptions to Provider Contracts>).
From a content perspective you will need to activate and configure scope item 57Z: Subscription Management with Sales Billing. For example, you need to set up Event Mesh and configure the communication arrangement.
Let’s assume that the setup has been done. In S/4HANA you can now find a provider contract replicated from the subscription as shown in the figure below.
It may not be immediately visible, but the provider contract for sales billing has been created in a specific flavor for the sales billing scenario and holds different attributes than the provider contract as utilized by contract accounting. These attributes are, for example, the revenue recognition key, the product sold, and the reference to the solution order item. Creating the provider contract with a special category for sales billing allows a clear separation of the integration scenarios.
Furthermore, you can see that the structure of a subscription billing item with two rate elements is resolved into provider contract items with the product sold CAP_GROUPBOX_TIER from the subscription billing item and the sub-level products from the rate elements. Additionally, a revenue recognition key PPCA and a profit center has been derived.
Let's first talk about the profit center. The profit center maintained on the item will be consistently used for all postings on the provider contract. The profit center currently (CE2308) needs to be derived based on configuration. You can find the configuration in the Manage Your Solution app under Finance > Contract Accounting > Provider Contract > Define Specifications for Derivation of Standard Account Assignment (102679), in the example below the profit center YB900 is derived.
You can find this under Contract Accounting as the provider contract is also used in other scenarios predominantly around Contract Accounting. The profit center in SAP represents a company area for which a separate period-based profit is determined.
In addition, you may need to recognize revenue separately from the invoicing event and spread the recognized revenue over time. In the integration scenario with sales billing, event-based revenue recognition (EBRR) is used. EBRR requires the activation of the scope item 5DQ: Event-Based Revenue Recognition - Subscription Billing and either 5DR: Event-Based Revenue Recognition - Subscription Billing - IFRS or 5DS: Event-Based Revenue Recognition - Subscription Billing - US GAAP.
As per the figure, above the revenue recognition key PPCA has been derived. You can find the configuration in the Manage Your Solution app under Finance > Profitability Analysis > Revenue Recognition > Derivation of Recognition Keys for Provider Contracts (105138).
The revenue recognition key essentially summarizes the calculation and posting rules that are applied for the account assignment of the provider contract item. Before we go into the details of these rules, let's first continue along the process.
Revenue can be recognized as it's earned or in other words as the service is consumed by the customer. This is independent from the invoice and even though there was no billing you can accrue revenue according to the fulfillment progress. For that the expected total contract value needs to be known to revenue recognition in S/4HANA Cloud. For this purpose, Subscription Billing is able to create a revenue forecast that's replicated into a billing plan linked to the provider contract item. In the figure below you can find the corresponding configuration in Subscription Billing.
Our subscription is set up as a subscription with an annual billing cycle. The settings for the billing forecast utilize 3 billing cycles. As a result, you receive a billing forecast from January 1, 2023 to December 31, 2025, which as you can see covers the one-time charge and the recurring charge.
Before we continue with the process of revenue recognition, let's first focus on finishing the billing process from Subscription Billing. Once the billing cycle is closed, the pre-billing information in Subscription Billing is transferred into billing documents requests (BDRs). The BDRs are created with the same structure as the subsequent invoice utilizing provider contract item information. In our invoice the first BDR covers the one-time charge of 1.000 USD against provider contract item SB1406-1 and the recurring charge of 10.000 USD against provider contract item SB1406-2. The BDR is invoiced in Sales Billing creating the corresponding financial documents as shown in the figure below.
Let’s get back to the topic of revenue recognition. In our case the customer is billed in advance. As the subscription can be utilized over time, the billed revenue is deferred real-time based on the revenue recognition key assigned. Real-time means that with the posting of the financial document for the invoice a secondary document for the revenue deferral is posted.
Event-Based Revenue Recognition is based on the individual provider contract item and billed revenue and deferred revenue are posted with reference to the provider contract item.
Revenue is recognized periodically for a monthly financial posting period. EBRR can also recognize revenue real-time, if corresponding events such as time confirmations or goods movements are provided. In the context of Subscription Billing, you recognize the revenue ratably for the time the subscription could be used up to the end of the financial posting period, for example in January up to the 31st. In our case, the recognized revenue reduces the deferred revenue as visible in the figure below. For the one-time rate element the revenue is recognized upfront, whereas the revenue for the recurring rate element is spread over time. The base for this calculation is the planned revenue in the billing plan.
If the customer is billed in arrears, revenue is accrued first up until the billing happens. As such the provider contract item is in either in a deferred revenue position, if the invoiced amount is higher than the recognized revenue to date, or in an unbilled or accrued revenue position, if the recognizable revenue is higher than the billed amount up to date.
Event-Based Revenue Recognition can run fully automated. For the period-end close you usually schedule the batch job Run Event-Based Revenue Recognition – Provider Contracts that typically runs at month end at least.
Revenue is recognized up to the end of the fiscal year period you have entered here. This means that if, for whatever reason, you have not run revenue recognition for a provider contract before in an earlier period, EBRR performs a revenue catch-up. You can also enter a future period, and EBRR then recognizes the revenue up to the end of this period, provided the fiscal period is open. The posting date of any journal entries from this run is the last date of the period you have entered. Clearly the common use case is to run revenue recognition for the current period rather than scheduling the jobs for the distant future.
EBRR in general is self-correcting. This means that if a posting turns out to be not longer accurate, you can run EBRR again for the respective period and it will perform a revenue catch-up for the given period. Just as an example, say you recognized revenue but the subscription was cancelled. If you run revenue recognition again for the given period, the revenue will be adjusted.
Alternatively to the periodic jobs, every EBRR integration scenario also comes with a monitoring application: Event-Based Revenue Recognition – Provider Contracts.
Revenue recognition is performed on the basis of items. As a result, in the app you can find the individual provider contract items. The app shows the individual KPIs per item, for example billed revenue, recognized revenue for P&L and accrued and deferred revenue on the balance sheet side.
The monitoring apps are not intended as reporting apps, although they provide a lot of great information. Their purpose is rather to perform potentially necessary manual activities, such the re-valuation of provider contract items, or the change of revenue recognition keys.
In the app, with Set Parameters you can change the To Fiscal Year Period or the ledger, for example if you want to perform a re-valuation of the provider contract item.
The re-valuation functionality in the monitoring app is especially helpful if you want to perform a testing of the configured functionality. Here, you can directly post the recognized revenue or perform a simulation.
If you have performed a simulation, please also have a look at the explanation of the simulation. It provides some additional insights on how revenue was recognized or even where potential configuration could be missing. A common mistake is, for example, that additional GL accounts or conditions have been added but potentially were not considered in the EBRR configuration.
While the monitoring app provides great information, there are far better apps available for reporting purposes and for slicing and dicing the posting data. For example, the app Product and Service Margins or the app Display Margin Analysis.
In the apps you can filter by provider contract or solution order.
How does that work?
Provider contract and provider contract item as well as solution order and solution order item have been added to the profitability segment in Margin Analysis. These fields are automatically filled, together with the subscription item information during business processes that reference a subscription item.
For example, in the case of SD invoices created from an SD billing document request with reference to a subscription item, the information about the subscription item (provider contract and provider contract item) is transferred to the profitability segment of the SD billing document request created by the subscription billing component. The following SD invoice transfers these profitability segments and the information about the subscription items to the G/L line items created for this invoice.
In the above reports, these fields then can be used as follows:
- Drilldown field for various reports
- Selection criteria for receiver data in cost center assessment to Margin Analysis
- Source fields in substitution rules for the Accounting: Market Segment business context
- Display-only field in the account assignment screens of the profitability segment
Conclusion
The integration of SAP Subscription Billing with event-based revenue recognition in S/4HANA Cloud allows you to recognize revenue for subscriptions that are processed as provider contracts. The provider contract and item are available in the profitability segment. In margin analysis this allows reporting of revenues and cost either aggregated across all sales and service transactions in a solution order, or specifically for an individual subscription.
- SAP Managed Tags:
