Understanding Revenue Recognition over Time – an explanatory example
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:
- TSFA – Service – fixed price
- TSFP – Service – fixed price without actuals
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
|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€|
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:
|Period||Contract touches these dates:||Days in period|
Calculation of revenue for January and April:
|Period||Days||Revenue for partial periods||Revenue for full periods||Total Revenue|
therefore remaining: 270 – 93 = 177€
|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.
|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€|
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):
excellent and clear.
I would like to know if it is possible to assign a straight line accruals method on a Project based process (Project with sales integration). The purpose here would be to recognize 1/n part of the revenue for a n periods project.
More globally what are the accrual methods authorized for Project (TM), project (FP), contract, .....
for projects, you can use the POC based methods (vs. planned sales order costs or planned project cost) for fixec priced ones and the @delivery / @invoice accrual methods for T&M projects. Additionally, you have the base accrual methods.
Over time is not supported yet. Just out of interest: What's the industry / business model behind your request?