We are often asked what happened to SAP Revenue Accounting and Reporting in S/4HANA Cloud Public Edition. Is it available?
The short answer is: Yes, but.
RAR – as it is usually abbreviated – in the public cloud is called Contract-Based Revenue Recognition (CBRR). The scope items 3KK for IFRS or 3VS for US GAAP provide more details around the available scope. Technically, CBRR is based on the optimized features of revenue accounting inbound processing and contract management, versus what you may know as the classic features under SAP ECC.
However - as we are not getting tired to point out - we must understand the public cloud as more than just a set of functionalities. Essentially, it’s all about defined end-to-end scenarios, especially when it comes to the topic of revenue recognition.
For the areas of sell from stock, services, and projects, with event-based revenue recognition already sophisticated functionality is available (see links below). These scenarios are usually more cost and profitability driven where a tight integration into controlling and accounting as well as the operational scenario is of essence.
In contrast for the subscription business with its contract-based revenue streams, scenarios may be decoupled from an operational order management and billing system and often come with a higher complexity in relation to the revenue recognition accounting standard of IFRS 15 or ASC 606.
This is where CBRR fits in nicely, by either providing an integration of external order, fulfillment, cost, and invoice events through APIs registered in SAP's Business Accelerator Hub (formerly also called SAP's API Hub), as seen below …
... or by providing an end-to-end scenario based on SAP Subscription Billing with Contract Accounting and Invoicing and CBRR.
In the following, we would like to outline the latter.
And what is better than to explain the functionality based on a scenario.
Let’s imagine a company selling electrical vehicle (EV) charging services. A subscription in our example includes a 12-month package with a recurring baseline amount of 5 EUR and a usage-based component. The integration between Subscription Billing with S/4HANA Cloud Public Edition in general utilizes the same objects as we already outlined in the blog describing Financial Accounting for SAP Subscription Billing with Sales Billing in S/4HANA Cloud.
The subscription is mapped into a provider contract and the billing forecast into a billing plan to outline the scheduled billings from Subscription Billing. The difference here is that the provider contract is used in its initial sense, which is a contract object for the purpose of receivables management.
In contrast, in the scenario for the integration with Sales Billing we use the provider contract in a specific flavor for Sales Billing and rather as a proxy object for controlling and revenue recognition to be attributed in the market segment.
Also, when it comes to the integration of the pre-bills from Subscription Billing these are mapped into billable items in Contract Accounting and Invoicing which are then translated into billing and invoicing documents in Convergent Invoicing and - once invoiced - into open items in Contract Accounting.
In our scenario we created the subscription from Subscription Billing.
Once the subscription has been created, a billing forecast is scheduled for the baseline fee for the time frame of 12 months and a monthly billing of 5 EUR.
For the usage-based scenario a technical resource has been maintained where later we will track the usage.
The pricing in our use case is rather simple when it comes to the baseline fee, which is 5 EUR per month. For the usage-based scenario a look-up table is used in the Price Calculation service, which calculates a price depending on certain attributes (e.g., electric current AC / DC) and the usage.
If the integration with Convergent Invoicing and Contract Accounting has been activated through scope item Subscription Management with Convergent Invoicing (5IK), a provider contract is created with the corresponding items.
You will require the role Administrator (Convergent Invoicing) (SAP_BR_INVOICING_ADMIN_CINV) for the apps integrating with CBRR: Display Transfer Records and Transfer to Revenue Accounting.
Once a provider contract has been created or updated a transfer record is created, that already shows the structure of the order revenue accounting item. For this you need the scope item Contract Accounting - Contract-Based Revenue Recognition (3L3).
In the integration with CBRR you can create the order items either only based on the provider contract information or based on the provider contract using billing plan data.
For the integration with Subscription Billing for one-off and recurring charges, we utilize the second option, which allows a more granular configuration for example utilizing different price conditions. For usage-based scenarios the information is taken from the provider contract and enhanced through configuration in CBRR to determine the corresponding transaction price (Link to Online Documentation).
The Display Transfer Records – Revenue Accounting app allows you to display the transfer records and related pricing conditions. As this app only shows the transfer records you must use the application job Transfer to Revenue Accounting to schedule a periodic transfer of the records.
For a transfer of fulfillment records as in the context of usage-based scenarios the function aggregates billable items into fulfillment items for revenue accounting and therefore supports a separation of the fulfillment event from the actual timing of the invoice (User Assistance Link).
In S/4HANA Cloud Public Edition we only use the optimized inbound processing. Inbound processing is the component between a sender component (here Convergent Invoicing) and the contract management in revenue accounting. If there are no exceptions, the system processes the revenue accounting items directly after the transfer and creates the revenue contracts and performance obligations. If there are exceptions, the processing of the revenue accounting items is postponed, and you can post-process the items from the Manage Revenue Accounting Items app.
In our case a revenue contract has been created which you can find by searching with the subscription number as operational document in the Monitor Revenue Contracts app.
The revenue contract is a contract from an accounting perspective following the 5-step model of IFRS15, which starts with the identification of the contract with the customer. You may wonder how we get to a transaction price of 660 EUR, as the price from the monthly base fee was only 5 EUR per month over a time of 12 months (12 x 5 EUR = 60 EUR). For this let’s move onto the second step of IFRS15 which is the identification of performance obligations within the contract.
In the performance obligation overview, you can see two performance obligations. Note that the screen shot below is already a few steps ahead and shows revenue and invoices already posted, which is explained in the following steps.
For the performance obligation for EV_Charging a quantity of 1200 KWH has been estimated through the revenue accounting immanent rules engine. The transaction price was calculated based on 1200 KWH multiplied by 0,50 EUR which leads to transaction price of 600 EUR. The standalone selling price was calculated at the same price. The POB is fulfilled event-driven based on the consumption from the usage.
For the second POB, the transaction price comes from the billing plan. The SSP is also calculated at 600 EUR. The POB is fulfilled event-driven based on the customer invoice.
The revenue is allocated between the performance obligations based on the relative SSP, which is 330 EUR per POB.
As a next step we close the first bill, which in our case is the 5 EUR for the first period. Usually, the bills are closed automatically according to the settings in Subscription Billing.
From the bill in Subscription Billing, billable items are created, which then can be billed and invoiced in Convergent Invoicing. The invoice in our case is also the basis for creating the transfer records for the invoice revenue accounting items. The system generates invoice items when an invoicing document is created or reversed.
You process the invoice revenue accounting items as part of the periodic transfer application program you have seen before. Once the items have been processed, the information is updated for the revenue contract, which you can see as Billed Receivables.
As a next step, we receive the consumption records for the first period. In our case, the usage has been tracked manually in Subscription Billing, usually you may receive this through automated interfaces. We record a usage of 200 KWH against our technical resource ID.
Also, the bill for the usage is closed – in our case manually. We do this here in a stepwise approach to show the effects. In the real world, this would be an automated process that bundles all relevant activities, e.g., here all recurring amounts and usages that fall into a reference period. For the 200 KWH and based on the rules in the look-up table the system calculated a usage amount of 104 EUR (200 KWH x 0,52 EUR).
We can find a comprehensive overview of all billing relevant events in the Invoicing Overview of Contract Accounting and Invoicing. The overview shows the billable items and indicates if a billing and invoicing has already been performed. Convergent Invoicing as the name outlines allows converging multiple billing events.
It also shows the consumption records that have been processed, in our case the usage of 200 KWH.
Let’s get back to Revenue Accounting. When loading billable items, Convergent Invoicing generates fulfillment transfer records at billable item level. Whether a billable item leads to the creation of a fulfillment item is derived from the service type that you assign to the billable item in configuration settings.
The fulfillment items are transferred using the Transfer to Revenue Accounting app. This app does not generate fulfillment items for each billable item but aggregates the fulfillment transfer records on billable item level before transfer. This creates a transfer record for each aggregate. This reduces the volume of data for the fulfillment items to be transferred. Afterwards, the app forwards the fulfillment items to Contract-Based Revenue Recognition. In our case no aggregation was necessary as there was only one billable item for usage.
After fulfillment and billing the revenue contract shows revenue as following:
For the usage-based EV Charging POB, revenue has been recognized as 200 KWH / 1200 KWH = 16,67% * 330 EUR = 55 EUR.
For the recurring charge, revenue is recognized with the customer invoice, which is 5 EUR so far. 5 EUR / 60 EUR = 8,3 % (in this case on quantity-based but value-based) * 330 EUR = 27,50 EUR.
At month end now we must calculate contract liability and asset for the given contracts. This is again a periodic job, which however you can also start from the revenue contract.
If you have time-based revenue where revenue is to be recognized ratably, before running this program you would first run the Transfer Revenue program in Revenue Accounting. In our case, the revenue is recognized event-based through the usage and the customer invoice, and the Transfer Revenue program is not necessary.
After this manually triggered execution, you will find a contract liability for the revenue contract of 26,50 EUR, because of an overall billing of 109 EUR minus the recognizable revenue of 82,50 EUR. In S/4HANA Cloud Public Edition the direct posting is activated, which means that the results of the application jobs are directly posted into the universal journal.
Let me summarize: Above you have seen a complete subscription to revenue process. Usually this would run in an orchestrated and automated end-to-end process utilizing the application jobs in S/4HANA Cloud Public Edition with little need for manual intervention, for explanatory reasons this was broken out in more detail.
But what do you need to configure? This is what you will find in the following steps.
In S/4HANA Cloud Public Edition, a lot of the required configuration such as G/L accounts etc. has been preconfigured through best practices that are packaged in the scope items mentioned above. The integration between the BTP app SAP Subscription Billing and S/4HANA Cloud you have set up, which is supported through extensive setup guides.
The integration of master data such as customer and material / products has also been setup. For our scenario we used the materials EV_CHARGING and EV_RECURRING.
But there are some specific steps to be explained as follows:
To setup and perform the steps above I have assigned myself to the following roles:
- Configuration Expert - Business Process Configuration: SAP_BR_BPC_EXPERT
- Configuration Expert (Subscription Billing): SAP_BR_CONFIG_EXPERT_SBL
- Subscription Specialist (Subscription Billing): SAP_BR_SUBSCR_BILLG_SPCLST
- Pricing Specialist (Subscription Billing): SAP_BR_PRICING_SPCLST_SBL
- Administrator (Convergent Invoicing): SAP_BR_INVOICING_ADMIN_CINV
- Invoicing Specialist (Convergent Invoicing): SAP_BR_INVOICING_SPEC_CINV
- Revenue Accountant: SAP_BR_REV_ACCOUNTANT
- Administrator - Revenue Accounting: SAP_BR_REV_ADMIN
- Accounts Payable and Receivable Accountant (FI-CA): SAP_BR_APR_ACCOUNTANT_FICA
- Reconciliation Specialist - Accounts Payable and Receivable (FI-CA): SAP_BR_RECONC_SPEC_APR_FICA
For Subscription Billing I do not want to go into the details of rate plans and pricing, however, would like to only highlight the configuration of the billing forecast you have seen earlier in the demo:
For this we are in the Manage Business Configuration – Subscription Billing app in the role of the Pricing Specialist. A billing forecast has been maintained for 12 months. The subscription is replicated to S/4HANA Cloud and a contract account is required in the context of the integration with Contract Accounting and Invoicing.
In CBRR you also must add a few settings. You can find this under Finance > Revenue and Cost Accounting > Contract-Based Revenue Recognition in the Solution Builder.
To utilize CBRR the company code needs to be assigned to the accounting principle revenue accounting should be utilized.
The main configuration is done through the rules engine Business Rules Framework Plus (BRFplus). For revenue accounting you use BRFplus in a simplified format in S/4HANA Cloud. Main requirement is to derive the attributes of the revenue contract. The rules are split out as shown below.
For the product EV_CHARGING the transaction price had to be estimated based on an estimated consumption. In our 12-month contract we assumed a quantity of 1200 KWH which is priced at a price of 0,50 EUR per KWH. This is how the transaction price has been derived.
Furthermore, the POB attributes must be derived. As per below, for the product EV_CHARGING we derive a corresponding POB name and the POB Type CONTRACT.
The fulfillment is based on the consumption events, and only the final invoice changes the transaction price as kind of a true up.
For the recurring product, the fulfillment event is the customer invoice.
As we want to recognize the revenue based on the invoice value proportional to the total transaction price you must flag here that the fulfillment is amount value-based.
And finally, we need a standalone selling price (SSP). For the recurring product this is maintained as 600 EUR.
For the usage-based scenario you need to indicate that the SSP is calculated based on the provided quantity.
That’s it basically. With a few steps you can enhance your scenario for Subscription Billing and Convergent Invoicing with the integration into Contract-Based Revenue Recognition, provided that Subscription Billing and the integration into S/4HANA Cloud are already setup.
Are you interested to learn more about revenue recognition in S/4HANA Cloud Public Edition?
Then also have a look at the following blogs:
Financial Accounting for SAP Subscription Billing with Sales Billing in S/4HANA Cloud
Margin Analysis 4 Sell from stock in S/4HANA
Professional Services in the SAP S/4HANA Cloud Public Edition - The Collection
What’s New in Finance for Engineer Products and Systems (based on Engineer-to-order)
- SAP Managed Tags:
