With the introduction of SAP S/4HANA, SAP aims to resolve the disadvantages and problems of profitability analysis in SAP ECC. Therefore, the introduction of SAP S/4HANA resulted in many changes in profitability analysis. Previously, account-based profitability analysis was only available with a few functions. As the focus in SAP S/4HANA now shifts to the account-based profitability analysis and relies on the Universal Journal as one single source of truth, Margin Analysis is now more transparent, easier to use and meets the requirements for efficient management reporting. However, cost-based profitability analysis is still applicable in SAP S/4HANA, but not recommended. The greater reconcilability between the formerly separate FI and CO modules is one of the biggest advantages of S/4HANA within Margin Analysis. Through the usage of the Universal Journal, a 1:1 view is now provided for the data as only one table (ACDOCA) is the source for reporting purposes (single-source-of truth). Therefore, report creation with S/4HANA is now way faster while multi-dimensional views are possible.

Rentabilitätsanalyse im Universal Journal enthalten (Tabelle ACDOCA)

The new opportunities in S/4HANA make the Margin Analysis more powerful and reliable which is why managers should not miss out on it. However, some pitfalls could lead to failure and result in an inadequate usage of the new possibilities. With our experience, we recommend decision-makers strategically approach the conversion. When setting up a margin analysis, particular attention must be paid to three things. Margin analysis must be aligned to the steering model and value flows must be aligned with the P&L statement. It is, therefore, crucial to consider steering principles and derive design principles. In addition, companies must deal with cost-accounting costs which used to run as one value-flow into CO-PA. Also, sales deductions such as rebates or bonuses must be coordinated specifically.

Before migrating an existing SAP solution to S/4HANA or implementing it from scratch, companies face the challenge to choose the adequate deployment option that best fits the business needs and process landscape. While in the former SAP ERP system the On-Premise solution was more or less the only way to go, this shifts with SAP S/4HANA. Companies now can choose out of three deployment options that all have their specific benefits and might be reasonable to use depending on the company’s requirements: the On-Premise version and two cloud versions, one as a private cloud and one as a public cloud.

Deployment options for SAP S/4HANA

SAP S/4 HANA Public Cloud is an ERP-solution with standardised applications based on best practices. Standard processes, little to no customization; therefore, easy to set up and start working. Little ambiguity how a process should be designed. Companies have to stick to the standard, therefore not much personnel is required to maintain the system and to custom the solutions.

In contrast to the public cloud, the private cloud edition is a hybrid form of both the cloud and On-Premise solution of SAP S/4HANA. Therefore, code modifications are possible and full IMG access is available. Companies can design processes more freely; they can adapt their ERP-processes more to their operational processes.

The On-Premise solution of SAP S/4 HANA offers the full spectrum of ERP-functionalities: flexibility in process design, customizing (full IMG) available, developments and source code modifications possible, and interface-management. This solution is managed with an own data centre or by a third party.

The complexity of business functions and the increase of functional costs is a steering relevant issue in numerous companies. The consistent usage of SAP functional areas can support this important business control topic. Basically, a functional area is an assignment characteristic in SAP that breaks down revenues and operating expenses by function to fulfil the requirements of cost of sales method for external and/or internal P&L. From the legal perspective such as IFRS or local GAAP the use of functional areas as revenue, COGS, selling cost, general administration and other operating income/expenses is sufficient.

However, detailing these functional areas according to relevant corporate steering requirements would increase the information content and enable further control options for both functional costs and internal P&L. While in SAP ECC cost of sales method required a special ledger, with S/4HANA all data is completely integrated in the Universal Journal (ACDOCA). Hence, total-cost-method and cost-of-sales-method can be organized in parallel in Universal Journal.

From a business management perspective, functional cost controlling is a part of operational controlling and includes the planning, control, and cost management of business functions such as IT, Marketing or HR. In many companies, the controlling of these functions is becoming more important because of higher complexity of corporate functions and increasing functional costs. But at the corporate level, there is often a lack of functional cost transparency, for example, due to decentralized management or inconsistent functional cost definitions. Hence, a structured and system-based functional cost controlling systematic could be valuable.

Generally, vital goals can be pursued with functional cost controlling. It helps companies to create a central and accountable cost control of global functions from a corporate perspective. Uniform, comprehensive, and consistent data structures and value flows contribute to standardized and consistent reporting of functional costs. Thus, companies have potential to increase cost efficiency.

To present the functional costs of a company more transparently, it is advisable to use functional areas in SAP S/4HANA as an instrument of functional cost controlling to present steering relevant functions. Structuring functional costs by these functional areas forms the data basis for active functional cost controlling and benchmarking. For this purpose, all controlling objects of the company must be clearly assigned to the functional areas. This applies to all cost centres, internal orders, projects, production orders, service orders, and customer orders. It is crucial that the objects only carry the values that relate to the assigned functional area, i.e., that they belong to the specific function. If, for example, a marketing cost centre also carries IT costs, these costs must be as allocated to a functional IT cost centre. Obviously, a rearrangement of the booking material is a necessary change within a functional cost controlling approach by functional areas.

