What you should know about controlling in SAP S/4HANA. (Part 1)
(updated as of SAP S/4HANA release 1909)
As a controlling consultant I was very excited about the evolution of SAP ERP CENTRAL COMPONENT (ECC) to SAP S/4HANA.
Since the first release I was asking myself:
- Do we still have a “Controlling” concept in SAP S/4HANA or the Controlling part is evolving to a unique Finance concept?
- In the Universal Journal times in which direction the Controller knowledge should grow?
- Now that Universal Journal is the main source how should Controlling Reporting Transform?
The main aim of this blog post is therefore to reply to these questions trying to talk about SAP S/4HANA new concepts and to describe how these concepts have been evolved and are evolving.
With the advent of SAP S/4HANA many things are changed in controlling; I have prepared a list based on SAP S/4HANA 1909, (of course since the product is continuously evolving this list is not exhaustive).
This is a list of topics that I will cover in the first part of this post:
- Universal journal
- Realtime Integration
- Cost Elements
- CO Internal Postings writing in Universal Journal
- Evolution of SAP ECC Profitability Analysis to SAP S/4HANA Margin Analysis
- Predictive Accounting
- Cost Component Split/COGS Split and Product Cost Variances
- Statistical sales condition
- Attributed CO-PA
The universal journal is nowadays well known but to be honest when I saw the first description of the concept I was wondering what was the benefit for the final user.
I was able to understand and recognize the technical benefits contained in the Universal journal Concept like:
- Simplification of Tables, and Unification of Subleders (for example FI, CO, AA, ML)
- Elimination of totals Concept
- Amelioration of performances
- Elimination of differences in OLTP and OLAP concept
- Elimination of reconciliation between different ledgers (e.g. FI and CO)
but I was struggling on how to transform it in a tangible business advantage for the Controller.
At that time, having the possibility to see new SAP FIORI APPS on Universal Journal the it was clear to me that the FIORI would have been a perfect match. And as a matter of fact fact I could verify some FIORI Apps able to offer Controlling Reports like never in the past. For example the Market Segment FIORI app.
Please see also the FIORI topic in third part of this blog (when it will be ready).
Regarding Controlling part, one of the consequences of the Universal Journal is that total tables are not in place anymore and if you remember ECC most of the Controlling Reporting was based on totals tables. So how these reports are now working in SAP S/4HANA? There is a non disruptive compatibility view mechanism that ensure that the reports are redirected and continue to work. So as mentioned By OSS 2270404:
“The former tables COEP, COSP, and COSS are replaced by views of the same name, so-called compatibility views, that aggregate the data in the universal journal on the fly in accordance with the old table structures”
Old reports continue to work based on the universal journal tables, CO Fiori Apps are based on the universal journal as well, that means that as matter of fact your reporting source is now the Universal journal. But which part of the Universal Journal? This is really the question that a Controller should ask himself (and I will try to reply further in this blog post).
There is one example I like to show to my customers about elimination of tables and unification of subledgers. Everybody knows that Payable, Receivable, Assets, Controlling and material ledger are now in the same universal journal table (the ACDOCA table). That also means that the granularity of Finance postings has augmented; if you for example think about an asset purchasing you will have a row for each asset you are buying (and not simply by a G/L Account representing the asset itself). But the concept of Universal Journal is much more than a technical concept: having a single place where to find every information regarding for example the purchasing to pay process is extremely useful.
An example, a customer raises a purchase requisition and a purchase order to a project, materials are to be considered in this case as Capex Cost. The goods receipt Is therefore directed to a Wbs element, then the Wbs element is settled to an Asset Under Construction (End of the period) and then to a Final Asset (End of the internal Construction). After a while an Invoice is raised and then the payment is posted.
In ECC you had to probably create a custom report to keep together the information from purchase requisition to payment among different tables. With the Universal journal you can find every record in one single table. (Anyway, if you want to keep the documents related one to another you should go analyze the problem a little bit deeper, maybe the new document flow FIORI app may help you a bit on that).
So with the progression of SAP S/4HANA I found my way to the real business value for Controllers.
The Finance realtime integration, and before of it the Controlling Reconciliation Ledger were concepts used in ECC to keep aligned FI with CO.
For example one cross Cost Center CO posting belonging to different Profit Centers or Business areas or Company codes could create a misalignment between FI and CO. In ECC if you had an FI posting of 100 Euro on Cost center A (Profit Center A) and then a CO internal allocation from Cost Center A to Cost Center B (Profit Center B) as a matter of fact you would have Controlling reporting (cost center and Profit Center) not aligned with Finance Reporting.
Finance Reporting: Cost Center A (Profit Center A) 100 Euro
Controlling reporting: Cost Center A (Profit Center A) 0 Euro Cost Center B (Profit Center B) 100 Euro
If you had the requirement to have Finance and Controlling reporting reconciled (for example because your profit center represents your business segment and it should be always aligned in FI and CO) you could use the mentioned concept to realign FI with CO.
In other words, after the CO Allocation you could have an (only) FI posting like:
- – 100 Cost Center A
- + 100 Cost Center B
If the allocation was done on secondary cost elements you had the possibility to “represent” the Secondary Cost element with a specific G/L account in order to allow the posting in FI (by definition the FI posting could not be done on secondary cost elements).
In SAP S/4HANA, with the concept of universal journal, secondary cost elements are G/L accounts and every CO posting is represented in universal journal, therefore you do not need Reconciliation ledger or Realtime integration concept anymore.
Please note I am not talking about cross company clearing accounts, this has remained in SAP S/4HANA customizing as well.
The fact that cost element are now G/L accounts is also a known concept since a while. The fact of having the Universal journal suggested to have one single concept. That means that even if you are creating an internal positing in CO (e.g. CO internal allocation between two cost centers) you will obtain an FI document for it with an FI header (BKPF, not BSEG).
If you are concerned to have a challenge on separating the secondary cost element on your B/S or P/L structure you may want to know that there are ways to separate them from the primary cost elements.
The OSS 2841880 may help, it talks about Financial Statement Versions G/L Account Hierarchies Semantic Tags.
The definition of GL Account Hierarchies and Financial Statement Version helps in this way. You can assign primary and secondary cost element General Ledger Accounts to different Hierarchies to keep them separated for reporting and statutory purposes.
Sematic Tags helps on the creation on KPIs.
Anyway the total impact of secondary element is by definition zero (because you use them only to move costs from one cost object to another one) so you should not worry about them in total but only among Controlling objects.
If you put together the Universal journal concept (already explained) with the SAP trend to suggest the customers to use Margin Analysis based on the old Account Based CO-PA (that uses G/L Accounts instead of Costing based Value Fields) you may find the “marriage” of Cost elements and G/L Accounts as a simple natural consequence.
CO INTERNAL POSTINGS WRITING IN UNIVERSAL JOURNAL
With Universal Journal concept CO Postings are written in the Universal Journal table (ACDOCA).
To write on this table you need some basic concepts:
- Document Type. Even CO internal Postings are now written on document types (As per the FI documents). Potentially you need to choose one document type for each CO Business transaction. If you think about the Realtime Integration Concept explained previously the reasons why you need a document type should now be clear.
- Assignment of CO Version to the leading ledger or to every ledger. If you think about the new ledger concept like a way of grouping your P/L and B/S for internal and external (e.g IAS, US GAAP) reporting purposes you may find this possibility very interesting.
Basically you have the option of recording some of your postings in specific ledger group and to dedicate even CO postings to obtain an alternative Profit and Loss. Even with the new Universal Allocation you can run Allocation cycles by ledger. Moreover you have the possibility of executing CO specific postings (for example manual re-posting of cost) per ledger group. So manual or automatic allocation of costs may be a good way to start doing posting per ledger (accounting principle).
EVOLUTION OF SAP ECC PROFITABILITY ANALYSIS TO SAP S/4HANA MARGIN ANALYSIS
With the advent of Universal journal SAP suggests to use the Margin Analysis evolution of Controlling Profitability Analysis.
In ECC there were 2 types of CO-PA
- Costing Based (based on separate ledger and using Value Fields)
- Account Based (integrated with G/L Accounting and using G/L Accounts )
(Actually for specific customers, there was also a third type of Profitability Analysis called “Combined” but this is now of not allowed anymore in SAP S/4HANA )
Most of customers who used Profitability Analysis opted for Costing Based cause it was much powerful and very integrated with Product Costing. For example it allowed the use of Valuations to import in CO-PA Sales Order Statistical Conditions, moreover it had functionalities to import COGS split into CO-PA Value Fields.
Being based on Value Fields (and not on G/L Accounts), writing on different tables, and sometimes not completely aligned with the General Ledger Document postings (for example Goods issue) Costing Based CO-PA was therefore not easily reconciled with General Ledger.
Following the integrated approach of the Universal Journal, SAP decided to use the integrated ECC Account Based CO-PA as a base to build the new SAP S/4HANA Margin Analysis. Margin Analysis concept became a new Version of Account Based CO-PA improved in the Universal Journal. Costing Based CO-PA can still be used in SAP S/4HANA but Margin Analysis will be the only solution improved by SAP
The fact that you now have characteristics in Universal Journal actually means that whatever characteristic you may want to create in your detailed P/L (for example Customer, Market Segment, Product Group and so on) you will be able to see this characteristic in your universal journal table ACDOCA as a column.
At the beginning this option to go for Margin Analysis was not easy to adopt for CO-PA Costing based customers cause, as previously mentioned, Costing Based CO-PA offered more functionalities; but then, release by release, SAP improved the Margin Analysis in the Universal Journal with new functionalities. Nowadays these improvements and new developments have transformed Margin Analysis in a very better solution.
Let’s see a comparison table:
As you can see most of the gaps between Costing Based CO-PA and Margin Analysis have been closed and most important, reconciliation with Finance is integrated in Margin Analysis but not in Costing Based CO-PA. You may object that even in the ECC the Account Based CO-PA was integrated with G/L Accounting but despite that, many customers chose Costing Based CO-PA. On the other hand you must admit that these customers did not have universal Journal in ECC and most important, that in terms of functionalities Account Based CO-PA is less powerful than Margin Analysis.
Having a look to the comparison you may see that some of the features (e.g. Statistical Sales Conditions or Incoming sales order) are realized thanks to the possibility of writing new rows in the Universal Journal on Extension Ledgers. If you stop to think for a minute about the concept of posting on a parallel ledger in ECC you may think of something belonging to Financial on a specific Financial table (BSEG or FAGLFLEXA). Now it is instead an Universal Journal posting and depending on which fields are filled you may want to consider them for Controlling as well, so they are to be considered as controlling postings.
An implication of that is that you will not find them on the classic SAPGUI reporting but only in FIORI.
Let’s take in consideration the Predictive Accounting concept.
The Idea to have in a dedicated part of P/L Sales and Purchasing Orders in real time, before they become an actual posting may help customers to anticipate their month end closing and reporting.
You have the possibility to bring in SAP S/4HANA Sales and Purchase orders in a specific ledger and to obtain automatic reversals of these postings once the related Financial documents are posted.
This is what SAP calls “Bottom Up Predictive Accounting” and it is clearly explained at this link
The good thing about predictive accounting is that the “predicted postings” are automatically synchronized with the actual postings.
How many customers were in the past “simulating not posted goods receipts or goods issues (or even not posted invoices) as a part of the month end closing procedures to reverse them at the beginning of the following month? (I know some ECC customers doing that even in FI-SL Special Ledger).
Thanks to Predictive Accounting this in now over. Someone may object that having predictive postings is not the same to have financial postings and that financial posting may be different from what they were supposed to be in the Orders; well this may be true, but it is also true that we are talking about prediction, so in my opinion it is much better to insert a prediction in a P/L than to have nothing.
Please be aware that as of SAP S/4HANA release 1909 Predictive accounting related to Sales orders has limitations:
Again, would you as a controller consider these postings as a value added? I would.
Were these postings considered as standard in ECC? Maybe yes but in a specific separated not finance integrated reporting (in Costing based CO-PA).
Is it useful to have them in the Universal Journal with other actual postings even on a separate section of it on Extended Ledger? I would say yes.
COST COMPONENT SPLIT/COGS SPLIT AND PRODUCT COST VARIANCES
If you think at the differences between Account Based and Costing based CO-PA in ECC with regards to COGS split it was mainly a question of:
Costing Based CO-PA
- Simulation of Material Cost (Fix and Variable) at the time of Sales Document
- Production Cost (Fix and Variable) at the time of sales Invoice
Accounting Based CO-PA
- Cost of Sales at the time of Goods Issue
The Costing Based CO-PA advantage was to have Material and Productive Cost split by Cost Components related to CO-PA Value Fields.
In Margin Analysis as per OSS note 2349278 “Cost of goods sold (COGS) postings are assigned to an account/cost element at the time of the goods issue from the warehouse”. New functions are available to split the COGS posting to multiple accounts in accordance with the relative weight of the assigned cost components. This split can be updated with the results of actual costing from SAP S/4HANA 1809”.
You can use a new customizing to put in relations Cost Components to G/L Accounts, in this way you can obtain the split when you post a goods issue in Margin Analysis. Cost components can be valuated at standard and since 1809 at Actual Price too.
The same it is relevant for Product Cost Variances (product variance split)
So the ECC gap of having Costs in CO-PA reconciled with Accounting at the time of Goods issue is now covered by Margin Analysis.
STATISTICAL SALES CONDITIONS
Another Costing Based CO-PA functionality is the possibility to calculate statistical sales conditions (e.g related to warranties or freight cost) that are in SD Order but are not part of the Sales Invoice. Those costs are calculated internally and brought to CO-PA Characteristic even if not calculated in Finance and debited to the customer (at least not directly). From SAP S/4HANA release 1809 it is possible to transfer these statistical sales conditions in an extension ledger and to have them in Universal journal.
ATTRIBUTED MARGIN ANALYSIS
Attributed Margin Analysis is a new way to derive Profitability Segment Characteristic in Universal journal even without executing manual activities. One possible example is to obtain the characteristic filled for a posting on a Wbs element that has settlement rule to CO-PA characteristic. If the settlement rules are properly compiled, a simple posting on the Wbs element will feed the Margin Analysis Characteristic as well without the need of executing the settlement itself. The Posting Controlling Object will still be the Wbs element but the characteristic fields will be filled in parallel. This process is of course not just limited to the example I have made and I think it is a very clear example of new functionalities we may find in SAP S/4HANA.
To have a more detailed description of what is included in Attributed Realtime Margin Analysis you can have a look to this blog as well brought to you by the RIG.
So to say some conclusive words on Margin Analysis, nowadays I think that apart from very specific functionality the Margin Analysis is now a suitable solution for customers. Main reasons are:
- It is integrated into the overall concept of the Universal Journal
- It has been extended broadly over the past releases
- It is fully aligned with SAP Financial Accounting development strategy and SAP has the intention of conducting new developments in this area only.
When you think about Controlling in SAP S/4HANA you really need to mention other parts beside what I have already talked about, topics like Universal Allocation, Material Ledger, Reporting (FIORI), Planning Processes are fundamental.
I will try to use the second part of this blog to give a complete reply on the initial questions I raised at the beginning. To give anyway some preliminary conclusion, I think that the Controlling Consultant role will continue to be necessary, but consultants need to expand their knowledge to new arguments (and I think I have already mentioned some in this first post).
Moreover, the universal journal table (ACDOCA) is central and it should be learned by the controlling consultant.
In the third part of this blog post I will also describe how the controlling Reporting has evolved to FIORI.
What do you think?
Anyway if you want a step by step guide to CO tasks I suggest to read this book
Brought to you by S/4 HANA RIG
Will you also discuss the planning/budgeting in S/4?
Thanks a Lot !
Hi Sorry I did not see you question, regarding planning I will try.
Regarding budgeting and availability control functionalities you may refer to this other blog
Excellent document. However a small correction I.e COEP table was not replaced by CS views. Only COSS and COSP only replaced by CDC views.
COEP is continuing as it is even in S4Hana.
Thanks for your comment, you may be right but if you need to read it you need to go to V_COEP_VIEW.
Please read OSS 2335210.
Really interesting.....nice document. Thank you sir. Half of the document completed reading. Really helpful
Thanks a lot!
GT - Very interesting analysis of controlling in S/4. More so around (COPA ) margin analysis. How does this play out in Central Finance where feeder systems are on either CB copa or AB copa?
PR - This blog is not about Central Finance.
If you want to go in a deeper detail on Central Finance I strongly recommend this blog https://blogs.sap.com/2020/02/14/different-views-on-what-is-central-finance/
You will find the reply to your question in this blog.
Please see specifically the part:
Replication from costing-based CO-PA in source: SAP Note 2184567, question #17
A transfer occured for a cost estimate with the same key. In other words, there's already a cost estimate for the material in the same walmartone period with the same costing type, costing variant, and costing version. This problem generally occurs if you create multiple costing runs in teh same period.
I am sorry i am not sure I have understood what you wrote, would you please articulate it?
Excellent, Explanation on changes in S4 Hana controlling, Thank you GIANLUCA TACCONE...
thanks for your explanation , what about sap actual splitting cost in s4hana & ecc behavior ?
Dear Ibrahim ,
what about it? 🙂 This is always the questions I raise to customers (just a joke btw)
So I am not a splitting expert, but things are similar so if you were in ECC with NEW GL with splitting in ECC and you convert to S/4 you will find the same situation in S/4.
Otherwise if you were not in NEW GL in ECC you will be in NEW GL in S/4 but with basic NEW GL functionalities (e.g. no splitting)
You cannot activate splitting in a normal Conversion to S/4 HANA, you usually need to convert and then activate document splitting as a separate project.
I have recently heard (but I am not completely sure about that! So no commitments!) That in some specific brownfield approaches that uses Data Management and IT landscape Transformation Services SAP will start to provide the Splitting Scenario during Migration)
Nice post. A lot new things it seems. However as a Group Controller, I have 2 Qs:
I assume the for PC you mean Profit Centers.
Profit center are completely integrated in S/4 as they were in ECC New-GL. So if you decide to use them, you can have a Profit Center for each P/L item and with Document Splitting you split the B/S part per profit center as well. Or maybe the splitting and B/S part can be kept at segment level Segment can conceptually be assigned to many profit centers .
Please be aware that Business Area is still there, it is not gone so if you do not want to use profit centers in theory you can.
If you want instead to setup a Profit center at BU level you can, it is up to you to decide the granularity you need on assignments of Profit Center to Cost Objects (Cost centers, Orders, Wbs, Profitability segment and so on).
Thanks for your reply. It is well appreciated. Yes, PC = Profit Centers
The problem with using PCs ( for more granular level) is ful balancehseet can not be derived even in S/4 I guess. There are many postings that would not be able to identify itself which PC it belongs to. ( A huge portion of Raw Materials are common to many product lines, so unless they are consumed into specific SFG, or FG you may not be able to report Inventory of such raw materials to specific PC
Again, everything can not be document split ( equity, RE, or some provisions , Patents etc). So naturally no scope of matching the balanced B/S.
I do not know how oen can allocate a lot of B/S items that are really common to organisation legal entity. It would be pure allocation to get a full B/s on PC level.
But great to have your insights. S/4 is making life easy, it seems.
Really impressing blog , very useful one.
May i know details of Part2 of this blog 🙂 🙂
Thanks & Regards
It is includedin the hyperlink on the conclusion part of this blog. Anyway this is the link https://blogs.sap.com/2020/08/04/what-you-should-know-about-controlling-in-sap-s-4hana.-part-2/
Great Blog. Thanks for sharing.
Hi Gianluca, very good job!!!!
Thanks for the article. Can we do cross controlling area allocations using Project System/ WBS?
Very nice and very informative.
My customer is asking for multilevel product hierarchy, say 7 levels, for BOM, Pricing and Management reporting. WE are using S/4Hana onprem.
I read some article about one app in S/4Hana cloud
Manage Product Hierarchy Assignments” (App ID: F4240) - Is this feature available in S/4 Hana OP?
Please reply or send some links
Introduction to Product Hierarchy in SAP S/4HANA Cloud | SAP Blogs