Co-Authored by Gabi Hoffmann and Stefan Walz
Welcome to this blog, in which we will present the project accounting and controlling innovations for the customer project solution in S/4HANA cloud, which includes logistic business processes such as sales from stock, free of charge items, returns and simple engineer to order.
In this business scenario a project is assigned to sales order items to capture the costs and revenues of the logistical processes of a sales order. So, the outbound deliveries post expenses on the project. Customer invoices, credit and debit notes post revenues on the project. You can also – following rules – assign several sales order items to one wbs billing element.
In addition, costs can also be booked on this project with other transactions such as time sheet, activity allocation, supplier invoice, goods receipt to supplier invoice, post general journal entry or goods issue from stock. Overhead surcharges can also be posted on the project.
There is a simple manual project planning available, what allows project controlling by a plan/actual comparison and revenue recognition based on Percentage of Completion (PoC) methods.
To ensure the simplified business process including event-based revenue recognition and market segment margin out of the box, we provide this functionality along with assignment rules and for dedicated sales order item categories only. We enhance the list of sales order item categories and the supported scenarios release by release.
Please note that SAP S/4HANA Cloud provides additional a tailored end-to-end solution for professional services, which has consultancy, audit and tax companies in scope. This solution is described in the following blog.
We will start in this blog with first insights on new financial capabilities as appetizer. Then we show, how we benefit in this scenario from the financial innovations in S/4, before we come to the architecture and scenario setup.
Then we will show you an end-to end process in the system – including the scenario where we sell a manufactured product and post costs of goods sold split on the project. We close with deeper insights in the event -based revenue recognition.
Let us start with some impressions about the – reporting – capabilities of financial accounting for customer projects in S/4HANA cloud.
This report provides the information to analyze the project profitability:
Figure 1 project profitability overview
The special features of this report are based on the underlying database and business processes:
The next report shows how every project direct impact your customer and product margins:
Figure 2 product and service margins for customer projects
In the columns we use as KPIs the semantic tags – a grouping of G/L accounts.
You get for every project a single margin, but also per customer and product sold! The same market segment information is available for the accrued revenue/ WIP in the very right column.
Now let’s have a look, how your analysis capabilities in the trial balance increase. We start trial balance app, include as dimension the product sold, the customer and the project and then filter on our project.
Figure 3 trial balance drill down by project
There is no longer just one posted amount on the G/l accounts. You can trace for all G/L accounts posted with reference to our project the following attributes: our project and market segments like product and costumer derived from the assigned sales order item
Thus, you can drill down your WIP by e.g. product sold and customer; similar for the expense, revenue and CO postings.
The business processes belonging to the shown numbers we will look at in chapter 4.
The same as in the Professional services scenario – see blog link above – and the new service scenario New Financial Accounting for Service Management in S/4HANA Cloud | SAP Blogs we benefit in this scenario from HANA and the innovations in financial accounting – the Universal Journal, the profitability attribution for revenue carrying objects and the event-based revenue recognition.
With the Universal Journal the accounting applications General ledger, Controlling, event-based revenue recognition and Profitability are now integrated. Thus,
To allow a plan/actual comparison on the same structure and entities we store plan costs and revenues in ACDOCP, the corresponding database to the Universal Journal/ACDOCA, which contains the actuals.
With the planning on Customer project we derive the same market segment information as for the actuals. So, even if you plan just on customer project the assigned sales order item and its market segment attributes are derived and stored in every ACDOCP line item – see example in chapter 4.
An example for the controlling value flow for customer projects including the cost centers and their under/ over absorption you get in figure 4.
Figure 4 controlling value flow for project based sales process
This value flow principle we follow in S/4HANA cloud for revenue carrying objects.
The postings on the project are equal to the example in chapter 4. The time sheet on project and the overhead costs credit the cost centers and debit the customer project. These costs and the realized revenue calculated and posted by event-based revenue recognition provide a margin for the customer project and for product and customer.
The cost center is debited with periodic costs like asset depreciation, travel expenses or salary expenses. At period-end there will be a difference on the cost center between these debits and the credits posted to customer projects. These differences can be allocated to profitability segment. Assumption in our example here is, that they can be assigned on product and customer level. The level of assignment depends of course on the customer business. Technically it would be possible to even assign these costs on customer project or sales order item.
So, the profitability for product and customer is the aggregation of the customer project costs and revenues and the allocation to profitability segment. In our example the margin for the product “SM0001” is 14,28€.
Our architecture for sales order and project setup is driven by the target to allow for every posting on the project – independent if manual or by the sales document flow – an automated margin reporting on the market segment attributes.
To define a unique profitability segment and to allow the determination of a revenue recognition key we must be able to identify a leading sales order item.
in the current approach, in release CE 2011 we define the first assigned pricing and billing relevant sales order item as the leading one, and therefore, there can be only one assigned to the billing element.
The non-billing relevant free of charge items post only costs on the project element, which is assigned to the sales order items. There can be multiple free of charge items assigned to the same billing project element.
This setup is visualized in the figure below.
Figure 5 – financial setup for project based sales scenario
For the billing project element and the related sub-tree there is a unique profit center defined.
The unique pricing and billing relevant sales order item – here item 10 – derives the revenue recognition key. The key is stored in the billing project element – see chapter 6.
Additionally, this leading sales order item defines the unique profitability segment which is derived for every posting on the billing work package and the work packages below.
How this derivation by posting on project works, shows the next figure.
Figure 6 – market segment derivation logic for project based sales
For every posting on a wbs element we check if there is a leading sales order to the wbs billing element assigned (if the posting is done on a workpackage, which is no billing element, we read the superordinate wbs billing element). If we get in the wbs billing element a leading sales order item, we read this sales order item and derive a profitability segment on the fly: with the product sold defined by this sales order item, customer, sales organization and division from the sales order header. And we derive attributes, which are defined in the company profitability segment: so, we define the product and customer group. If profitability extensibility is in place, these fields will be derived too! We do not store the profitability segment on the sales order or wbs element. It is available in the journal entries only.
With the Universal Journal it is now possible to use in one Journal entry line item several cost objects in parallel. This was not possible in ERP. We still have exact only one real account assignment for every line item. This is identified with the field “Object type” (technically ACCASTY). In our example it is “PR”, what indicates a wbs element assignment. Only on the real account assignment are follow-up processes possible like revenue recognition. The other account assignments are attributed and only for reporting purposes. We use this here with having the sales order item and the profitability segment attributed.
Thus, not only a project margin can be provided by the postings on the project, but also a profitability reporting on the market segments is available. With the use of Universal Journal integrated Profitability we derive for every posting on a wbs element a profitability segment – based on the attributes in leading sales order item – and enrich the journal entry -like we do it in the customer project scenario – see blog mentioned above.
There are scenario variants in place
There are rules in place for changing the assignment of a sales order item to the wbs billing element
Now let’s take a look at the various financial accounting capabilities by a simple end-to-end project based sales process.
In our example we will create a sales order with a service item and a free of charge item. Both we assign to the same wbs billing element.
First, we start with the Project creation and the app “project control”.
Figure 7 creation of the project
We select the profile “project with revenue”. The functional area is “YB18 cost of goods sold”. We want to apply overhead surcharges; thus we assign the costing sheet “1010PI”. We set Project status to released.
Next step is the sales order creation
Figure 8 sales order creation
First item with product SM001 is billing relevant with a planned billing amount of 1200€, which is defined in a milestone billing plan. This is the main item – relevant for determination of revenue recognition and profitability segment.
The second item with product TG12 is a free of charge item.
Both items are assigned to the billing element SW-Mario09, what you can check in the very right column.
Now we plan the project to allow a plan- actual comparison and to allow a percentage of completion (PoC). Please note: there is the option with the file upload and also SAC Integration available.
We first enter the data in an Excel-file:
Figure 9 – Excel file for project planning
We use plan category PLN. This category is used in revenue recognition for POC calculation.
We enter just 2 lines. The first line is the expense planning based on the expense account 51600000. The second line reflects the planned revenue by the revenue G/L account 41000000.
Please note: line 3 with the X entries is very important. The X defines per column which data are replaced in ACDOCA. More information you can get here: SAP Help Portal
Then we start the app “Import Financial plan data”
Figure 10 – app for project planning
When you upload the file, you get notified, if you would reverse with the upload already existing plan data.
After successful upload Let’ have a look on the project plan data. We start the app “project plan actual”
Figure 11 – analysis of the plan data on project
You see here the both line items we entered in the file.
But please recognize, for our plan data there is the information about customer and product sold additional derived! The same as for the actual postings we use the assignment of the wbs billing element to the leading sales order to derive additional market segment attributes.
So, if you plan a project after assignment of the project to a leading sales order item you get the plan data on sales order item level too!
Now let’s come to the first actual posting with the outbound delivery for the free of charge item.
Figure 12 – outbound delivery
With pressing the bottom “post goods issue” we get the following journal entries:
Figure 13 – created journal entries of outbound delivery
The second document is the prima nota, which reflects the goods issue. And then you the see the impact of parallel accounting: Journal Entry 1, 3, and 4 are the revenue recognition postings per active ledger in company code 1010.
Let’s analyze the Journal entries for the leading ledger 0L
Figure 14 – journal entries of outbound delivery in leading ledger
The first two line items reflect the goods issue: the credit of the inventory and the debit of the project in line item 2.
The second journal entry is the revenue recognition posting. The realized revenue – calculated by the POC – and the balance sheet activation with WIP G/L account.
All line items are referenced to the logistic goods issue posting (see column 4).
The POC is calculated by actuals costs divided by planned costs = 40€/1000€= 4%. The POC is multiplied with the planned revenue: 4%*1200€= 48€ realized revenue.
The expense posting of the goods issue and the revenue recognition postings are account assigned to the project (see object type = PR in column 7). As there is a leading sales order item 15245/10 in the billing element defined, we derive the sales order item and subsequent profitability attributes from the sales order item like product sold SM0001, the customer 10100001 or the sales organization 1010.
Now let’s come to the next business transaction: a time confirmation on the project.
We start the app “My time sheet”.
First you need to create here a task for the project. You can assign in the task the billing element or a subordinate wbs element.
Figure 15 – time confirmation on the customer project
We mark the task of our project and select 1 h on Friday, the 6th and save.
The subsequent posted journal entries you see here:
Figure 16 – journal entries of time confirmation on the customer project
The first two line items reflect the CO activity allocation: the credit of the employees’ cost center and the debit of the project in line item 2, in which you get the used activity type – see column Part.CC.Activity – with the confirmed 1 hour.
The second journal entry is the revenue recognition posting. The realized revenue – calculated by the POC – and the balance sheet activation with WIP G/L account.
All line items are referenced to the time sheet entry – see in column 3 the reference doc type =CATS and the CATS document 85 in column 4.
The POC is calculated by actuals costs divided by planned costs = 75€/1000€= 7,5%. The POC is multiplied with the planned revenue: 7,5%*1200€= 90€ realized revenue.
The activity allocation debit and the revenue recognition postings are account assigned to the project (see object type = PR in column 7). As there is a leading sales order item 15245/10 in the billing element defined, we derive the sales order item and subsequent profitability attributes from the sales order item like product sold SM0001 and the customer 10100001.
We start now a periodic overhead calculation for our project with the app “Run overhead calculation – projects actual”.
Figure 17 – selection screen for overhead calculation
We select our Project SW-Mario09 and the period – here 11/2020.
Figure 18 – log for overhead calculation
In the log you see the calculation condition scheme. 10% material overheads calculated on the material expenses and on the sum of both there is an additional administration overhead percentage of additional 10% applied.
Please note: the displayed currency is here the global currency USD. The percentage is calculated for every currency in parallel.
Let’s have a look on the posted journal entry in the leading ledger 0L.
Figure 19 – JE for overhead calculation
The first two journal entries with two items each reflect the CO overhead calculation posting for material overhead and administration overhead: the debit of the project and the credit of the cost center in the second line item.
The 2 journal entries below are the revenue recognition postings- one Journal Entry per overhead rate. The realized revenue – calculated by the POC – and the balance sheet activation with WIP G/L account.
All line items are referenced to the overhead document – see column 4.
The overheads debit and the revenue recognition postings are account assigned to the project (see object type = PR in column 7). As in the examples before the profitability attributes are derived by the leading sales order item 15245/10 and stored in the journal entry line items.
Now let’s have a look on the revenue recognition values with the app Event based revenue recognition projects 2.
Figure 20 – revenue recognition values on the project after cost postings before billing
In the upper section you see the income statement relevant postings. The actuals posted on the project sum up to 123,40€. The matching recognized revenue is 148,08€. This leads to a calculated margin of 24,68€.
In the second section you see the balance sheet values. Here we have the WIP or Accrued revenue of 148, 08€ – the offset to the recognized revenues.
The bottom section shows the – for revenue recognition recognized – plan data: planned revenue of 1.200€ and planned costs of 1000€.
Now we come to the billing.
With the app Create Billing document we get the due billing plan item for our service item.
Figure 21 – billing due list
We select the line item with our order 15245 and hit the button Create Billing documents and come to the screen below.
Figure 22 – billing document
In the billing document we have one item for our product SM0001 and 120€, which is the Amount out of the billing plan.
We select the button “Post Billing document” and get the Journal entries below for leading ledger 0L.
Figure 23 – journal entries of billing document
The first three line items reflect the billing document: the receivables line item, the credit of the project with the billed revenue and the tax line item.
The 2 journal entry line items below are the revenue recognition line items. The revenue adjustment and the balance sheet line item on deferred revenues.
Note: We need to defer the billed revenues as we have already realized revenue with the cost postings. (these postings are explained by T-accounts in section 7)
All line items are referenced to the billing document – see column 4.
The billed revenue line and the revenue recognition postings are account assigned to the wbs billing element. As in the examples before the profitability attributes are derived by the leading sales order item 15245/10 and stored in the journal entry line items.
To net the revenue recognition balance sheet Amounts deferred and accrued revenues, we start again the revenue recognition monitor above and reevaluate (this is normally done automatically by period-end-closing run). This results in the posting below.
Figure 24 – journal entries of revenue recognition balance sheet netting
Both line items are posted on balance sheet G/L accounts. The deferred revenue of 120€ – resulting from billing – is netted with the accrued revenue.
Please note: the revenue recognition line items are account assigned to the project (Column 8 object type = PR) and all profitability attributes are derived.
More to the posting logic we describe in chapter 6
Now we start again the revenue recognition app to analyze the revenue recognition of our project:
Figure 25 – revenue recognition values on the project after cost postings, billing and rev rec netting
In the upper section you see the actual costs of 123,40€ and the recognized revenue of 148,08€; while the billed revenue is 120€. The difference you see in the accrued revenue/WIP in the second section.
All these postings lead now to the following margin reporting on the project
Figure 26 – margin reporting for project
The line items reflect the single postings in this chapter. You see the recognized margin of 24,68€ in the respective column is valid for the project, but impacts also the margin the sales order, the product sold, customer and sales org.
On the very right column you see the balance of 28.08€ on the WIP account. This is the effect that we realized more revenue than yet is billed.
The enhanced reporting capabilities you can realize in the trial balance too. If you start the trial balance for company code 1010 and then add the dimension Project definition and filter on our project SW-Mario09, you will get the report in figure 3.
Now we show you a new scenario. In this scenario we sell a manufactured product leading to cost component split postings on project, what allows now a multilevel cross margin reporting on the project.
First let’s have a look on the product. Based on its quantity structure, BOM and routing, a cost estimate is performed – see below.
Figure 27 cost estimation for product by cost components
To show the usage of material and working hours on a multi-level basis there is a cost component split available.
100 pieces of product FG126 cost 1.807€, thereof material expenses of 1.648€
Then we create a sales order and assign the wbs billing element “SW-Mario07”
Figure 28 sales order item of a manufactured product assigned to project
We plan the project to allow POC calculation by the event-based revenue recognition
Figure 29 planning file for project
We upload this with the planning app as in chapter 4
Then we post the outbound delivery
Figure 30 outbound delivery for sales order
We subsequent post a goods issue of this one piece.
This leads to the following journal entry
Figure 31 journal entry for outbound delivery including cogs split and revenue recognition
You see here, the goods issue of the one piece for our product created 3 documents
In line one you see the goods issue posting on the project
The second journal entry embrace 5 line items representing the cost component split and posted with the business transaction type “TBCS”.
The first line of this journal entry reverses the goods issue amount. The next 4 line items reflecting the cost component split determined by our cost estimation in figure 27. So, for example you see cogs of direct material of 16,48€, which is equal to our material expenses shown in the cost estimate.
The next journal entry is posted by revenue recognition. Based on the planning a POC is calculated. The result is posted as realized revenue and WIP on the project.
This enables the following reporting
Figure 32 detailed margin reporting on project
The cost component split is visible on the project. So, your project reporting does not only show the goods issue amount on the project, but the more detailed information of its cost components.
This allows a multilevel margin reporting on the project and for your market segments customer and product.
As mentioned above the plan data are provided on sales order item level and thus on product and customer too.
This enables a plan actuals comparison for these market segments.
As mentioned above, this scenario is integrated with event-based revenue recognition. In our example revenue recognition postings were triggered with
Activation of Event based revenue recognition occurs when the sales order item is assigned to the billing element and a revenue recognition key can be derived successfully.
For our use case the following example is in place:
Figure 33 rev rec key derivation logic
For the leading sales order item, the revenue recognition key ‘Cost based POC’ is derived. The key is stored on billing element of the project. Because the same wbs billing element is assigned to the second sales order item, the revenue recognition key is also in place for the postings triggered by the second sales order item. Hence, the event-based revenue recognition is activated for both sales order items.
Leading sales order item and revenue recognition key is always coupled. No leading sales order item without revenue recognition key.
In addition, there are some check necessary to ensure the consistency of the process: Here an overview of the most important checks:
During the creation of a sales order item:
The following revenue recognition keys are currently available:
The revenue recognition key can be maintained via a SSCUI and is dependent of the contract type and the sales order item product:
Figure 34 SSCUI for rev rec key derivation
Please note even it is stored in the project, it is derived by the sales order item.
In order to analyze the process, to check for instance the real-time revenue recognition results and good issue postings the process specific Monitoring Apps can be used. To get the complete picture it is necessary to select with the billing element from the project.
In addition, the Monitoring apps support:
The solution enables a fast period close, since most of the revenue recognition postings are already recorded and only adjustment and clearing postings need to be made.
For our example the following postings are initiated:
Figure 35 posting logic for cost based POC
To show how the functionality behaves with the revenue recognition key ‘completed contract’ (EPMCC) we must adapt the example a little bit. To trigger the revenue and cost posting the project must have the status completed and fully invoiced. Therefore, the assumption for the following booking example is that the sales order item 10 (product SM00001) has a value of 148,08 €. The sales order item is fully billed with one time and the project is completed.
Figure 36 posting logic for completed contract
Now let’s come to the posting logic for ‘no revenue recognition method’ (EPMNC). Revenue and cost are recognized as occurred for projects.
Figure 37 posting logic for no rev rec
This method is used to assign a pricing and billing relevant sales order item to a wbs billing element w/o wanting any rev rec postings.
Feedback welcome
We hope you enjoyed this overview on the accounting solution for project based sales in S/4HANA cloud. It is another scenario, in which we are now benefiting from the innovations in financial accounting – the Universal Journal, the profitability attribution for revenue carrying objects and the event-based revenue recognition.
We will enhance functionality on roadmap – for example we currently specify the ETO scenario, customer downpayment and the valuated project stock. We will keep you updated.
Okumaya devam et...
Welcome to this blog, in which we will present the project accounting and controlling innovations for the customer project solution in S/4HANA cloud, which includes logistic business processes such as sales from stock, free of charge items, returns and simple engineer to order.
In this business scenario a project is assigned to sales order items to capture the costs and revenues of the logistical processes of a sales order. So, the outbound deliveries post expenses on the project. Customer invoices, credit and debit notes post revenues on the project. You can also – following rules – assign several sales order items to one wbs billing element.
In addition, costs can also be booked on this project with other transactions such as time sheet, activity allocation, supplier invoice, goods receipt to supplier invoice, post general journal entry or goods issue from stock. Overhead surcharges can also be posted on the project.
There is a simple manual project planning available, what allows project controlling by a plan/actual comparison and revenue recognition based on Percentage of Completion (PoC) methods.
To ensure the simplified business process including event-based revenue recognition and market segment margin out of the box, we provide this functionality along with assignment rules and for dedicated sales order item categories only. We enhance the list of sales order item categories and the supported scenarios release by release.
Please note that SAP S/4HANA Cloud provides additional a tailored end-to-end solution for professional services, which has consultancy, audit and tax companies in scope. This solution is described in the following blog.
We will start in this blog with first insights on new financial capabilities as appetizer. Then we show, how we benefit in this scenario from the financial innovations in S/4, before we come to the architecture and scenario setup.
Then we will show you an end-to end process in the system – including the scenario where we sell a manufactured product and post costs of goods sold split on the project. We close with deeper insights in the event -based revenue recognition.
I First financial insights
Let us start with some impressions about the – reporting – capabilities of financial accounting for customer projects in S/4HANA cloud.
This report provides the information to analyze the project profitability:
Figure 1 project profitability overview
The special features of this report are based on the underlying database and business processes:
- You get this report updated with every single posting on a customer project – e.g. a time confirmation for a work package.
- You get not only the costs, but also the matching realized revenue by realtime revenue recognition – see more in this blog: An Introduction to Event-Based Revenue Recognition with Customer Projects in SAP S/4HANA Cloud | SAP Blogs
- The KPIs are all based on aggregation of Journal entry line items. Thus, you can filter on many attributes of the journal entry. And very important you can rely on a single database and a single source of truth for the financial reporting.
- The tiles offer margin information by customer group and product group. This is possible as we derive and store market segment information in every journal entry posted on the project.
- The same we do for the revenue recognition postings. WIP can be drilled down by project and market segments – in the report above the product sold group
The next report shows how every project direct impact your customer and product margins:
Figure 2 product and service margins for customer projects
In the columns we use as KPIs the semantic tags – a grouping of G/L accounts.
You get for every project a single margin, but also per customer and product sold! The same market segment information is available for the accrued revenue/ WIP in the very right column.
Now let’s have a look, how your analysis capabilities in the trial balance increase. We start trial balance app, include as dimension the product sold, the customer and the project and then filter on our project.
Figure 3 trial balance drill down by project
There is no longer just one posted amount on the G/l accounts. You can trace for all G/L accounts posted with reference to our project the following attributes: our project and market segments like product and costumer derived from the assigned sales order item
Thus, you can drill down your WIP by e.g. product sold and customer; similar for the expense, revenue and CO postings.
The business processes belonging to the shown numbers we will look at in chapter 4.
II S/4HANA financial innovations for customer projects
The same as in the Professional services scenario – see blog link above – and the new service scenario New Financial Accounting for Service Management in S/4HANA Cloud | SAP Blogs we benefit in this scenario from HANA and the innovations in financial accounting – the Universal Journal, the profitability attribution for revenue carrying objects and the event-based revenue recognition.
With the Universal Journal the accounting applications General ledger, Controlling, event-based revenue recognition and Profitability are now integrated. Thus,
- we offer new insights into reporting and analysis for your customer projects, as profitability attributes are now available for all General ledger Journal entries like WIP, billing documents, good issues, time sheet – example see figure 3.
- We provide out-of-the box real-time revenue recognition with the event-based revenue recognition – including audit trails for each revenue recognition posting to primary posting on the project. There is an option to enter manual accruals with project account assignment.
- This allows together with event-based revenue recognition a real-time market segment and margin reporting.
- Simplified Period-end-close: Settlement between the applications – CO and CO-PA – is obsolete. We enrich in this customer project scenario, where a sales order is assigned, the profitability attributes already at the time of posting on the wbs element. Additionally, reconciliation between the financial application is obsolete.
- With integration in Universal Journal we get for all postings on customer project – Costs and revenues, as well as revenue recognition postings – the option for multiple currencies
- And we get the option for parallel valuation as we provide parallel ledger. So, for example you can use for your local ledger completed contract method and defer the costs. In the parallel ledger following IFRS accounting principle you can use cost based POC method- which we will show in chapter 4.
To allow a plan/actual comparison on the same structure and entities we store plan costs and revenues in ACDOCP, the corresponding database to the Universal Journal/ACDOCA, which contains the actuals.
With the planning on Customer project we derive the same market segment information as for the actuals. So, even if you plan just on customer project the assigned sales order item and its market segment attributes are derived and stored in every ACDOCP line item – see example in chapter 4.
An example for the controlling value flow for customer projects including the cost centers and their under/ over absorption you get in figure 4.
Figure 4 controlling value flow for project based sales process
This value flow principle we follow in S/4HANA cloud for revenue carrying objects.
The postings on the project are equal to the example in chapter 4. The time sheet on project and the overhead costs credit the cost centers and debit the customer project. These costs and the realized revenue calculated and posted by event-based revenue recognition provide a margin for the customer project and for product and customer.
The cost center is debited with periodic costs like asset depreciation, travel expenses or salary expenses. At period-end there will be a difference on the cost center between these debits and the credits posted to customer projects. These differences can be allocated to profitability segment. Assumption in our example here is, that they can be assigned on product and customer level. The level of assignment depends of course on the customer business. Technically it would be possible to even assign these costs on customer project or sales order item.
So, the profitability for product and customer is the aggregation of the customer project costs and revenues and the allocation to profitability segment. In our example the margin for the product “SM0001” is 14,28€.
III Financial Accounting architecture and scenario setup
Our architecture for sales order and project setup is driven by the target to allow for every posting on the project – independent if manual or by the sales document flow – an automated margin reporting on the market segment attributes.
To define a unique profitability segment and to allow the determination of a revenue recognition key we must be able to identify a leading sales order item.
in the current approach, in release CE 2011 we define the first assigned pricing and billing relevant sales order item as the leading one, and therefore, there can be only one assigned to the billing element.
The non-billing relevant free of charge items post only costs on the project element, which is assigned to the sales order items. There can be multiple free of charge items assigned to the same billing project element.
This setup is visualized in the figure below.
Figure 5 – financial setup for project based sales scenario
For the billing project element and the related sub-tree there is a unique profit center defined.
The unique pricing and billing relevant sales order item – here item 10 – derives the revenue recognition key. The key is stored in the billing project element – see chapter 6.
Additionally, this leading sales order item defines the unique profitability segment which is derived for every posting on the billing work package and the work packages below.
How this derivation by posting on project works, shows the next figure.
Figure 6 – market segment derivation logic for project based sales
For every posting on a wbs element we check if there is a leading sales order to the wbs billing element assigned (if the posting is done on a workpackage, which is no billing element, we read the superordinate wbs billing element). If we get in the wbs billing element a leading sales order item, we read this sales order item and derive a profitability segment on the fly: with the product sold defined by this sales order item, customer, sales organization and division from the sales order header. And we derive attributes, which are defined in the company profitability segment: so, we define the product and customer group. If profitability extensibility is in place, these fields will be derived too! We do not store the profitability segment on the sales order or wbs element. It is available in the journal entries only.
With the Universal Journal it is now possible to use in one Journal entry line item several cost objects in parallel. This was not possible in ERP. We still have exact only one real account assignment for every line item. This is identified with the field “Object type” (technically ACCASTY). In our example it is “PR”, what indicates a wbs element assignment. Only on the real account assignment are follow-up processes possible like revenue recognition. The other account assignments are attributed and only for reporting purposes. We use this here with having the sales order item and the profitability segment attributed.
Thus, not only a project margin can be provided by the postings on the project, but also a profitability reporting on the market segments is available. With the use of Universal Journal integrated Profitability we derive for every posting on a wbs element a profitability segment – based on the attributes in leading sales order item – and enrich the journal entry -like we do it in the customer project scenario – see blog mentioned above.
There are scenario variants in place
- In the scenario, in which costs are posted on a project before assignment of a leading sales order item, you need to run the profitability realignment after sales order item assignment to update the already posted journal entries with the market segment information. The next revenue recognition run will take all the postings in account and apply up-to-date revenue recognition data.
- In the scenario w/o leading sales order item or in case you want to define the profitability segment manual, you can apply a settlement rule on the wbs billing element, in which exact one profitability segment is defined. This profitability segment will be read by every posting on the project – instead of the leading sales order item. The settlement rule will not be used for settlement. There is no settlement in place.
- If you do not want revenue recognition, you need to derive for “pricing and billing relevant” sales order items a rev rec key “non rev rec”. Otherwise you cannot assign a wbs element. With this you get a leading sales order item and the rev rec key will be stored in the WBS billing element.
- As mentioned, there can be only one pricing and billing relevant sales order item assigned, but multiply additional non billable items
- There can be many not billing relevant items assigned to one billing element and no pricing and billing relevant sales order item. Then there will be no leading sales order item no rev rec key and no automatic defined profitability segment. But you can define profitability segment manual by the settlement rule in the billing element
There are rules in place for changing the assignment of a sales order item to the wbs billing element
- You can assign a wbs billing element to a pricing and billing relevant sales order item, if there is not yet a leading sales order item assigned – free of charge items can be assigned already.
- If there exists one successor document for the sales order item – like a delivery – the wbs account assignment in the sales order item cannot be changed or deleted anymore
- For the wbs assignment change on the leading sales order item, there is an additional check: there must not be any revenue recognition postings, the assignment can be deleted and changed.
IV Project based sales business processes
Now let’s take a look at the various financial accounting capabilities by a simple end-to-end project based sales process.
In our example we will create a sales order with a service item and a free of charge item. Both we assign to the same wbs billing element.
First, we start with the Project creation and the app “project control”.
Figure 7 creation of the project
We select the profile “project with revenue”. The functional area is “YB18 cost of goods sold”. We want to apply overhead surcharges; thus we assign the costing sheet “1010PI”. We set Project status to released.
Next step is the sales order creation
Figure 8 sales order creation
First item with product SM001 is billing relevant with a planned billing amount of 1200€, which is defined in a milestone billing plan. This is the main item – relevant for determination of revenue recognition and profitability segment.
The second item with product TG12 is a free of charge item.
Both items are assigned to the billing element SW-Mario09, what you can check in the very right column.
Now we plan the project to allow a plan- actual comparison and to allow a percentage of completion (PoC). Please note: there is the option with the file upload and also SAC Integration available.
We first enter the data in an Excel-file:
Figure 9 – Excel file for project planning
We use plan category PLN. This category is used in revenue recognition for POC calculation.
We enter just 2 lines. The first line is the expense planning based on the expense account 51600000. The second line reflects the planned revenue by the revenue G/L account 41000000.
Please note: line 3 with the X entries is very important. The X defines per column which data are replaced in ACDOCA. More information you can get here: SAP Help Portal
Then we start the app “Import Financial plan data”
Figure 10 – app for project planning
When you upload the file, you get notified, if you would reverse with the upload already existing plan data.
After successful upload Let’ have a look on the project plan data. We start the app “project plan actual”
Figure 11 – analysis of the plan data on project
You see here the both line items we entered in the file.
But please recognize, for our plan data there is the information about customer and product sold additional derived! The same as for the actual postings we use the assignment of the wbs billing element to the leading sales order to derive additional market segment attributes.
So, if you plan a project after assignment of the project to a leading sales order item you get the plan data on sales order item level too!
Now let’s come to the first actual posting with the outbound delivery for the free of charge item.
Figure 12 – outbound delivery
With pressing the bottom “post goods issue” we get the following journal entries:
Figure 13 – created journal entries of outbound delivery
The second document is the prima nota, which reflects the goods issue. And then you the see the impact of parallel accounting: Journal Entry 1, 3, and 4 are the revenue recognition postings per active ledger in company code 1010.
Let’s analyze the Journal entries for the leading ledger 0L
Figure 14 – journal entries of outbound delivery in leading ledger
The first two line items reflect the goods issue: the credit of the inventory and the debit of the project in line item 2.
The second journal entry is the revenue recognition posting. The realized revenue – calculated by the POC – and the balance sheet activation with WIP G/L account.
All line items are referenced to the logistic goods issue posting (see column 4).
The POC is calculated by actuals costs divided by planned costs = 40€/1000€= 4%. The POC is multiplied with the planned revenue: 4%*1200€= 48€ realized revenue.
The expense posting of the goods issue and the revenue recognition postings are account assigned to the project (see object type = PR in column 7). As there is a leading sales order item 15245/10 in the billing element defined, we derive the sales order item and subsequent profitability attributes from the sales order item like product sold SM0001, the customer 10100001 or the sales organization 1010.
Now let’s come to the next business transaction: a time confirmation on the project.
We start the app “My time sheet”.
First you need to create here a task for the project. You can assign in the task the billing element or a subordinate wbs element.
Figure 15 – time confirmation on the customer project
We mark the task of our project and select 1 h on Friday, the 6th and save.
The subsequent posted journal entries you see here:
Figure 16 – journal entries of time confirmation on the customer project
The first two line items reflect the CO activity allocation: the credit of the employees’ cost center and the debit of the project in line item 2, in which you get the used activity type – see column Part.CC.Activity – with the confirmed 1 hour.
The second journal entry is the revenue recognition posting. The realized revenue – calculated by the POC – and the balance sheet activation with WIP G/L account.
All line items are referenced to the time sheet entry – see in column 3 the reference doc type =CATS and the CATS document 85 in column 4.
The POC is calculated by actuals costs divided by planned costs = 75€/1000€= 7,5%. The POC is multiplied with the planned revenue: 7,5%*1200€= 90€ realized revenue.
The activity allocation debit and the revenue recognition postings are account assigned to the project (see object type = PR in column 7). As there is a leading sales order item 15245/10 in the billing element defined, we derive the sales order item and subsequent profitability attributes from the sales order item like product sold SM0001 and the customer 10100001.
We start now a periodic overhead calculation for our project with the app “Run overhead calculation – projects actual”.
Figure 17 – selection screen for overhead calculation
We select our Project SW-Mario09 and the period – here 11/2020.
Figure 18 – log for overhead calculation
In the log you see the calculation condition scheme. 10% material overheads calculated on the material expenses and on the sum of both there is an additional administration overhead percentage of additional 10% applied.
Please note: the displayed currency is here the global currency USD. The percentage is calculated for every currency in parallel.
Let’s have a look on the posted journal entry in the leading ledger 0L.
Figure 19 – JE for overhead calculation
The first two journal entries with two items each reflect the CO overhead calculation posting for material overhead and administration overhead: the debit of the project and the credit of the cost center in the second line item.
The 2 journal entries below are the revenue recognition postings- one Journal Entry per overhead rate. The realized revenue – calculated by the POC – and the balance sheet activation with WIP G/L account.
All line items are referenced to the overhead document – see column 4.
The overheads debit and the revenue recognition postings are account assigned to the project (see object type = PR in column 7). As in the examples before the profitability attributes are derived by the leading sales order item 15245/10 and stored in the journal entry line items.
Now let’s have a look on the revenue recognition values with the app Event based revenue recognition projects 2.
Figure 20 – revenue recognition values on the project after cost postings before billing
In the upper section you see the income statement relevant postings. The actuals posted on the project sum up to 123,40€. The matching recognized revenue is 148,08€. This leads to a calculated margin of 24,68€.
In the second section you see the balance sheet values. Here we have the WIP or Accrued revenue of 148, 08€ – the offset to the recognized revenues.
The bottom section shows the – for revenue recognition recognized – plan data: planned revenue of 1.200€ and planned costs of 1000€.
Now we come to the billing.
With the app Create Billing document we get the due billing plan item for our service item.
Figure 21 – billing due list
We select the line item with our order 15245 and hit the button Create Billing documents and come to the screen below.
Figure 22 – billing document
In the billing document we have one item for our product SM0001 and 120€, which is the Amount out of the billing plan.
We select the button “Post Billing document” and get the Journal entries below for leading ledger 0L.
Figure 23 – journal entries of billing document
The first three line items reflect the billing document: the receivables line item, the credit of the project with the billed revenue and the tax line item.
The 2 journal entry line items below are the revenue recognition line items. The revenue adjustment and the balance sheet line item on deferred revenues.
Note: We need to defer the billed revenues as we have already realized revenue with the cost postings. (these postings are explained by T-accounts in section 7)
All line items are referenced to the billing document – see column 4.
The billed revenue line and the revenue recognition postings are account assigned to the wbs billing element. As in the examples before the profitability attributes are derived by the leading sales order item 15245/10 and stored in the journal entry line items.
To net the revenue recognition balance sheet Amounts deferred and accrued revenues, we start again the revenue recognition monitor above and reevaluate (this is normally done automatically by period-end-closing run). This results in the posting below.
Figure 24 – journal entries of revenue recognition balance sheet netting
Both line items are posted on balance sheet G/L accounts. The deferred revenue of 120€ – resulting from billing – is netted with the accrued revenue.
Please note: the revenue recognition line items are account assigned to the project (Column 8 object type = PR) and all profitability attributes are derived.
More to the posting logic we describe in chapter 6
Now we start again the revenue recognition app to analyze the revenue recognition of our project:
Figure 25 – revenue recognition values on the project after cost postings, billing and rev rec netting
In the upper section you see the actual costs of 123,40€ and the recognized revenue of 148,08€; while the billed revenue is 120€. The difference you see in the accrued revenue/WIP in the second section.
All these postings lead now to the following margin reporting on the project
Figure 26 – margin reporting for project
The line items reflect the single postings in this chapter. You see the recognized margin of 24,68€ in the respective column is valid for the project, but impacts also the margin the sales order, the product sold, customer and sales org.
On the very right column you see the balance of 28.08€ on the WIP account. This is the effect that we realized more revenue than yet is billed.
The enhanced reporting capabilities you can realize in the trial balance too. If you start the trial balance for company code 1010 and then add the dimension Project definition and filter on our project SW-Mario09, you will get the report in figure 3.
V Selling a manufactured product in project based sales scenario
Now we show you a new scenario. In this scenario we sell a manufactured product leading to cost component split postings on project, what allows now a multilevel cross margin reporting on the project.
First let’s have a look on the product. Based on its quantity structure, BOM and routing, a cost estimate is performed – see below.
Figure 27 cost estimation for product by cost components
To show the usage of material and working hours on a multi-level basis there is a cost component split available.
100 pieces of product FG126 cost 1.807€, thereof material expenses of 1.648€
Then we create a sales order and assign the wbs billing element “SW-Mario07”
Figure 28 sales order item of a manufactured product assigned to project
We plan the project to allow POC calculation by the event-based revenue recognition
Figure 29 planning file for project
We upload this with the planning app as in chapter 4
Then we post the outbound delivery
Figure 30 outbound delivery for sales order
We subsequent post a goods issue of this one piece.
This leads to the following journal entry
Figure 31 journal entry for outbound delivery including cogs split and revenue recognition
You see here, the goods issue of the one piece for our product created 3 documents
In line one you see the goods issue posting on the project
The second journal entry embrace 5 line items representing the cost component split and posted with the business transaction type “TBCS”.
The first line of this journal entry reverses the goods issue amount. The next 4 line items reflecting the cost component split determined by our cost estimation in figure 27. So, for example you see cogs of direct material of 16,48€, which is equal to our material expenses shown in the cost estimate.
The next journal entry is posted by revenue recognition. Based on the planning a POC is calculated. The result is posted as realized revenue and WIP on the project.
This enables the following reporting
Figure 32 detailed margin reporting on project
The cost component split is visible on the project. So, your project reporting does not only show the goods issue amount on the project, but the more detailed information of its cost components.
This allows a multilevel margin reporting on the project and for your market segments customer and product.
As mentioned above the plan data are provided on sales order item level and thus on product and customer too.
This enables a plan actuals comparison for these market segments.
VI Further insights revenue recognition
As mentioned above, this scenario is integrated with event-based revenue recognition. In our example revenue recognition postings were triggered with
- goods issue,
- time confirmation
- overhead calculation
- customer invoicing
Activation of Event based revenue recognition occurs when the sales order item is assigned to the billing element and a revenue recognition key can be derived successfully.
For our use case the following example is in place:
Figure 33 rev rec key derivation logic
For the leading sales order item, the revenue recognition key ‘Cost based POC’ is derived. The key is stored on billing element of the project. Because the same wbs billing element is assigned to the second sales order item, the revenue recognition key is also in place for the postings triggered by the second sales order item. Hence, the event-based revenue recognition is activated for both sales order items.
Leading sales order item and revenue recognition key is always coupled. No leading sales order item without revenue recognition key.
In addition, there are some check necessary to ensure the consistency of the process: Here an overview of the most important checks:
During the creation of a sales order item:
- if a sales order item is relevant for standard pricing and billing relevant
- a) revenue recognition key can be determined
- if there is already a leading sales order item on the billing element
-> assignment is not possible - if there is no billing element assigned store leading sales order item and revenue recognition key
- if there is already a leading sales order item on the billing element
- b) revenue recognition key cannot be determined-
> refuse assignment
- a) revenue recognition key can be determined
- if an item is relevant for free goods pricing and billing relevant, no revenue recognition key is derived, and it will never update leading sales order item
The following revenue recognition keys are currently available:
- Cost-Based Percentage-of-Completion Method (EPMFC)
- Revenue is calculated on cost-based percentage of completion and recognized at time of posting goods issues for deliveries from the sales orders or with any other business transaction posting costs on the project such as time confirmation
- Completed Contract Method (EPMCC)
- Revenue and cost are deferred during the lifetime of a project and recognized when the status of the project is completed
- No Revenue Recognition Method (EPMNC)
- Revenue and cost are recognized as occurred for projects
The revenue recognition key can be maintained via a SSCUI and is dependent of the contract type and the sales order item product:
Figure 34 SSCUI for rev rec key derivation
Please note even it is stored in the project, it is derived by the sales order item.
In order to analyze the process, to check for instance the real-time revenue recognition results and good issue postings the process specific Monitoring Apps can be used. To get the complete picture it is necessary to select with the billing element from the project.
In addition, the Monitoring apps support:
- manual contract accruals
- Manual accruals can be posted by the event-based revenue recognition app. On separate G/L accounts, by providing a comment, which is stored in journal entry item text, account assigned to the WBS billing element. The manual accruals are automatically cleared with the status completed from the project
- temporary adjustments
- It is possible to enter temporary manual adjustments through the app. Entered manual adjustments will be cleared again the next periodic revenue recognition run.
- show G/L Account Line Items-Reporting (e.g. shown in figure 31)
The solution enables a fast period close, since most of the revenue recognition postings are already recorded and only adjustment and clearing postings need to be made.
For our example the following postings are initiated:
Figure 35 posting logic for cost based POC
To show how the functionality behaves with the revenue recognition key ‘completed contract’ (EPMCC) we must adapt the example a little bit. To trigger the revenue and cost posting the project must have the status completed and fully invoiced. Therefore, the assumption for the following booking example is that the sales order item 10 (product SM00001) has a value of 148,08 €. The sales order item is fully billed with one time and the project is completed.
Figure 36 posting logic for completed contract
Now let’s come to the posting logic for ‘no revenue recognition method’ (EPMNC). Revenue and cost are recognized as occurred for projects.
Figure 37 posting logic for no rev rec
This method is used to assign a pricing and billing relevant sales order item to a wbs billing element w/o wanting any rev rec postings.
Feedback welcome
We hope you enjoyed this overview on the accounting solution for project based sales in S/4HANA cloud. It is another scenario, in which we are now benefiting from the innovations in financial accounting – the Universal Journal, the profitability attribution for revenue carrying objects and the event-based revenue recognition.
We will enhance functionality on roadmap – for example we currently specify the ETO scenario, customer downpayment and the valuated project stock. We will keep you updated.
Okumaya devam et...