Skip to Content
Author's profile photo Former Member

Incorrect Behavior of Revenue Recognition for Fixed Price Sales Order Items?

When you have a customer project that is linked to a sales order with both fixed price and time & material items you may run into figures which look strange at first sight. Well, to be honest, also at second sight they might look strange. But there is no way to change that because of ByDesign customers using projects in a manifold of fashions.

I will explain why this is so and what the remedy is.

This is the setup

  • Consider a sales order (SO) with two items, one is a fixed price item the other is a T&M item.
  • Now create a project from that SO and let the system create one task for the fixed price item and one task for the T&M item
  • Assign accrual method “108 – Recognize using cost-to-cost project PoC” to the fixed price SO item
  • Perform a time recording with respect to the project task that points to the fixed price SO item

Here is a concrete example:


If you now run the revenue recognition for the SO in question you will end up with this situation:


The time confirmation performed created deferred cost of 100 USD. These were recognized with the revenue recognition run as internal service expenses. At the same time revenues of 150 USD were posted. Why 150 USD? When you look at the system documentation you will find that for accrual method cost-to-cost project PoC the PoC in this case is determined as follows: PoC = Total actual cost for SO item 20 / total estimated project cost. Thus, 150 USD = 100 USD / 200 USD * 300 USD (net value of SO item 20) is the documented but maybe not expected result. You probably expect 300 USD since 100% of the planned work has been performed.


Reading through the documentation you will find that the authors anticipated this expectation and recommended to go for manual accrual methods and then manually adjust the PoC.

Now for the rationale behind this. You might have noticed that I only talked about fixed price SO items and not fixed price project tasks. There is a good reason for this: There is no such thing as a fixed price task in ByDesign! The project itself – the execution related part of your customer engagement – is agnostic of how expense recordings will be dealt with in Financials. The system defines a set of default rules how expenses recorded with respect to a project task are mapped to a sales order item. Thus, it looks like task CPSO39-2 is a fixed price task. But, you are free to introduce additional rules for different types of expenses and can even manually reassign recordings in the not yet invoiced time and expenses work center view to other sales order items. Once you have more complicated project structures – and by the way: the project structure does not necessarily have to follow the sales order structure – the situation gets worse and the mapping of planned cost to SO items is sort of unforeseeable.

But since I promised you a remedy, here it is:
Use accrual method “102 – cost-to-cost PoC” instead.


Then you will get the expected result: 1 h recorded, 100 % of planned work for task CPSO39-2 gives a PoC of 100% and thus a revenue that corresponds to the net value of SO item 20.

Admittedly, this approach requires you to maintain a price component in the sale order item for the cost estimate, but the benefit is that you get what you expect.


When you use the project-related accrual method this is something that comes for free since in this case the system always accesses the currently planned cost of the project. But as explained above, there is no easy way to map the project tasks to the SO items and thus to automatically fill the cost estimate in the SO item.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Andreas Eissmann
      Andreas Eissmann

      Hi Otfried,

      sorry, but in my Point of view this is a wrong system behaviour. I see two Options:

      1. SAP says that it is not possible to use this fix price accrual method in combination with T&M positions in Sales Order

      2. SAP corrects this functionality so that not all planned costs will be taken to calculate the PoC

      Why? Because it makes absolutely no sense to take all planned costs of the whole project but only take actual costs of fix price sales order items. Why it is possible to take actual costs of sales order items but do not take planned costs the same way?

      A PoC calculated like this: "actual costs of fix price position / planned costs of whole Project" is wrong and can`t be never be right.

      In my method "102 - cost-to-cost PoC" instead is not practically because you have to edit planned costs at two Points if your projects changed.(in most cases change of planned work).

      I hope SAP will correct this behaviour otherwise this method can`t be used for most of the customers.

      Best Regards,


      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Hi Andreas,

      my main point above was:

      There is no such thing as a fixed price or T&M project task. There is no modeled information available that would easily enable us to associate planned cost to a certain sales order item. Most things here are based on convention.

      Now, you might argue that we can use the mapping information that is present as "assignment rules" in "Not Invoiced Time and Expenses". This is true for the simple case discussed in the blog. But I can easily imagine quite a few inappropriate changes to the rules that you are allowed to do but which would break the meaning of what we want to achieve. A complicated logic is also not something that we would like to offer to you since this would probably increase the maintenance load since we have to explain why the algorithm is correct and still you don't get the desired result.

      So what does it mean?

      Our documentation contains a clear statement on how the software works and what the consequences are. The conclusion you draw from this is pretty clear from your post. But I would ask everyone to come to their own conclusion.
      The accrual method in question was developed together with a customer for whom the implementation and the side effects were fine. This is not about like it or not, but we don't consider this behavior a bug.

      As you can see from the above, there is currently no concept available that would allow to calculate the PoC based on cost related to fixed price SO items only. Thus, you cannot expect an alternative approach - a new accrual method - be available soon.

      We are, however, investigating the influence of IFRS 15 requirements onto the current revenue recognition features.This is of course something we will have to adhere to. I cross-checked with the guy driving this topic: In the course of this, we would consider how to improve here.

      Best regards


      Author's profile photo Andreas Eissmann
      Andreas Eissmann

      Thank you Otfried for your answer.

      You are right with

      Our documentation contains a clear statement on how the software works and what the consequences are.

      but sometimes Software should work otherwise 🙂

      I don`t want criticise without make proposals...I think we can improve with to things:

      1. For simple calculation take the association from sales order: If a project Task (or a Sub Task of it) is linked from a fix Price sales order item than take the planned costs from this Task(s) to calculate

      -> It`s definitely better than take all planned costs from whole project

      2. Make "Estimated costs" field available to write with SAP Cloud Applications Studio to let partner realize specific, more complicated scenarios for customers



      For me the current logic isn`t correct and can`t be for mixed fix Price and time and materials Projects, so I see a Need to improve.

      Best Regards,


      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Hi Andreas,

      you might find this information interesting:

      • Please check out PDI Enhancement Option "SalesAccruralsPOCPlanValuesGet"
      • In Split Revenue Recognition Knut describes how to influence revenue recognition with PDI means in the BO FinancialAccountingViewOfSalesAndServiceDocument.

      Best regards