Customers using customer contracts might use services on a fixed-price base. In revenue recognition, those are realized over time. But the accrual methods provided there are not easy to understand. Therefore, I'd like to provide an explanatory example.
This applies on these sales document item types which are available in the customer contract:
A customer contract has three items of type "fixed-price without actuals", to cover all available over-time accrual methods. The contract runs over three months, each month is invoiced at 90€.
In work center "Cost and Revenue", view "Sales Documents", you will find these specific accrual methods for this contract:
Those have been assigned as shown above to the contract items. In the next paragraphs, let's discuss what these accrual methods should calculate.
To understand what the system will recognize each period, you have to be aware how the system determines the number of affected periods. The contract runs over three months, but touches four (January, February, Mars, April) periods.
Therefore: 270€ divided by four months is a revenue of 67,50€ each month.
This accrual method is a balance between day-level accuracy and "even periods". It will realize revenue at day level for the periods that aren't will all days within the contract's duration (in this example: January and April), and will realize revenue evenly for periods that are with all their days in.
But, there is a pitfall: One might expect that it determines three full periods (=three full months of contract duration), divides by this quantity and uses one period to realize January and April proportionate. This isn't the case.
Calculation of days that are in contract's validity for each period:
Calculation of revenue for January and April:
This accrual methods calculates the number of days and weights them evenly to distribute revenue. Therefore, periods have different revenue amounts.
OK, having discussed these things in theory, let's proof this with some screenshots. Click on the screenshots to enlarge them.
Accrual methods and pre-calculated revenue:
Result of a revenue recognition run (items are not yet invoiced):
This applies on these sales document item types which are available in the customer contract:
- TSFA - Service - fixed price
- TSFP - Service - fixed price without actuals
Example
Customer contract
A customer contract has three items of type "fixed-price without actuals", to cover all available over-time accrual methods. The contract runs over three months, each month is invoiced at 90€.
| Item | Description and accrual method assigned | Start / end | Quantity [Periods] | Price | Value |
| 10 | Straight Line - Even Periods | 22.01.2018 - 21.04.2018 | 3 | 90,00€ | 270,00€ |
| 20 | Straight Line - Prorate Partial Periods | 22.01.2018 - 21.04.2018 | 3 | 90,00€ | 270,00€ |
| 30 | Straight Line - Exact Days | 22.01.2018 - 21.04.2018 | 3 | 90,00€ | 270,00€ |
Revenue recognition
In work center "Cost and Revenue", view "Sales Documents", you will find these specific accrual methods for this contract:
- 303 - Straight Line - Even Periods
- 304 - Straight Line - Prorate Partial Periods
- 302 - Prorate Partial Periods
Those have been assigned as shown above to the contract items. In the next paragraphs, let's discuss what these accrual methods should calculate.
Straight Line - Even Periods
To understand what the system will recognize each period, you have to be aware how the system determines the number of affected periods. The contract runs over three months, but touches four (January, February, Mars, April) periods.
Therefore: 270€ divided by four months is a revenue of 67,50€ each month.
Straight Line - Prorate Partial Periods
This accrual method is a balance between day-level accuracy and "even periods". It will realize revenue at day level for the periods that aren't will all days within the contract's duration (in this example: January and April), and will realize revenue evenly for periods that are with all their days in.
But, there is a pitfall: One might expect that it determines three full periods (=three full months of contract duration), divides by this quantity and uses one period to realize January and April proportionate. This isn't the case.
Calculation of days that are in contract's validity for each period:
| Total | 90 | ||
| Period | Contract touches these dates: | Days in period | |
| January | 22.01.2018 | 31.01.2018 | 10 |
| February | 01.02.2018 | 28.02.2018 | 28 |
| March | 01.03.2018 | 31.03.2018 | 31 |
| April | 01.04.2018 | 21.04.2018 | 21 |
Calculation of revenue for January and April:
| Period | Days | Revenue for partial periods | Revenue for full periods | Total Revenue |
Total | 93€ therefore remaining: 270 - 93 = 177€ | 177,00€ | 270,00€ | |
| January | 10 | 270€ / 90 days * 10 days in period = 30€ | 30,00€ | |
| February | 177€ / 2 months = 88,50€ | 88,50€ | ||
| March | 177€ / 2 months = 88,50€ | 88,50€ | ||
| April | 21 | 270€ / 90 days * 10 days in period = 63€ | 63,00€ | |
Straight Line - Exact Days
This accrual methods calculates the number of days and weights them evenly to distribute revenue. Therefore, periods have different revenue amounts.
| Total | 90 | 270€ | ||
| Period | Contract touches these dates: | Days in period | Revenue | |
| January | 22.01.2018 | 31.01.2018 | 10 | 270€/90 days * 10 days = 30€ |
| February | 01.02.2018 | 28.02.2018 | 28 | 270€/90 days * 28 days = 84€ |
| March | 01.03.2018 | 31.03.2018 | 31 | 270€/90 days * 31 days = 93€ |
| April | 01.04.2018 | 21.04.2018 | 21 | 270€/90 days * 21 days = 63€ |
Screenshots
OK, having discussed these things in theory, let's proof this with some screenshots. Click on the screenshots to enlarge them.
Accrual methods and pre-calculated revenue:
| Even periods |  |
| Prorate partial periods |  |
| Exact days |  |
Result of a revenue recognition run (items are not yet invoiced):
- SAP Managed Tags:
3 Comments
