Dr. Gerold Wellenhofer and Volkmar Zahn
Continuing the blog series on Universal Parallel Accounting in SAP S/4HANA in 2022, where we have already looked at options for parallel valuations. We will now address the topic from the point of view of Revenue Recognition to explain how different material prices and cost rates are considered in event-based revenue recognition. We remember that the different valuations reflect the requirements of the various accounting principles.
For revenue recognition we must consider the complete end-to-end process with sales, services and projects as all integration scenarios come with their specific requirements. For example, in the context of sales we need to potentially deal with different material prices. In a project scenario you may have also different activity cost rates.
The focus area for event-based revenue recognition was initially S/4HANA Cloud, therefore you will find here also the biggest availability with integration scenarios for sell from stock, services, product-based sales and services as well as subscriptions.
For S/4HANA on premise or private cloud edition, EBRR initially was only used for the integration with project system. Further enablement introduced the integration for sell from stock, which is subsequently enhanced. With S/4HANA 2022, event-based revenue recognition will also be enabled for maintenance-centric service processes – but that is another story.
For our blog, we want to mainly look at the sell from stock and the project scenario in S/4HANA.
Sell from Stock scenario
A common use case in the sell from stock scenario are different material prices according to different accounting principles. That maybe the result of divergent depreciation rules you have applied.
The rules how revenue is recognized by event-based revenue recognition are grouped into revenue recognition keys, that describe the data sources, revenue and cost recognition methods, as well as the posting rules for revenue/cost and accrued/deferred revenue on the balance sheet side. For the use cases of Universal Parallel Accounting this logic does not change, which also means that you will not need to do any extra configuration in EBRR for this purpose. Once UPA is activated with the corresponding business function, revenue recognition will work as described below.
In the sell from stock scenario the most common rule set is to recognize revenue when the transfer of control happens, this is usually the case when the goods issue is posted. Event-based revenue recognition allows you to accrue revenue for example based on an invoice simulation once the goods issue happens. Activating Universal Parallel Accounting allows you to use different material prices when posting into the different ledgers aligned with the underlying accounting principles. The revenue obviously cannot differ and is based on the transaction price with the customer.
As a consequence, the customer can report cost and revenues and the corresponding margin individually for each accounting principle.
Project System
For the integration with project system, typically customers use either a cost-based or revenue-based percentage-of-completion (PoC) method. We differentiate between real-time processing, e.g. when the time confirmations are posted, versus the period-end close. In the period-end close usually further re-valuations happen, generally those that are more time-consuming as they imply reading additional data (e.g. due to plan changes, or due to the netting between accrued and deferred).
In a nutshell, for a cost-based POC the progress is measured according to the actual cost versus planned cost. Different material prices or activity rates may lead to different actual cost in the relevant ledgers. Obviously, there can be only one fulfillment progress for a given project. EBRR in this case applies the PoC of the leading ledger.
For a revenue-based PoC, the PoC is calculated based on the actual revenue versus the planned revenue. This PoC is then applied to the planned cost. No issue with different cost rates you may think. Unfortunately, that is too easy as you have to keep in mind that the planned cost is only captured in the leading ledger. In order to consider different costs in other ledgers we therefore introduced a relative actual cost (RAC) ratio based on the actual cost in the respective ledger, versus actual cost in the leading ledger.
That all was a bit fast, and you are right demanding an example.
Let’s take again the example of the cost-based PoC.
Planning data can only be entered for the leading ledger 0L. In this case, revenues of 200€ and costs of 100€ have been planned. Based on the material prices or activity and expense rates in a given ledger, actual cost of 20€ is recognized in the leading ledger 0L and 30€ for the non-leading ledger 2L.
The percentage of completion (PoC) is evaluated in the leading ledger as actual costs/planned costs
PoC = 20€/100€ = 20%.
This percentage of completion is applied to the planned revenues (which is 200€ for all ledgers in this example), therefore,
Accrued revenue = 20%*200€ = 40€.
The calculation is applied during real-time processing and also in period-end closing.
As mentioned above, for a revenue-based PoC method the situation is slightly different.
Again, planning data for projects is entered only for the leading ledger, 0L in our case. We have the same situation as before, which is planned revenues of 200€ and planned cost of 100€ in the leading ledger 0L. For the actual cost, 20€ are posted in the leading ledger 0L and 30€ for the non-leading ledger 2L. The nature of the revenue-based PoC method is that these actual costs are deferred and recognized based on the ratio actual revenues (from the invoice) versus planned revenue.
Let’s apply this to the related use case. We billed the end customer with 20€, which leads to a percentage of completion (PoC) of 10% in the leading ledger (20€/200€).
This PoC is applied to the planned cost of 100€ which leads to an accrued cost of 10%*100€ = 10€
To consider different costs in the other ledgers, a relative actual cost (RAC) rate has been introduced with:
RAC (2L) = actual costs (2L) / actual costs leading ledger (0L) = 1,5
Before first period closing, an RAC of 1 is applied. In period closing and for later calculations, costs are calculated with updated RAC as:
Recognized costs (2L) = PoC * RAC * planned costs = 15€
Special Considerations
There are a few things you should keep in mind within the initial delivery of S/4HANA 2022 and that we would like to point out. The roadmap for revenue recognition will continue to develop and you may find that some of these topics below will be addressed based on customer feedback.
Conclusion
If you are interested in Universal Parallel Accounting and need revenue recognition functions, there is no way around Event-Based Revenue Recognition. Especially Results Analysis, the predecessor of EBRR, is not supported for Universal Parallel Accounting.
For the integration with project system, you can use the following revenue recognition methods with universal parallel accounting:
For the integration with sell from stock, you can use the following revenue recognition methods with universal parallel accounting:
For these methods, universal parallel accounting for Event-Based Revenue Recognition is supported during real-time processing and period-end closing.
The cost-based and revenue-based POC methods (method 3 & 7) have specifics that need to be kept in mind.
Further Resources
Product documentation: Parallel Accounting with Event-Based Revenue Recognition
3191636 - Universal Parallel Accounting (SAP S/4HANA 2022): Scope Information here
3220122 - Event-Based Revenue Recognition with SAP S/4HANA 2022: Release Information Note
Continuing the blog series on Universal Parallel Accounting in SAP S/4HANA in 2022, where we have already looked at options for parallel valuations. We will now address the topic from the point of view of Revenue Recognition to explain how different material prices and cost rates are considered in event-based revenue recognition. We remember that the different valuations reflect the requirements of the various accounting principles.
For revenue recognition we must consider the complete end-to-end process with sales, services and projects as all integration scenarios come with their specific requirements. For example, in the context of sales we need to potentially deal with different material prices. In a project scenario you may have also different activity cost rates.
The focus area for event-based revenue recognition was initially S/4HANA Cloud, therefore you will find here also the biggest availability with integration scenarios for sell from stock, services, product-based sales and services as well as subscriptions.
For S/4HANA on premise or private cloud edition, EBRR initially was only used for the integration with project system. Further enablement introduced the integration for sell from stock, which is subsequently enhanced. With S/4HANA 2022, event-based revenue recognition will also be enabled for maintenance-centric service processes – but that is another story.
For our blog, we want to mainly look at the sell from stock and the project scenario in S/4HANA.
Sell from Stock scenario
A common use case in the sell from stock scenario are different material prices according to different accounting principles. That maybe the result of divergent depreciation rules you have applied.
The rules how revenue is recognized by event-based revenue recognition are grouped into revenue recognition keys, that describe the data sources, revenue and cost recognition methods, as well as the posting rules for revenue/cost and accrued/deferred revenue on the balance sheet side. For the use cases of Universal Parallel Accounting this logic does not change, which also means that you will not need to do any extra configuration in EBRR for this purpose. Once UPA is activated with the corresponding business function, revenue recognition will work as described below.
In the sell from stock scenario the most common rule set is to recognize revenue when the transfer of control happens, this is usually the case when the goods issue is posted. Event-based revenue recognition allows you to accrue revenue for example based on an invoice simulation once the goods issue happens. Activating Universal Parallel Accounting allows you to use different material prices when posting into the different ledgers aligned with the underlying accounting principles. The revenue obviously cannot differ and is based on the transaction price with the customer.
As a consequence, the customer can report cost and revenues and the corresponding margin individually for each accounting principle.
Project System
For the integration with project system, typically customers use either a cost-based or revenue-based percentage-of-completion (PoC) method. We differentiate between real-time processing, e.g. when the time confirmations are posted, versus the period-end close. In the period-end close usually further re-valuations happen, generally those that are more time-consuming as they imply reading additional data (e.g. due to plan changes, or due to the netting between accrued and deferred).
In a nutshell, for a cost-based POC the progress is measured according to the actual cost versus planned cost. Different material prices or activity rates may lead to different actual cost in the relevant ledgers. Obviously, there can be only one fulfillment progress for a given project. EBRR in this case applies the PoC of the leading ledger.
For a revenue-based PoC, the PoC is calculated based on the actual revenue versus the planned revenue. This PoC is then applied to the planned cost. No issue with different cost rates you may think. Unfortunately, that is too easy as you have to keep in mind that the planned cost is only captured in the leading ledger. In order to consider different costs in other ledgers we therefore introduced a relative actual cost (RAC) ratio based on the actual cost in the respective ledger, versus actual cost in the leading ledger.
That all was a bit fast, and you are right demanding an example.
Let’s take again the example of the cost-based PoC.
Planning data can only be entered for the leading ledger 0L. In this case, revenues of 200€ and costs of 100€ have been planned. Based on the material prices or activity and expense rates in a given ledger, actual cost of 20€ is recognized in the leading ledger 0L and 30€ for the non-leading ledger 2L.
Figure 1: Event-Based Revenue Recognition for Cost-Based PoC
The percentage of completion (PoC) is evaluated in the leading ledger as actual costs/planned costs
PoC = 20€/100€ = 20%.
This percentage of completion is applied to the planned revenues (which is 200€ for all ledgers in this example), therefore,
Accrued revenue = 20%*200€ = 40€.
The calculation is applied during real-time processing and also in period-end closing.
As mentioned above, for a revenue-based PoC method the situation is slightly different.
Again, planning data for projects is entered only for the leading ledger, 0L in our case. We have the same situation as before, which is planned revenues of 200€ and planned cost of 100€ in the leading ledger 0L. For the actual cost, 20€ are posted in the leading ledger 0L and 30€ for the non-leading ledger 2L. The nature of the revenue-based PoC method is that these actual costs are deferred and recognized based on the ratio actual revenues (from the invoice) versus planned revenue.
Figure 2: Event-Based Revenue Recognition for Revenue-Based PoC
Let’s apply this to the related use case. We billed the end customer with 20€, which leads to a percentage of completion (PoC) of 10% in the leading ledger (20€/200€).
This PoC is applied to the planned cost of 100€ which leads to an accrued cost of 10%*100€ = 10€
To consider different costs in the other ledgers, a relative actual cost (RAC) rate has been introduced with:
RAC (2L) = actual costs (2L) / actual costs leading ledger (0L) = 1,5
Before first period closing, an RAC of 1 is applied. In period closing and for later calculations, costs are calculated with updated RAC as:
Recognized costs (2L) = PoC * RAC * planned costs = 15€
Special Considerations
There are a few things you should keep in mind within the initial delivery of S/4HANA 2022 and that we would like to point out. The roadmap for revenue recognition will continue to develop and you may find that some of these topics below will be addressed based on customer feedback.
- In the above examples, we looked at examples where the source system posted into all relevant ledgers, leading and non-leading. This is also the main use case, think of: goods issues, time confirmations, invoices, they should affect all valuation relevant ledgers where revenue and cost need to be reported in the same way. Given the flexibility of SAP of course you could do also ledger-specific postings. This maybe especially relevant for controlling functions such as allocations or settlements. However, for now ledger-specific postings should not be done exclusively in Financial Accounting (FI), for example using the Post General Journal Entries This applies to both revenue and cost postings; they should not be posted using General Ledgers postings only.
- When using alternative fiscal year variants as part of parallel accounting, postings to special periods are not supported in the different ledgers of a company code.
- Adjustments for imminent loss are not yet supported.
- Time and Expenses (Recognition Method 4 – DIP profile) is supported in closing, only.
- As plan source we consider data within the Financial planning table ACDOCP.
- Some further specifics apply to the integration with group ledger. In general, the posting logic of Event-Based Revenue Recognition is the same as for any other non-leading ledger. However, as soon as Advanced Intercompany Sales and Advanced Intercompany Stock Transfer and Group Valuation are used in combination, there is a specific posting logic for revenue recognition in the group valuation ledger, specifically for the integration of Event-Based Revenue Recognition with Sell from Stock and the respective revenue recognition keys SFS, SFSCCM and SFSN. In these scenarios, to make sure that the posting logic in the context of intercompany elimination postings is correct, the elimination postings created in the group valuation ledger during billing do not trigger Event-Based Revenue Recognition postings, neither in real-time processing nor during month-end close. You have to also note that it is not possible to maintain different revenue recognition rules for the group valuation ledger compared to the legal valuation ledger that is assigned to the group accounting principle since the configuration for “Document Types” and “Recognition Keys – Company Code and Accounting Principle Settings” depends on the accounting principle.
Conclusion
If you are interested in Universal Parallel Accounting and need revenue recognition functions, there is no way around Event-Based Revenue Recognition. Especially Results Analysis, the predecessor of EBRR, is not supported for Universal Parallel Accounting.
For the integration with project system, you can use the following revenue recognition methods with universal parallel accounting:
- Recognize revenue on cost-based POC (method 3)
- Recognize costs on revenue-based POC (method 7)
- Recognize revenue time-based (method 10)
- Recognize all costs and revenues (method 2)
- Completed contract: recognition at final billing/technical completion (method 9)
For the integration with sell from stock, you can use the following revenue recognition methods with universal parallel accounting:
- Recognize costs on revenue-based POC (method 7)
- Recognize revenue on delivery-related invoice simulation (method 14)
- Completed contract: recognition at final billing/technical completion (method 9)
- Recognize all costs and revenues (method 2)
For these methods, universal parallel accounting for Event-Based Revenue Recognition is supported during real-time processing and period-end closing.
The cost-based and revenue-based POC methods (method 3 & 7) have specifics that need to be kept in mind.
Further Resources
Product documentation: Parallel Accounting with Event-Based Revenue Recognition
3191636 - Universal Parallel Accounting (SAP S/4HANA 2022): Scope Information here
3220122 - Event-Based Revenue Recognition with SAP S/4HANA 2022: Release Information Note
- SAP Managed Tags:
1 Comment
