Picture the following scenario in Event-Based Revenue Recognition in SAP S/4HANA Cloud: You set up a time and expense-based customer project with a project-specific price, and you define a certain invoice cap for this project. However, the value for the corresponding revenue cap listed in the Display Project WIP Details app deviates from the value that you would expect. Need help understanding why this is the case? We’ve got you covered. Read more about how you can fix this behavior during configuration.
For the integration of Event-Based Revenue Recognition (EBRR) with customer projects, you can negotiate an invoice amount cap for time and expenses billing elements with your client during project creation. The underlying logic is that your customer won’t need to pay more than this amount even if the time confirmations and expenses actually incurred exceed it. With respect to the revenue recognition process, setting this limit means the billable revenue won’t be higher. During the period-end closing, this cap amount is considered in the following way: If the sum of accrued revenue and billed revenue exceeds the cap amount, then the accrued revenue is reduced accordingly. This is then called a revenue cap.
Let’s look at some examples where you can find the revenue cap in the Event-Based Revenue Recognition apps.
The revenue cap is displayed in the Event-Based Revenue Recognition – Projects app.
Furthermore, you can also see the revenue cap in the Display Project WIP Details app. Here, the revenue cap for the project is displayed in a dedicated column (which you might need to add by choosing Settings).
As this screenshot shows, the revenue cap reduces the amount of the WIP in Company Code Currency.
To help you gain a deeper understanding of how the cap affects the calculation in Event-Based Revenue Recognition, and enable you to ensure that the calculated values are displayed correctly, let me walk you through the steps of a particular calculation example.
Let’s assume you create a customer project of the contract type Time and Expenses. You negotiate an invoice cap of EUR 1800 with your customer.
Next, you define a project-specific price. Let’s say you usually staff a consultant whose service charge is EUR 100 per hour. However, for this particular project, you set a deduction of EUR 20 per hour. This means that the project-specific price is set to EUR 80 for one hour of work done by the consultant. In the Manage Prices – Sales app, you define these pricing conditions by using the condition type PSP0 for the regular service price and condition type PCP0 for the project-specific price. To learn more about it, see Manage Prices - Sales | SAP Help Portal
Now, you conduct time confirmation on your customer project. Let’s assume that the activity with this project-specific price has been carried out for 30 hours. With the respective time confirmation posting, the event-based revenue recognition process is triggered. The process debits the accrued revenue account and credits the revenue adjustment account. Without the invoice cap, this amount would be EUR 2400: 30 hours with a project-specific price of EUR 80 per hour. However, the cap has been set to EUR 1800, which means that the ratio by which the revenue is reduced is 0.75.
This comes into play if we look at the calculation of the total accrued revenue before and after the consideration of the cap for the two pricing conditions. The following table shows you how these values are calculated.
If you now conduct the period-end closing, the differences in accrued revenue for the two pricing conditions shown in the table are posted. At this point, it is essential that both calculated differences are posted to the correct accounts to ensure that the value of the revenue cap is displayed correctly in subsequent Event-Based Revenue Recognition processes. You can achieve this through configuration.
So let’s switch to the background of the calculation and posting of the cap, your configuration environment where you (or your system administrator) define the relevant parameters. Here, use the search function to search for the configuration object Maintain Settings for Event-Based Revenue Recognition. Choose assignment rule COSPTM (Service Time and Material DIP-Based) and select Assign Sources and Posting Rules, as you can see on the following screenshot:
Here, you can see our two pricing conditions reflected as sources YR1 Revenue-Service and YD1 Revenue Deduction-Service. You might recognize that they have different usages assigned.
Herein lies the crucial reason for a potential deviation of the revenue cap value. With these particular configuration settings, the revenue cap value differs from what you expect.
Let me explain why. For the source YR1 Revenue-Service, usage 108: Identify reduction of accrued revenue by invoice cap is assigned. However, source YD1 Revenue Deduction-Service is not assigned to usage 108: Identify reduction of accrued revenue by invoice cap by default (at least prior to the SAP S/4HANA Cloud 2308 release). Now consider the following screenshot, as it shows the journal entry created for the posting of the differences between the accrued revenue before and after the cap deduction.
The difference of EUR - 750 for the service time is posted with the subledger-specific line item type (SLA Line Item Type) 8102 (Reduction of accrued revenue by invoice cap) because of the connection to the usage 108 that identifies this value as a reduction of the accrued revenue. The value is now considered in Event-Based Revenue Recognition, for example, in the Display Project WIP Details app.
However, the difference for YD1, EUR 150, does not have the usage 108 assigned. In the journal entry, you can see that it is posted with a different SLA Line Item Type 8100 (Revenue in Excess of Billings, Accrued Revenue, Contract Asset). Due to the missing assignment to usage 108, this value is not considered in subsequent EBRR processing. It can therefore be regarded as the reason for deviating values, for example, in the Display Project WIP Details report.
If we applied this to our example, the deduction of the accrued revenue (and thus the revenue cap) in Event-Based Revenue Recognition would now be EUR 750 instead of the actual deduction of EUR 600.
There are two possible ways to go about changing this.
First, let’s consider the case that you haven’t maintained any accounts for the source YR1.
During the configuration for the assignment of sources, you can simply use the following line with a blank source for usage 108, as you can see in the following screenshot:
Adding this setting will ensure that both sources, the revenue time and the deduction condition, are connected to usage 108. Hence, the following screenshot of the journal entry shows that SLA Line Item Type 8102 is used.
Since you have not maintained accounts for the source YR1 and YD1 before, the postings do not affect different accounts, which means in our example, a total reduction of the invoice cap of EUR 600 was calculated. The revenue cap in the Display Project WIP Details app is now also propagated correctly.
If this blog post sparked your interest and you want to know more about Event-Based Revenue Recognition in general, check out what we have provided for you on the SAP Help Portal:
Event-Based Revenue Recognition | SAP Help Portal
But first, a quick introduction: What’s the cap all about?
For the integration of Event-Based Revenue Recognition (EBRR) with customer projects, you can negotiate an invoice amount cap for time and expenses billing elements with your client during project creation. The underlying logic is that your customer won’t need to pay more than this amount even if the time confirmations and expenses actually incurred exceed it. With respect to the revenue recognition process, setting this limit means the billable revenue won’t be higher. During the period-end closing, this cap amount is considered in the following way: If the sum of accrued revenue and billed revenue exceeds the cap amount, then the accrued revenue is reduced accordingly. This is then called a revenue cap.
Let’s look at some examples where you can find the revenue cap in the Event-Based Revenue Recognition apps.
The revenue cap is displayed in the Event-Based Revenue Recognition – Projects app.
Furthermore, you can also see the revenue cap in the Display Project WIP Details app. Here, the revenue cap for the project is displayed in a dedicated column (which you might need to add by choosing Settings).
As this screenshot shows, the revenue cap reduces the amount of the WIP in Company Code Currency.
Let’s dive right into an example scenario for the cap
To help you gain a deeper understanding of how the cap affects the calculation in Event-Based Revenue Recognition, and enable you to ensure that the calculated values are displayed correctly, let me walk you through the steps of a particular calculation example.
1. Project creation with a project-specific price
Let’s assume you create a customer project of the contract type Time and Expenses. You negotiate an invoice cap of EUR 1800 with your customer.
Next, you define a project-specific price. Let’s say you usually staff a consultant whose service charge is EUR 100 per hour. However, for this particular project, you set a deduction of EUR 20 per hour. This means that the project-specific price is set to EUR 80 for one hour of work done by the consultant. In the Manage Prices – Sales app, you define these pricing conditions by using the condition type PSP0 for the regular service price and condition type PCP0 for the project-specific price. To learn more about it, see Manage Prices - Sales | SAP Help Portal
2. Time confirmation for the project
Now, you conduct time confirmation on your customer project. Let’s assume that the activity with this project-specific price has been carried out for 30 hours. With the respective time confirmation posting, the event-based revenue recognition process is triggered. The process debits the accrued revenue account and credits the revenue adjustment account. Without the invoice cap, this amount would be EUR 2400: 30 hours with a project-specific price of EUR 80 per hour. However, the cap has been set to EUR 1800, which means that the ratio by which the revenue is reduced is 0.75.
This comes into play if we look at the calculation of the total accrued revenue before and after the consideration of the cap for the two pricing conditions. The following table shows you how these values are calculated.
| Revenue Service Pricing Condition for Source YR1 | Revenue Service Deduction Pricing Condition for Source YD1 | |
| Total accrued revenue before cap deduction | EUR 100 per hour x 30 hours = EUR 3000 | EUR - 20 per hour x 30 hours = EUR - 600 |
| Total accrued revenue after cap deduction | EUR 100 per hour x 30 hours x a ratio of 0.75 = EUR 2250 | EUR - 20 x 30 hours x a ratio of 0.75 = EUR - 450 |
| Difference to be posted during period-end closing | EUR 2250 - EUR 3000 = EUR - 750 | EUR - 450 + EUR 600 = EUR 150 |
3. Period-end closing
If you now conduct the period-end closing, the differences in accrued revenue for the two pricing conditions shown in the table are posted. At this point, it is essential that both calculated differences are posted to the correct accounts to ensure that the value of the revenue cap is displayed correctly in subsequent Event-Based Revenue Recognition processes. You can achieve this through configuration.
How configuration in Event-Based Revenue Recognition affects the cap
So let’s switch to the background of the calculation and posting of the cap, your configuration environment where you (or your system administrator) define the relevant parameters. Here, use the search function to search for the configuration object Maintain Settings for Event-Based Revenue Recognition. Choose assignment rule COSPTM (Service Time and Material DIP-Based) and select Assign Sources and Posting Rules, as you can see on the following screenshot:
Here, you can see our two pricing conditions reflected as sources YR1 Revenue-Service and YD1 Revenue Deduction-Service. You might recognize that they have different usages assigned.
Herein lies the crucial reason for a potential deviation of the revenue cap value. With these particular configuration settings, the revenue cap value differs from what you expect.
Let me explain why. For the source YR1 Revenue-Service, usage 108: Identify reduction of accrued revenue by invoice cap is assigned. However, source YD1 Revenue Deduction-Service is not assigned to usage 108: Identify reduction of accrued revenue by invoice cap by default (at least prior to the SAP S/4HANA Cloud 2308 release). Now consider the following screenshot, as it shows the journal entry created for the posting of the differences between the accrued revenue before and after the cap deduction.
The difference of EUR - 750 for the service time is posted with the subledger-specific line item type (SLA Line Item Type) 8102 (Reduction of accrued revenue by invoice cap) because of the connection to the usage 108 that identifies this value as a reduction of the accrued revenue. The value is now considered in Event-Based Revenue Recognition, for example, in the Display Project WIP Details app.
However, the difference for YD1, EUR 150, does not have the usage 108 assigned. In the journal entry, you can see that it is posted with a different SLA Line Item Type 8100 (Revenue in Excess of Billings, Accrued Revenue, Contract Asset). Due to the missing assignment to usage 108, this value is not considered in subsequent EBRR processing. It can therefore be regarded as the reason for deviating values, for example, in the Display Project WIP Details report.
If we applied this to our example, the deduction of the accrued revenue (and thus the revenue cap) in Event-Based Revenue Recognition would now be EUR 750 instead of the actual deduction of EUR 600.
Troubleshooting: How to change this?
There are two possible ways to go about changing this.
First, let’s consider the case that you haven’t maintained any accounts for the source YR1.
During the configuration for the assignment of sources, you can simply use the following line with a blank source for usage 108, as you can see in the following screenshot:
Adding this setting will ensure that both sources, the revenue time and the deduction condition, are connected to usage 108. Hence, the following screenshot of the journal entry shows that SLA Line Item Type 8102 is used.
Since you have not maintained accounts for the source YR1 and YD1 before, the postings do not affect different accounts, which means in our example, a total reduction of the invoice cap of EUR 600 was calculated. The revenue cap in the Display Project WIP Details app is now also propagated correctly.
Feel like you want to know even more about Event-Based Revenue Recognition now?
If this blog post sparked your interest and you want to know more about Event-Based Revenue Recognition in general, check out what we have provided for you on the SAP Help Portal:
Event-Based Revenue Recognition | SAP Help Portal
- SAP Managed Tags:
