Expand +



SAP S/4HANA: First Steps Toward Real-Time Profitability Analysis

by Janet Salmon, Product Manager, SAP SE and Stefan Walz, Chief Business Process Architect, Financials Development, SAP

May 11, 2017

Janet Salmon and Stefan Walz look at real-time Profitability Analysis (CO-PA) processes in the context of project-based services with a view to combining a simple form of revenue recognition with enhanced cost management insights. They explain how each posting to a project can be extended to update the associated profitability characteristics and how to use project time confirmation to trigger real-time revenue recognition. They describe which types of projects can benefit from this approach, discuss the impact of deriving profitability characteristics at the time of posting, and explain the new configuration options delivered with SAP S/4HANA 1610.

Several articles in SAPinsider have already outlined the shifts in profitability reporting and the move toward real-time finance processes. We briefly recap the basics of profitability reporting in SAP S/4HANA and then show you what changes. We explain how a time recording to a project can trigger a revenue recognition posting that in previous releases required you first to run results analysis and then to settle the project.

Profitability Reporting and Characteristic Derivation

Let’s start by looking at profitability reporting in SAP S/4HANA in general.

The article “SAP Simple Finance: New Options in Profitability Analysis” explained how the revenue and cost of goods sold postings are automatically linked with the relevant profitability characteristics for reporting purposes. You find a detailed description of the implications for a conversion project in SAP Note 2349278 (S4TWL - Profitability Analysis) and SAP Note 2349297 (S4TWL - Reporting/Analytics in Controlling). What this means is that Profitability Analysis (CO-PA), which was previously a separate application, becomes part of the universal journal.

Activating account-based CO-PA ensures that table fields are created in the universal journal for all the profitability characteristics in your operating concern. During migration your existing account-based CO-PA data is moved to the universal journal and the cost elements are merged with the accounts to give you a single profitability document that can provide the basis for both internal and external reporting. When the universal journal was introduced with the SAP S/4HANA Finance 1503 edition, the controlling processes were still needed to move costs to CO-PA at period close. In the case of projects this meant that settlement was needed to transfer the costs from the projects to CO-PA at period close. With the new approach, delivered with 1610, companies’ projects no longer need to be settled because there is now a new approach that immediately calculates the revenue to be recognized and generates the appropriate posting without waiting for period close.

Ajay Maheshwari’s article, “You Are Now a Step Closer to Real-Time Profitability in SAP S/4HANA Finance with Fewer Settlements,” showed how profitability reporting works for internal orders and explained how expense postings made to cost centers, orders, and projects could be extended to update the associated profitability characteristics. He explained how to set up derivation functions to read the profitability characteristics for an internal order from the settlement rule instead of waiting for the settlement process to credit the order (sender) and debit profitability analysis (receiver).

The same approach can be taken for customer or billable projects so that expenses charged to the work breakdown structure (WBS) show as cost postings to the project, but also as an assignment to the profitability characteristics. Where the WBS element is a billable item, the revenue postings are handled the same way and also assigned to profitability characteristics using the information in the settlement rule, using the mechanisms described in Ajay Maheshwari’s article.

Since there is now no need to settle, the settlement rule becomes redundant and deriving the characteristics from the settlement rule makes no sense. As an alternative, you can configure the system to read the profitability characteristics for the assigned sales order item. This only works if there is a one-to-one relationship between the WBS billing element and sales order item. With this approach, the CO-PA characteristics are effectively extending the posting line, giving you a real cost assignment to the WBS element and an additional statistical cost assignment to the CO-PA characteristics. If at the time of posting there are no profitability attributes, as might be the case at the start of the project where there is neither a settlement rule nor an assigned sales order item, then you can use the new CO-PA realignment function to update the CO-PA assignments in the relevant journal entries posted for the WBS element, once the detail is available.

Event-Based Revenue Recognition

We now look in detail at a further enhancement by showing you how to create an additional posting line that recognizes the revenue to be accrued for a billable customer project. Figure 1 shows the journal entries for a time confirmation on a customer project in the G/L Account Line Items application. Users can access this app from the tiles delivered as part of the G/L accountant role. In the Journal Entry column, you can see the twin journal entries triggered by the time recording and created simultaneously, with reference to the time recording.

