In this blog I would like to show you how SAP S/4HANA cloud covers the reporting requirements specific to the professional service industry. We will see how the profit center (PC) and employee profitability reporting requirements are covered and how non-billable items are posted and reported.
Profit center reporting for customer projects
Many professional service companies are subdivided into many smaller entities who are in charge of revenue and margin. The lead for such an entity is very often a partner. In SAP S/4HANA this entity is reflected by the profit center.
For a customer project you can assign a responsible profit center at the billing item level.
Figure 1: Maintenance of responsible Profit center on customer project billing item
The PC is defaulted on the project header, but can be overwritten at the project billing item level as long as there is no posting on the assigned work breakdown structure (WBS) hierarchy. As explained in blog 1 Real-time insights in project-based service scenario the billing element is the level for revenue recognition and (market segment) reporting.
This allows reporting for several PCs on one customer project – see figure 2
Figure 2: Drilldown customer project margin by responsible profit center
Remark: All project KPIs are available at PC level - not only margin, but accrued (WIP) and deferred revenue too.
Margin reporting per contributing profit center
In the professional service industry it is very common to have many contributors from other profit centers confirming time and expenses for a customer project. Their profit center responsible – often the partner – wants to participate in the customer project margin. Creating a separate billing item for each contributing profit center is not an option.
To support the requirement to see the project margin not just for the responsible project profit center but also for the contributing profit centers, we introduced a new attribute in the Universal Journal: the origin profit center.
The employee ID enables us to read the employee master data and get the assigned cost center. From the cost center we get the employee’s profit center. This profit center we store in the new Universal Journal attribute, the origin profit center.
Figure 3: Method to derive the origin profit center.
When a consultant confirms time to the project, we get the following postings on the customer project.
Figure 4: Origin profit center in app “Display line items in General Ledger”
The first line is the time confirmation debit on the customer project. The next 2 lines are the revenue recognition lines – the event based revenue realization. In every line item there is an employee ID available. This allows us to get the origin profit center from the employee’s cost center.
The derivation of the origin profit center is provided for CPM projects (customer and internal projects) and cost centers. It is based on the employment ID (Employee ID). The employee must be assigned to a cost center. The cost center needs to be assigned to a profit center.
If the employee information is not available, the origin profit center is derived through the project´s profit center. This is the case for example for billing and Revenue Recognition postings on fixed price projects and in general for goods issues.
As the origin PC is derived for all postings on the customer project, a complete margin reporting is available – not only on the responsible profit center, but on the contributing/origin profit center too – see figure 5.
Figure 5: Project Profitability by Origin profit center
There are confirmations from Consultant3_DE, assigned to Origin PC YB101, and Consultant3_US, assigned to Origin PC YB140. Their “Home profit centers”, derived from their cost center, are assigned to the origin PC.
When no employee is assigned to the posting – second line – the origin PC is derived from the responsible profit center of the billing item.
Derivation of the origin PC is easy in case of Time and Material billing. Here we simulate billing with every single time confirmation, and we get and post realized revenue for every confirmation. This allows us to store the employee in the line item for revenue recognition postings – see figure 4.
For fixed price we applied a new approach.
Calculating revenue for contributing Profit center in fixed price scenario – target revenue
For fixed price contract items, we calculate realized revenue by applying the percentage of completion (POC) to the total plan values for cost/ revenue.
E.g. fixed price project with
Planned cost of 100€
Planned revenue of 200€
Actual cost postings of 10€ --> recognized revenue will be 20€
When calculating recognized revenues on this totals level, there is no reference to a single employee. Therefore, we cannot derive a contributing PC for these revenue recognition line items and we derive the origin PC by the responsible PC. The billing of a fixed price project does not provide any employee related information.too.
To get revenue lines for the contributing PC we introduced a new functionality for fixed price scenario – the target revenue calculation. For every confirmation with an assigned employee we simulate T&M billing and calculate the revenue, which the employee would generate if it would be a T&M contract.
Additional to the legal revenue recognition postings we create – at the same time and within the same document - 2 additional lines posted with a new dedicated Target Revenue G/L account
These 2 lines are only for cost management purpose and have no legal relevance. The balance for the target revenue is always zero within one accounting document.
Here a posting example: a consultant confirms 1 hour to a fixed price project
Figure 6: Origin PC revenue provided by target revenue in app “Display line items in General Ledger”
In the first line you see the time confirmation on project with the origin PC from the employee YB101.
The second and third line are the legal, POC based revenue recognition line items. We realize a revenue of EUR 83.33 assigned to the origin PC YB337, which is derived from responsible PC on billing item.
Line 4 and 5 are the target revenue line items. You can see that the balance is zero. We get the revenue of EUR 100 out of T&M billing simulation. This is the revenue the consultant would realize in case of T&M billing. So, we assign the EUR 100 revenue to his origin PC YB101. The debit, offset, line we assign to the Profit center of the billing item.
The concept is that the responsible profit center from the project takes always the delta between the realized revenue calculated fixed price and T&M. In this case this means a loss of EUR 16,67 for the responsible profit center YB337.
Figure 7 shows, how this example looks like in profitability reporting
Figure 7: Target revenue in profitability reporting
For the contributing PC YB101 there is margin of EUR 35. The responsible PC realizes a loss of EUR 16,67.
Remark: in case you define project dependent time and material price conditions, we will take them in account. This allows you to maintain target revenue with respect to the expected margin for the fixed price project.
As not all customers need this functionality, it is enabled by a new revenue recognition key SPFCTR: Fix Price Cost based POC Target Rev, which the customer needs to assign in the revenue recognition key derivation table for his fixed price item categories – self configuration UI is available.
Target revenue is calculated and posted in event-based processing only. If the posting fails, there will be error messages the same as for the normal revenue recognition process. There will be information in the revenue recognition log and you can - after resolving the issue – repost and generate the target revenue posting. Error messages from event-based processing have to be resolved and cannot be deleted, otherwise target revenue postings would be missing.
The released profit center hierarchies work for the origin PC too. As we provide the origin PC for customer projects, internal projects and cost centers, a company view based on origin PC will be available.
Figure 8: Hierarchy reporting for origin Profit center
The origin profit center is provided in SAP S/4HANA cloud only.
Employee Profitability reporting
Information about employee profitability is very important for the professional service industry. The margin by employee is calculated with the employee’s realized revenue minus the employee’s confirmation costs (quantity multiplied with employee specific cost rate – see blog 2)
In case of Time & Material contracts, we now apply employee information in all line items, posted to the customer project and in relation to an employee. In blog 2 we explained that the time sheet transfer is at single confirmation level and contains the information of employee. We provide the employee ID in the travel expense interfaces. For billing transfer to accounting we keep the employee ID in the aggregation and provide it in the billed revenue items.
In case of fixed price, we get the employee revenues based on the target revenue – see figure 6.
So an employee profitability based on all customer projects – cross company - can be provided:
Figure 9: Project Profitability based on Employees
Non-billable items – new field “billable control”
There is now a functionality - for time and material contract types only - to provide the information that the item is not billable already at the project planning and staffing stage.
Figure 10: Planning resources as non-billable
This is defaulted to the time sheet entry
Figure 11: Confirmation of a non-billable item
When transferring to Accounting no realized revenue is calculated – in the case of a time and material contract item. There are only costs. We simulate time and material billing and we get zero revenue back. In time and material billing there will be no billing proposal for this item.
This leads to the following reporting:
Figure 12: Billable control in project profitability reporting
For the Consultant3_DE there is no revenue calculated for the EUR 260 costs with the billable control S1.
The billable control S1 has the meaning non-billable.
Project Profitability Overview APP
To give the Accountant an overview for the most important KPIs and market segments we provide the project overview APP.
Figure 13: app project profitability overview
The most important KPIs are the margins of course, but the WIP too. Here we distinguish between accrued revenue – confirmed but not yet billed – and deferred- paid by customer but not yet service delivery. If Accrued revenue (WIP) is too high, the project manager will be informed about the billing backlog.
As the market segment we provide customer and customer group, product sold and product sold group, and of course the very important profit center. Here you can select the responsible profit center and the origin profit center.