This structuring ensures a consistent and transparent functional cost view. Only in this way the functional costs of the steering relevant functional areas, as divided into IT, marketing and HR in the following figure, can be presented transparently across several organizational and legal units. Thus, the functions can be managed from a group perspective. Functional cost information can be reported on a standardized basis, time consuming ad-hoc analysis is no longer needed.

Functional costs in functional areas

SAP Analytics Cloud (SAC) is a software as a service (SaaS) solution from SAP. It combines business intelligence, predictive analytics as well as planning in a public cloud environment. With SAC, SAP is attempting to merge the heterogeneous reporting applications and front-end tools into one central tool. The SAP Analytics Cloud can be seen as a stand-alone solution that provides a broad portfolio of functions for unified reporting and integrated planning that can run independently from SAPs ERP systems. With SAPs focus on SAC as the main analytics tool, they try to simplify their portfolio of analytical solutions. Also, SAP continues to promote the hybrid use of On-Premise and cloud solutions. For example, companies that use SAP S/4HANA On-Premise can still use SAC as an analytics tool.

Architecture of the SAP Analytics Cloud

The analytics platform runs either on SAP owned data centres or in data centres of Amazon (AWS). As aforementioned, SAC supports hybrid solutions and hence, integrates with various solutions from other cloud providers as well as with certain On-Premise solutions. However, live connections are limited to SAP solutions like SAP HANA, SAP Business Warehouse or SAP BPC. Moreover, in contrast to other BI tools, e.g., Power BI, SAC allows the write back of data from other SAP sources.  Besides, import connections allow a wider range of data sources, e.g., Microsoft Excel or Google Drive. Since SAC is provided as a comprehensive package, the core functionalities such as data modelling (which is the basis for other functionalities), data wrangling or visualisation cannot always be clearly assigned to individual analytical areas such as business intelligence or planning. Rather, most of the functionalities can be found in all workflows but are used in different ways.

Many companies have previously invested in SAP BPC and are therefore confronted with the question of whether it makes sense to use SAP Analytics Cloud in addition. In fact, it makes business sense to combine the existing planning landscape in SAP with planning in SAC, as it offers new opportunities through functions such as value driver trees, which should not be missed from a business perspective. However, there are some key points to consider before doing so.

However, in our opinion, the greatest strength of SAC lies in its planning function. It unifies both operational and financial planning and offers new possibilities through features such as Machine Learning. Moreover, the SAP Analytics Cloud supports the adequate allocation of resources within the planning through built-in collaboration features.

Group companies may have different accounting standards (group accounting standards, local accounting standards and tax accounting standards) and must be able to represent these. In former SAP versions, there were different approaches to meet these requirements.

With the implementation of SAP S/4HANA, it is possible to map parallel accounting in General Ledger Accounting by maintaining several parallel ledgers according to different accounting principles. For the financial statements, the relevant accounting principles are mapped in the leading ledger or the local ledgers. A ledger is a centralized collection of accounting data. In addition to parallel ledgers, extension ledgers are also introduced as a new feature in S/4HANA. Extension ledgers offer functionalities that can be used for management reporting to adjust or add data in spreading the standard ledgers without editing the data from the underlying ledgers.

To be able to keep several parallel general ledgers in general ledger accounting, for example to balance according to several accounting principles, a ledger is created for each of the legal requirements. At group level, for example, a company prepares its accounts for all company codes in accordance with IFRS in a so-called leading ledger, while the individual company codes prepare their accounts in compliance with their local accounting standards, e.g. US GAAP or HGB, in the non-leading ledger.

In the standard S/4HANA system, ledger 0L is the leading ledger and exactly one ledger must be identified as such. This ledger is updated in all company codes and the settings (currency, transaction variant, etc.) are transferred for each company code.

The non-leading ledgers can exist alongside the leading ledger and are managed as parallel ledgers based on local accounting principles, for example. A posting can be made to all ledgers, to multiple ledgers, or to a single ledger. For an additional parallel accounting rule, another non-leading ledger can be created in the general ledger.

Parallel accounting in SAP S/4HANA

To display the different valuation areas per accounting principle – and thus per ledger – each ledger must be assigned to its own ledger group.

The advantage for parallel accounting in SAP S/4HANA is the manageable number of G/L accounts, since a separate ledger is maintained for each accounting standard (IFRS, HGB, etc.). Thus, different business variants can be mapped with this solution approach. In addition, separate reconciliation of Asset Accounting with the General Ledger is no longer required, since all acquisition postings generated by the system are posted directly to the General Ledger (to the same ACDOCA table).

In addition to the standard ledgers, SAP S/4HANA offers extension ledgers as a new function. There are three possibilities to use these ledgers. The first possibility is the type “extension ledger”. Here, no full scope of all posting records can be made, but only additional postings. Only manual postings are possible. The extension ledger can therefore be used for manual supplementary postings from Controlling to the Financial Accounting module e.g., if the posting month or fiscal year has already been completed in the standard ledger and the posting periods there are already closed.