Figure 1
Follow-on posting in the G/L Account Line Items app

We now explain the four posting lines (journal entries) shown in Figure 1. The first two posting lines are familiar to any controller. We have credited Cost Center 10101902 and debited WBS Element SW007 1.1 for one hour of consulting activity as a direct activity allocation (RKL) shown in the BusT (business transaction) column. Normally this posting would remain on the WBS element as an expense until you performed results analysis and settled to move the values to CO-PA at period close.

Now, however, the time recording has triggered two further posting lines under the new business transaction TBRR (transaction-based revenue recognition), which makes a revenue adjustment of EUR 120 for the work performed. The revenue adjustment is to a profit-and loss (P&L) account and the accrued revenue to a balance sheet account. This posting takes place on the basis of the revenue recognition key in the WBS element, ensuring that revenues are realized on confirmation based on a percentage of completion (POC) that uses the costs as its basis. Notice how the two documents are linked by the common document number in the Ref. Doc. (reference document) column (we’ve entered this document number in the selection criteria of the report to focus attention on this double document).

In the cloud edition of SAP S/4HANA, this type of real-time revenue recognition is available for all postings on a project and the delivered settings ensure that an appropriate revenue recognition key is assigned to the top-most WBS billing element before the first posting is made to the project. There is a one-to-one relationship between the sales order item and the WBS billing element that includes a billing plan to define the planned revenues. The settings also ensure that the appropriate cost planning is available for the project so that the percentage of completion can be calculated.

In the on-premise edition of SAP S/4HANA, it is the task of the implementation team to ensure that there is a one-to-one relationship between the sales order item and the billing element and that the appropriate cost plan is in place.

The trigger for the new process is the direct activity allocation (RKL) posting initiated by the time confirmation and—in the case of a fixed price project—the values contained in this document. Notice that the time recording resulted in a charge of 75 euros to the WBS element and the revenue adjustment is for 120 euros. In the case of a fixed price contract, the system calculates the realized revenue using the cost-based POC multiplied with the planned revenue. In the case of a time and materials (T&M) project, the system simulates the T&M billing to calculate the revenue to be realized.

While Figure 1 shows the new posting approach in a familiar application, SAP also offers new applications designed to support the new process. Figure 2 shows the new application for Event-Based Revenue Recognition - Projects. You find this application in the Sales Accountant role. This app lists all WBS elements that are flagged as Billing Elements with an appropriate revenue recognition key. You can then select from the relevant Billing Elements to view the details. You also need to ensure that the WBS element is assigned to the correct recognition key that controls whether it is a fixed price project, a time and expense (T&E) project, or a project with periodic billing. Notice from the different key names that we provided an example with three different approaches to revenue recognition by configuring three recognition keys (the Recognition… column).

Figure 2
The Event-Based Revenue Recognition app

If you caught yourself looking at Figure 1 and wondering what happened during the calculation, then Figure 3 explains the details. To drill into the detail, select the WBS billing element SW007.0.1 in Figure 2. Here you can see the charged costs, the billed revenue (if there is any), the revenue adjustments associated with the actual cost, and the accrued revenue. In the case of a fixed price project, the app shows the planned values. These values are taken into account for revenue realization.

Figure 3
Details of a fixed price project

The automation is a huge benefit of SAP S/4HANA, but there can be times when a project manager knows things that the system can’t know about the project. For this reason, you notice two links (Enter Temporary Adjustment and Enter Accruals) at the top right of the application. In Figure 4 we have entered manual accruals to allow for the fact that the project manager knows that the customer will claim a discount.

Figure 4
Manual accrual postings

The manual accruals are posted as a journal entry with the assignment to the project and the text is updated to the journal entry. Figure 5 shows the result of these manual accruals (we’ve ringed the two lines to show how these differ from the posting lines we looked at in Figure 1). These manual accruals can be reported by project showing the item text as a reminder as to why the posting was made. Here again, we are performing a posting that updates the WBS element, but it is also assigned to the appropriate market segments so that these manual accruals are included in the view of project profitability.

