How Has Controlling Changed with SAP S/4HANA?

In this blog post, we want to illustrate the evolution of controlling in SAP S/4HANA.

The functional and architectural effects should be easy to understand based on the evolutionary steps. Our guiding principles are the simplification of the processes and the gain in transparency and analysis options.

As an example, let’s consider the SAP S/4HANA implementation project at a company. In a first step, you post costs to the implementation project by time confirmation. Because the project is billable, you apply revenue recognition to get the matching realized revenue and the WIP/accrued revenue. The goal in this example is to have the results of the revenue recognition available in the general ledger and a margin on the project and the associated market segment (here the customer and the product, which is the SAP S/4HANA implementation) can be shown.

Now let’s look at the processes that got us started: the SAP ERP functionality, as shown in this figure.

You can see that each process step has its own database per application, which meet different requirements. The time recording is initially only persisted in the controlling table, so the costs are visible for the project. At the end of the period, there is a results analysis run, which determines the matching revenue and the WIP. The result is stored in separate results analysis tables. Another periodic job is started: the settlement. It consists of two parts: the settlement to the general ledger, to update the balance sheet and income statement, and the settlement to costing-based profitability analysis to provide the costs and revenues for the market segments involved.

With this setup, you face the following challenges:

• The combined content of several tables represents the truth. Reconciliation efforts are enforced by design.
• There is a need for a periodic transfer of data (a settlement) to the appropriate table for reporting and subsequent processing. As a consequence, there is no current data in the different applications. You see data in the general ledger first at the period end.
• The structure divergency of the applications leads to deviating reporting entities. So, you have the general ledger account in the general ledger, the cost element in controlling, a special cost element in result analysis, and a value field in profitability. At the same time, there are different reporting capabilities and entities in the different applications. So the ledger as a reporting entity is only available in general ledger; there are deviating currencies in the different applications and availability of market segment attributes only in costing-based profitability analysis.

With the introduction of SAP S/4HANA Finance, you get the general ledger, controlling, and margin analysis integrated in one database: a first simplification. Results analysis is still an application that the Universal Journal does not include. Thus, there is still a settlement required to update the other applications. The figure below provides our example with specific amounts.

In step 1, the time recording is now persisted in the Universal Journal and thus in the general ledger. The project reporting can be done based on Universal Journal. We still need the periodic runs. In step 2, the result analysis still stores the realized revenue, matching it to the posted costs, and the WIP in separate results analysis tables.

The settlement now posts in the Universal Journal in step 3. In step , there is a settlement with document 2 to the general ledger, to update the balance sheet and income statement. In step , you post document 3, which credits the project and debits the profitability segment. The first two lines settle the realized revenue; the next two line items settle the costs.

Margin analysis is now done in the Universal Journal. When you start a report for the SAP S/4HANA implementation project, you’ll see two line items:

1. SAP S/4HANA implementation settlement revenue ($260)
2. SAP S/4HANA implementation settlement cost of goods sold ($200)

And with the aggregation, you get a margin of $60.

This is a first step to bringing the applications together and running them on one data model. But to further simplify, to provide data in real time and to improve the analysis capabilities, there are two additional features: event-based revenue recognition and attribution of the market segments.

The next figure shows how the preceding example is reflected in the system with the new cost management approach.

This is a dramatic simplification. The event-based revenue recognition is triggered by the cost posting. This immediately posts the realized revenue and the WIP. The legal general ledger reporting is up to date with the cost entry.

You write the market segment on both the cost line and the revenue recognition lines. A further settlement to profitability is obsolete. Here too, you already have the market segment reporting available with the cost postings.

The leads to the following benefits:

• No reconciliation efforts between different tables required
• Real-time reporting provided for all applications
• Simplified period-end close (no settlement required any longer)
• Enhanced reporting insights:
  • Drilldown is available for general ledger accounts like WIP by project and market segment.
  • Margin reporting is done on the original postings and general ledger accounts. In our example, the cost of sales is determined by the consulting hours, and the revenue is determined by the realized revenue and not by settlement accounts anymore.

Using this example, we want to draw your attention to another innovation: it’s now possible to store several controlling objects on one journal entry item. So, depending on the business process, the system can enrich journal entry items and derive additional account assignment information. We make a distinction between the following: 

• The real account assignment: There can only be exactly one per line. It is identified by the Account Assignment Type For example, KS stands for cost center, OR stands for order, PR stands for project, and so on. Follow-up processes such as surcharges, revenue recognition, and settlement can only run on the real account assignment.
• The attributed account assignments: These are only available for reporting purposes. There are no follow-up processes running on them. There can be several attributed controlling objects on one journal entry item.

In the example in this post, the posting on a customer project, the project is the real account assignment. You attribute the sales order item, to which the project is assigned, and the profitability segment, which you derive from the sales order information. There are also some additional scenarios to consider:

• Service order scenario: The real account assignment is the controlling object for service order items, new in SAP S/4HANA. You attribute the profitability segment based on information provided by the service order, like the customer and product sold.
• Intercompany scenario: You credit the cost center in the supplying company, which is the real account assignment, and attribute the project of the receiver company.

Editor’s note: This post has been adapted from a section of the book Controlling with SAP S/4HANA: Business User Guide by Janet Salmon and Stefan Walz.