In addition, there are two other extension ledger types for different applications. The extension ledger type “simulation” is an extension ledger and works similarly to a “test mode” run. This ledger type is used to apply simulation functions for example as foreign currency valuation. The last extension ledger type “prediction and commitment” allows posting sales orders (before delivery or billing) in the Universal Journal, to support sales and profitability forecasting (which is traditionally done in costing-based Profitability Analysis using record type A). This ledger can also be used for purchase order commitment management.

Even though SAP offers sophisticated and comprehensive Business Intelligence (BI) solutions (e.g., SAP Analytics Cloud), many organisations still heavily rely on Microsoft Excel in their day-to-day business. On top of this, Microsoft offers an additional tool within its Office 365 package that goes beyond the capabilities of Excel: Power BI.
Power BI is one of the fastest-growing BI platforms and offers possibilities in analysing data that go beyond those of Microsoft Excel.

Architecture of Microsoft Power BI

Power BI: The leading self-service BI tool?
In general, BI tools are characterized by easy-to-use self-service functionalities that support a full analytic workflow: From data preparation to data visualization and insight generation.
One key benefit of Microsoft Power BI is its alignment and integration with Office 365 and Microsoft teams. As these platforms are used by millions of users every day, Power BI has gained and will further gain tremendous reach in the business world.

How to integrate Power BI with SAP S/4HANA
Power BI can be integrated with SAP HANA database via “ODBC” driver and with SAP BW database via “.NET driver.” In both ways, either a direct query connection or import mode connection is possible.
Also, companies that run their SAP system in a cloud can still use Power BI as their analytics tool independent from the cloud provider. All they need is an Office 365 license to connect to Power BI and to the Microsoft Cloud.

This blog article illustrates that Power BI is a powerful BI tool that is particularly attractive because of its connection with Microsoft Excel and its relatively low operating costs. Moreover, the article shows how an integration with an SAP landscape is possible and therefore, Power BI should also be considered as a business intelligence tool for companies with an SAP landscape.

In general, planning in SAP is mainly related to two fields of action: logistics and financial planning. Both interact with each other when it comes to “demand planning” in logistics and “sales and revenue planning” in financial. Moreover, the graphic illustrates that the backbone-heavy planning functionalities, e.g., MRP runs, are still located in S/4HANA.

Planning Areas

With the introduction of the Universal Journal in S/4HANA, the ACDOCP table should serve as a single source of truth for plan data. The following graphic shows the overall planning architecture for financial planning in S/4HANA:

Hybrid planning with SAC and S/4HANA

The graphic shows the interaction between the SAC planning operations and SAP S/4HANA planning functions. In this case, SAC only functions as a front-end planning tool with the collection of plan data. Complex and algorithm-based planning functions, e.g., planning based on bills of material, still require the use of SAP S/4HANA.

Product cost controlling (or product costing) is an essential task of corporate management to create manufacturing cost transparency and efficiency. Since product costs and consequently corporate profits can be influenced by an effective product cost controlling, it is very important for businesses to manage product costs by steering manufacturing cost structures, production deviances contribution margins or losses, among other things.

SAP product cost controlling consists of two components: Product cost planning (cost estimation) and cost object controlling. Both pillars of SAP product costing will be described in more detail in the following.

SAP Product Cost Planning is the essential part of product costing

The starting point of SAP product costing is the order-neutral product cost planning. Aim of this component is to estimate product costs from a single assembly or finished product to the whole product range of all plants of a company. You can calculate the cost of goods manufactured (COGM) and the cost of goods sold (COGS) and structure them by customized cost components according to a manufacturing view and/or a primary cost view to get a deeper insight into origin and type of the product costs. The basic building blocks of the product cost estimates are bill of materials, routings, activity type rates and surcharge rates by cost centres. You can imagine that data quality of these building blocks is from essential importance for the information value of cost estimation. Therefore, product costing approaches always must commonly be elaborated between overhead cost controlling, production controlling and supply chain department.

Cost object accounting provides product cost controlling information on an order level

Alongside product cost planning, cost object accounting forms the second complex of topics in product cost controlling. While product cost planning delivers article-based cost estimates, the focus of cost object accounting lies on the controlling of production cost units. Which cost unit is used is dependent from the specific production environment. For shopfloor manufacturing the controlling object is the production order, for serial or batch production controlling takes place on the product cost collector and in make-to-order the cost object is usually a customer order or a customer project. Common for all types of cost object accounting is the determination of costs at different points during production process and the calculation of the resulting cost object deviations. Cost object controlling includes preliminary costing, concurrent costing, and final costing. Usually, a preliminary cost estimate is made to determine the planned costs of a cost object at the time the cost object is created. Planned costs are the target costs calculated for a specific order in relation to the corresponding planned quantity. Concurrent costing allows you to view and analyse the actual costs of individual cost objects at any time, even before the cost object or period is closed. The final costing of a cost object is performed during the period-end closing process. After final costing full actual costs are allocated and can be compared with the target costs to perform cost analyses and deviation analysis, among other things.