Figure 5
A G/L account line item report showing all postings on a project, including the manual revenue recognition posting

What Happens at Period Close

While event-based revenue recognition represents a huge leap forward, it doesn’t take changes during the period into account, such as a change to the percentage of completion, hours that have to be written off in the case of T&M billing, or a status change to the project. The period close is the time to take account of such information and adjust the financial view of the project to reflect any new information.

You may also find that errors occurred and the posting to the WBS element was made successfully, but the follow-on revenue recognition posting failed. There are various sources for such problems. The plan data might have been incomplete or there might have been no revenue recognition key assigned to the project at the time of billing. For this reason, you should still perform a revenue recognition run at period close to fix any inconsistencies.

You find the Event-Based Revenue Recognition application (Figure 6) in the Sales Accountant role. The selection part of the screen looks familiar if you’ve worked with results analysis, but we focus on the bottom part of the screen. Here you can see whether the follow-on postings were made successfully or need to be retriggered. Here you find details about why the posting failed. You need to ensure that errors are fixed here before you execute results analysis to recognize the proper revenue for the period. Once you have completed this step, you can run revenue recognition for the project by clicking the Execute button in Figure 6.

Figure 6
Event-Based Revenue Recognition for Projects or WBS Elements

As we think about the period close, it’s worth looking at the account assignments in more detail. Figure 7 shows the same application as in Figure 1 with the cost assignment to the WBS element. This is the genuine cost assignment in terms of the account assignment. In the universal journal (table ACDOCA) this is captured by the PR (for project) in the ACCASTY field. We’ve pulled in additional columns to show the provided market segments Customer, Customer Group, PA Product, Sales Order and Sales Org—pulled from the settlement rule of the WBS billing element or the assigned sales order item. This followed the same basic approach described by Ajay Maheshwari in his article. The costs are shown for these CO-PA characteristics immediately, without requiring you to settle at period close. We have essentially extended the project cost line to include the CO-PA characteristics.

Figure 7
CO-PA characteristics in the G/L Account Line Items app

What is interesting here is that we also see work in process (WIP) and reserves assigned to CO-PA characteristics. WIP was previously only visible by company code and profit center, and now we can see the revenue adjustment and accrued revenue associated with all the CO-PA characteristics for this project. This is a huge benefit for project managers whose projects have significant work in process.

For an accountant, it is now possible to drill down from financials statement revenue recognition values to the single postings. This improves transparency massively and simplifies auditor work. No reconciliation efforts are needed anymore.

With this posting logic the system ensures that the matching principle is ensured for realized revenues and costs. All profitability reports are up-to-date with every confirmation and the controller or project lead can always trust the data instead of waiting until all closing steps are done. You can see this situation clearly in the application shown in Figure 8 in which you see how the confirmation (actual costs of 65 euros) has influenced the profitability of the product and customer in real time.

Figure 8
Project Profitability app available in the cloud

Figure 9 shows another report, Projects – Actuals. This report gives you an impression of what the new 360-degree view means for a single project. In previous releases, the project reports showed the revenue and costs on the project under the original cost elements and separate reports showed the results of performing results analysis. To see the associated customer and product information, you needed then moved to CO-PA, which would show the results of settlement. Now, if you select the project definition, you see both the project and the associated product and customer for each line thanks to the characteristic derivation.

Figure 9
Project report

In addition, you see the accounts/cost elements for the original posting (consulting, travel expense and billed revenue), the accounts for the follow-on postings (revenue recognition adjustment and the balance account), and the account for the manual reserve (reserves for unrealized costs). If you’ve ever asked yourself why CO-PA historically showed revenue minus costs, but not WIP, this is a step forward, with all period-related costs associated with the project being shown for the CO-PA characteristics.

Settings for Event-Based Revenue Recognition

You find the settings to control event-based revenue recognition in the IMG under menu path Controlling > Product Cost Controlling > Product Cost by Sales Order > Period-End Closing > Event-Based Revenue Recognition > Maintain Settings for Revenue Recognition. Revenue recognition is performed only if the relevant WBS element includes a recognition key (Figure 2). Figure 10 shows the settings for a sample recognition key). Notice in Figure 10 that it is possible to take different approaches to revenue recognition depending on the accounting principle with which you are working.

Figure 10
Settings for the recognition key

As you can see from the settings in Figure 11, the recognition key alone is just the starting point (if you are familiar with results analysis, you recognize the same behavior in the results analysis key). You also need to make sure that the system knows which accounts or cost elements are relevant for revenue recognition by defining a Source under Sources > Assign Cost Elements and Accounts in Figure 11. In Figure 11 we grouped all relevant cost line items into one cost group of Debit type Costs, but you can also use cost element categories, cost element groups, accounts, or the condition types from sales and distribution (SD) billing to make your selection. Just as you had to make sure that all relevant accounts were assigned to line IDs for results analysis, you have to ensure that all relevant accounts are included in the Sources for event-based revenue recognition.

Figure 11
Source assignment

The next step is to make this assignment source part of an Assignment Rule under Assignment Rules > Assign Sources and Posting Rules. In Figure 12 you can see the accounts that will be updated for revenue recognition. This is the equivalent of the old posting rules in results analysis with the difference that the postings will be made immediately rather than on settlement.

Figure 12
An assignment rule

Finally, you can define a separate document type for the revenue recognition postings, as shown under Document Type and Financial Statement Version in Figure 13. You see this document type in the Journal Entry column in Figure 1.

Figure 13
Document types for revenue recognition

Methods of Revenue Recognition Supported

So far, we’ve discussed the basic logic of the double posting for time recording and revenue recognition, but to run a real project, you need to understand what methods are available. Table 1 provides an overview of the options provided with the first edition of these features.


Type of billing


Cost/working hours based on POC

Fixed price Billing

The POC for delivery is measured in terms of expenses (planned costs from project planning) or in terms of working hours.
Confirmations are posted as expenses. In addition, realized revenues are posted (based on planned revenues from an SD billing plan).
Invoices are posted to an income statement account and reposted to deferred revenue.

Invoice based (POC)

Fixed price billing

Confirmations are posted as expenses and directly reposted to WIP.

Invoices are posted as realized revenues, whereas the cost of goods sold (COGS) is calculated on the basis of the planned values. COGS postings will post accrued costs.

Cost-based T&E

T&E billing

Confirmations are posted as expenses. In addition, realized revenues are posted (based on a DP90/ DMR simulation).
Invoices are posted to an income statement account and directly reposted to deferred revenue.
For T&E projects a new report, Display Project WIP Details, is available (e.g., WIP aging).

Time-based revenue recognition

Periodic billing

Confirmations are posted as WIP (COS adjustments).
Invoices are posted as billed revenues and reposted to deferred revenues.
The periodic run recognizes costs and revenues in a time-based fashion following the invoice schedule/ billing plan.

No deferral

All types of billings

Confirmations are posted as expenses and billings as revenues (projects without any recognition key).

Completed contract

All types of billings

Confirmations are posted as expenses and reposted to WIP.

Invoices are posted to an income statement account and reposted to deferred revenue.

All costs and revenue are recognized at period end closing (revenue recognition run), if the status finally billed or technically complete is active.

Manual revenue recognition

All types of billings

Confirmations are posted as expenses. Invoices are posted as billed revenues and reposted to deferred revenues.

Revenues are recognized manually by either giving a currency amount or a POC. The POC would then be applied to the plan revenue.

Table 1
A summary of revenue recognition options in SAP S/4HANA 1610

An email has been sent to:


Janet Salmon

Janet Salmon ( joined SAP in 1992. After six months of training on R/2, she began work as a translator, becoming a technical writer for the Product Costing area in 1993. As English speakers with a grasp of German costing methodologies were rare in the early 1990s, she began to hold classes and became a product manager for the Product Costing area in 1996, helping numerous international organizations set up Product Costing. More recently, she has worked on CO content for SAP NetWeaver Business Warehouse, Financial Analytics, and role-based portals. She is currently chief product owner for management accounting. She lives in Speyer, Germany, with her husband and two children.

Stefan Walz

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!