Overhead Accounting with Universal Parallel Accounting in SAP S/4HANA 2022
Continuing the blog series on Universal Parallel Accounting I will now look at the topic from the point of view of Overhead Accounting. If you haven’t already read it, please refer to Sarah Rössler‘s excellent introduction to the topic: Universal Parallel Accounting in SAP S/4HANA
While it was possible to use several ledgers in General Ledger Accounting in SAP ERP, only the values in the leading ledger were transferred to Controlling. This changed with the introduction of the business function “parallel cost of goods manufactured” with SAP ERP Enhancement Package 5, but this was not the pure ledger approach used in Universal Parallel Accounting and involved significant mapping to link the various financial applications. With Universal Parallel Accounting we introduce a pure ledger approach, where the ledger is used consistently in Asset Accounting, Controlling and Actual Costing in addition to General Ledger Accounting. In this blog, I’ll explain the value flows in Controlling and how these pave the way for the calculation of ledger-specific contribution margins.
End-to-end Value Flows in a Ledger-Based Approach
Before we look at the implementation in detail, it’s important to understand the difference between primary costs (those costs entering Overhead Accounting from outside the organization) and secondary costs (those costs that are allocated from one cost object to another) when it comes to parallel accounting requirements. External revenues will typically be the same irrespective of the accounting principle, but primary costs can vary, and you will often find different approaches to asset depreciation depending on the local requirements and different ways of creating provisions for pension rights and similar. In the past these differences were often reflected in adjustment postings if the differences were significant. With these costs we have potentially different inputs into Overhead Accounting. In the case of secondary costs, we are passing the collected costs from the senders to the receivers in subsequent processes, such as activity allocation and settlement. The different inputs will then require a separation of outputs by ledger to ensure, for example, that the activity rates reflect the different depreciation rules for the asset and that the project costs are cleared cleanly during settlement. Where the collected costs are capitalized as assets under construction or the acquisition costs of a finished asset, you will often find different approaches depending on what part of the collected costs can be capitalized. The double flow that is made possible with Universal Parallel Accounting is illustrated in Figure 1.
Starting on the left we are collecting costs on a WBS element or maintenance order and settling to an asset on completion of the building or maintenance work. The different acquisition costs or repair costs would show as two flows onto the asset. From SAP ERP Enhancement Package 7 this distinction was possible if you used the business function “parallel cost of goods manufactured” but involved a mapping between the ledgers and a CO version, rather than a pure ledger approach. It is also common to distinguish the type of costs that can be capitalized depending on the accounting principle.
The collected costs flow from the asset to the cost center via depreciation. With Universal Parallel Accounting it is no longer necessary to choose a single asset valuation for the purposes of cost accounting, since you can handle each approach via the different ledgers. From SAP ERP Enhancement Package 5 this distinction was possible if you used the business function “parallel cost of goods manufactured” but involved mapping the depreciation areas in Asset Accounting to the various CO versions. This changes with Universal Parallel Accounting, as Astrid Hilgenberg explains in detail in her blog: Asset Accounting with Universal Parallel Accounting.
Once collected on the cost centers the costs can flow to other cost centers, orders, WBS elements, and so on via an allocation or overhead calculation. With the business function “parallel cost of goods manufactured” you could reflect the second flow as a CO version, but with Universal Parallel Accounting the allocations have been adjusted to work by ledger, meaning that the period close transactions in Overhead Accounting now select and post with reference to a ledger.
When it came to manufacturing, the ledger was not considered by the production orders or for inventory management in SAP ERP. There was one set of values on the production orders to be used as a basis for variance analysis and one standard cost by material. The exception was in Actual Costing where it was possible to use “parallel cost of goods manufactured” to bring the different activity rates into Actual Costing and from there to Margin Analysis. With Universal Parallel Accounting, this changes and all postings to the production order and Margin Analysis reflect the ledger and you have ledger-specific values for work in process and production variances, provided you shift to the new event-based posting logic.
Figure 1 includes the codes for the scope items that were originally delivered with SAP S/4HANA Cloud. You can use the same scope items in SAP S/4HANA private cloud or on premise to accelerate your implementation. Bear in mind, however, that some familiar business transactions have not yet been adjusted to deal with the parallel ledgers. Where a transaction has not been enabled for use with Universal Parallel Accounting it has been removed from the SAP Easy menu when the business function “Universal Parallel Accounting” is active. SAP plans to enable missing transactions over time.
Impact of Universal Parallel Accounting on Settlement
The description so far might make it sound like Universal Parallel Accounting is simply the ability to include the ledger in all Controlling transactions, but the changes go further because Universal Parallel Accounting also allows you to work with different fiscal year variants, depending on the ledger and to include up to ten currencies in each ledger.
To understand the benefit of the move to Universal Parallel Accounting for settlement between CO-objects, market segments, assets, and so on, let’s look at a simple example (see Figure 2). Until now, the values to be settled were copied from the leading ledger (0L) to any additional ledgers, resulting in balances being left on the project in any additional valuations (ledger 2L, here) and an incorrect value on the receiver in the second ledger. With Universal Parallel Accounting, by contrast, the two sets of values are handled completely independently and the values on the project are cleared properly and the assets under construction are capitalized correctly in each ledger.
The need to handle multiple fiscal year variants was often the reason that customers chose to work with several controlling areas in the past, because the fiscal year variant was one of the settings in the controlling area. With Universal Parallel Accounting you can work with a different calendar, such as January to December, in group GAAP and a country-specific calendar, such as April to March in local GAAP, as shown in Figure 3. Here we see the situation without Universal Parallel Accounting, when the settlement values were simply copied from ledger 0L to 2L (as before). By contrast, with Universal Parallel Accounting the settlement rule is assigned to the ledger and can thus take account of the different calendars. When you run settlement in July, settlement takes account of the different fiscal year variants, and uses the settlement rule for period 7 in the global GAAP and for period 4 in the local GAAP.
Where the values to be settled on the project are in multiple currencies, the problem is exacerbated, as the values are copied to the second ledger and then converted into the additional currencies. In Figure 4 we see that with Universal Parallel Accounting the values in each currency are settled column-by-column and are not converted.
Value Flows in Detail
We’ll now walk through the various processes to explain the differences caused by the introduction of Universal Parallel Accounting.
Allocations are used to move costs from one cost center to another or from a cost center to a market segment and SAP offers a new solution for managing and running the allocation cycles. There are many more reasons to go to Universal Allocation than can be described in this blog, but the main reason to make the move from the perspective of Universal Parallel Accounting is that only Universal Allocation is ledger-enabled. You can define and run allocations per ledger or for multiple ledgers. You can also apply an allocation rule defined for a specific ledger to other ledger(s) by using the flexible ledger cycle flag.
You will need to use the Manage Allocations app (F3338) to create the cycles for your cost center allocations, profit center allocations, allocations to Margin Analysis and intercompany allocations (all are available in the same app, but you must choose the appropriate context). You can then use the Run Allocations app (F3548) to run the allocation each period. On completion you can use the Allocation Result app (F4363) shown in Figure 5 to view the result of each allocation. Notice in this case that separate allocations have run in ledgers 0L and 2L. You can also display the allocation results graphically using the Allocation Flow app (F4022).
It is beyond the scope of this blog to describe the full functionality of Universal Allocation, but you can find more details about the rational for the move and functional scope in Daigo Imai‘s blog: Universal Allocation in SAP S/4HANA 2021
Universal allocation can be used as an alternative to the classic transactions for cost center distribution (transactions KSV1-5), cost center assessment (transactions KSU1-5), periodic reposting (KSW1-5) and assessment to CO-PA (transaction KEU1-5). As you approach an implementation, be aware that there is not yet an equivalent for indirect activity allocation (transactions KSC1-5) and the predistribution of fixed costs (transaction KSFX) and so these transactions are disabled if you work with Universal Parallel Accounting.
You can also allocate costs between cost centers or to orders and projects using a direct activity allocation. Direct activity allocations rely on the definition of a cost rate per hour of work performed. The cost rates for these rates were previously stored in table COST and maintained manually using transaction KP26 or calculated using transaction KSPI, but this changes with the activation of Universal Parallel Accounting. The cost rates are stored in a new table, ACCOSTRATE, and you will no longer be able to maintain them using transaction KP26 but must rather use the Manage Cost Rates – Plan app (see Figure 6) to create your initial rates and Manage Cost Rates – Actual app to manually update actual rates. You can choose whether you create different activity rates per ledger if the differences between the rates are significant or you can work with ledger-independent activity rates to simplify the planning process. If you want to have the system calculate the actual activity rates, Transaction KSII can calculate actual rates per ledger. These can then be assigned to inventory via the actual costing run (Transaction CKMLCP) at period close.
As you think about Universal Parallel Accounting, remember that direct activity allocations can also take place across company code barriers. The activity rate can represent a transfer price with internal mark-up in the legal valuation views and an at cost view in the group valuation view.
Universal Parallel Accounting does not currently support the use of cost component split for the activity rates. It also does not support the used of business processes (transaction CP01-3) as an alternative to the combination of cost center/activity type or template allocation as a more dynamic method of triggering direct activity allocation.
Overhead calculation is ledger-enabled in so far as the base values are ledger dependent, but the percentage rate to be applied via the costing sheet is the same in each ledger. The costing sheet does not change with the new approach, you will no longer be able to use the classic transactions to post overhead but must rather use the new apps.
In the context of Universal Parallel Accounting there are two types of settlement:
- Settlement to CO-objects, market segments, G/L accounts, assets (supported)
- Settlement to materials (new event-based approach)
We looked at the benefits of the first type of settlement above. There is a change to the configuration in that the settlement profile includes a flag in Currencies/Ledgers that activates ledger-specific settlement (see Figure 7). In addition, there is an option to create ledger-specific distribution rules, if costs need to be capitalized differently depending on the accounting principle of the receiving asset.
Universal Parallel Accounting does not support settlement to material (WIP, variances and actual costs) but instead SAP offers a completely different approach that posts work in process and production variances with the underlying goods movements and confirmations. You’ll find more information about the general process in my earlier blog: The Differences between Traditional and Event-based WIP and Variance Calculation. For the latest information, check out Shuge Guo‘s post as part of the same series: Production Accounting for Universal Parallel Accounting
Universal Parallel Accounting does not support results analysis and hence also the settlement of results analysis data. The recommended approach is to move to event-based revenue recognition, as described in Volkmar Zahn’s blog: Event-Based Revenue Recognition for Universal Parallel Accounting
Actual cost rate calculation, overhead calculation, settlement, and universal allocations must run per ledger. This is either done manually via single Overhead Accounting apps or automated using the Schedule Overhead Accounting Jobs app, as shown in Figure 8.
Reports in Overhead Accounting offer the possibility to select and review financial data by ledger, since in these reports’ ledger is a filter criterion. The Product Profitability Report (see Figures 9 and 10) gives a sense of how the costs flow into the contribution margins with respect to a ledger. In this example the revenues are the same, but the cost of goods sold are different in the two ledgers, resulting in different contribution margins.
A move to Universal Parallel Accounting will also involve a move to the Fiori reports, as the ledger field has been enabled for all Fiori reports but has not been enabled in the existing Report Writer/Report Painter based reports.
For more details about how the cost of goods sold are calculated in each of these reports, please refer to my parallel blog: Inventory Accounting with Universal Parallel Accounting
This approach radically simplifies organizations’ abilities to handle the requirements of different accounting principles in the area of overhead management and removes the need for significant manual work to reflect the different approaches on the true cost of goods sold.
Given that this is the first release of Universal Parallel Accounting, it is important to compare the delivered scope with that required for your project, since functions that aren’t supported are not available in the SAP Easy Menu if the business function for universal parallel accounting is active.
The Reassign Costs and Revenues app is not yet ledger-enabled, so if you need to make manual changes in Controlling, you should use the “Post Journal Entries” app for the time being.
For a complete overview of the scope of Universal Parallel Accounting, please refer for this note: Scope Note for Universal Parallel Accounting
For further details concerning the alternative fiscal year variant, please refer to this note: Scope Note for Alternative Fiscal Year Variant
Universal Parallel Accounting is activated using a business function. For details, please refer to the business function documentation: Business Function Documentation
Thanks so much for the informative blog ! Just wanted to check whether we have a demo system in learning hub which is set up with Universal Parallel Accounting. Also, do we have a demo for UPA in SAP Demo store ? If not, what is the planned availability ?
Thanks so much !
We don't yet have a demo for UPA in the SAP demo store or on the learning hub. I'll update the blog when I know more.
1. Is the concept of CO delta versions still alive with the UPA (used in the business function FIN_CO_COGM), otherwise what (if at all) reduced information is written to CO documents? I would assume just the version 0 without any additional FI currencies.
2. Are there any plans for aka CJI3(N) based on ACDOCA that supports dynamic selection on master data attributes and the status selection profiles?
3. What about special Value Types that exist only as CO documents, for example 12.
the CO delta version isn't supported at all in SAP S/4HANA. It wasn't available with the universal journal (from OP1503) and there are no plans to support it going forward (see simplification item https://launchpad.support.sap.com/#/notes/2270414).
Regarding CJI3N, I've definitely heard the requirements, but we haven't implemented anything as yet.
The special value types are supported if they are part of the public cloud scope so value type 12 (down payments) is supported but the classic commitment solution isn't (instead we recommend to work with predictive commitment management which writes data to an extension ledger).
Thanks for this overview. It is very helpful to see al those new functionalities of Universal Allocations. Nevertheless misspoke functionalities or maybe I am not aware of those ones. Maybe you know.
I perform multi step overhead cost allocation from one cost center to others. By the end of this multistep allocation i dont have the transparancy/tracebility to the original sending cost center. I would need to make a complex analysis on allocation cycles and steps etc in order to trace my value flow from the last receiving cost center to the first sending cost center. Due to my understanding current functionalities of universal allocations offer only the app "allocation flow" which provides me the direct partner sending/receiving cost center objects, but not the partner of the partner (so all the previous allocation steps). My traceability is limited here, especially when I have to perform 8 to 10 allocation steps.
Is there some functionality in Universal Allocation which provides to me this full traceability of all corresponding partner objects from the original sender to the last receiver in the allocation value flow? For example, in PaPm I can trace my allocation to the first original sending cost center in the whole allocation vale flow.
Thank you and kind regards,
you're only hope at the moment is to use the "Allocation Flow" app in Universal Allocation to see the flows from the senders to the receivers. We are investigating a "Universal Cost Breakdown" that would provide transparency into the cost inputs across all value flows, but this is still in the research/design phase at the moment.
the allocation flow app is a good step in the right direction but still quite rudimentary not applicable for complex cost center hierarchy analysis and multisteps allocation.
Such a functionality like the "Universal Cost Breakdown" will be the game-changer!!. Bye-Bye to the complex calculations and business logics in SAP-BW in order to try to generate a little more transparency of the allocation flows and welcome to Fiori!!! I can really understand the complexity of your investigation, but cannot wait to see your results. Do you have a feeling when we could expect it?
the first small piece is planned for CE2308, but you can imagine that it is going to be quite a long journey to make the universal cost breakdown callable from everywhere.
I noticed that among all new functionalities of universal allocations, it is not possible anymore to have an allocation from one functional area to other functional area as it used to be in KSU1. We've had this functionality in the "old SAP" world (SAP Transaction KSU1).
I am also not aware of any customizing possibilites of universal allocations to have allocations between functional areas.
Are you aware, if this functionality is going to implemented in Universal Allocations in the future as well or is it already available in S4, but just needs to be configured/customized somewhere?
Thanks a lot and kind regards,
in the classic transactions, there is a configuration step to add receiver types which determines the fields shown in the Senders/Receivers screen above. In Universal Allocation SAP determines the fields via the Allocation Context. SAP Fioris cannot handle the dynamic nature of the old screen definition, so if we need to add a field then we need to create a new context. I'll add it to my list of gaps. Can you please share the use case that you have been handling via this approach in the past (is it cost center in combination with cost element and functional area or more like a profit center to profit center allocation that ignores the CO objects?).
thank you so much for your promt response.
My business case would be the allocation of actual overhead cost from a Cost Center in combination with a GL account and Functional area via a secondary GL account to a different Cost Center and different Functional Area.
In the scope of using "Margin Analysis" as allocation context I can create a segment in the allocation cycle and use as a sender the cost center and add the functional area on the receiver side. But unfortunately, I cannot add a Cost Center there on the receiver side. On the other side, i cannot add a Functional Area on the sender side. Is there any chance to add the cost center on the receiver side and functional area on the sender side as well? (e.g. via customization with the app "Custom fields and logic" or any other way?)
have you had a chance to look at my response? Is it possible to customize universal allocations, the way I described it below?
Thanks and kind regards,
Thanks for sharing the use case. Your challenge with "Custom Fields and Logic" is the context. You can currently add fields to the market segment context which would then be available as a receiver in allocations with the margin analysis context, but there isn't an extension context for universal allocation in general. I'll let you know if things change.
Thank you for your blog it is very informative.
In the blog there is a statement "be aware that there is not yet an equivalent for indirect activity allocation (transactions KSC1-5)" I can not find a reference in the SAP S/4HANA roadmap if that functionality is planned at all https://roadmaps.sap.com/board?PRODUCT=73554900100800000266&range=CURRENT-LAST#Q4%202022
Is this something that is on your radar at all ? and are you aware of many requests from customers for such functiionality ?. It has the impact of customer maintaining both cost centre global hierarchies for reporting and cost centre groups to maintain the indirect activity allocation cycle as flagging the "use in compatible cost centre group' indicator whan maintaining global hierarchies does not seem to have any application when maintaining the indirect activity allocation cycle.
any insight or thoughts to the future you may be able to share hear would be appreciated.
we are already discussing how to offer what you know as indirect activity allocation in combination with universal parallel accounting. It will be a new rule-based approach and I'll create a roadmap item as soon as we can say when we are able to deliver with reasonable certainty.
Currently indirect activity allocations only read the classic cost center hierarchies. Only in universal allocation can you choose between "new" and "old".
You mention above that Universal Allocation can be used as an alternative to Assessments, Distributions, and Periodic Repostings, but (at least in our release of S/4) the UA functionality does not match the capability of periodic reposting to allocate variable cost. For example, we plan labor as variable in each production line cost center but actuals from payroll come in to one central cost center at the plant; our goal is to allocate this cost and retain its variability in the production cost centers. Distributions always result in the labor being classified as fixed after actual cost splitting.
With our use of dual ledgers, we are compelled to use Universal Allocation given its ledger-specific allocation capabilities, but it seems the absence of periodic reposting will prevent us from representing all variable costs as variable. Is there any plan to include this functionality in the future? Or is there an alternative approach you would recommend?
yes, I know that there are still some topics missing (the biggest one is indirect activity allocation). I'll pass your comments on to the product owner for universal allocation.
Thanks for your blog!
Could you please kindly advise whether the following would be available with UPA activated:
1. Line item settlement rules maintenance for investment measures (CJIC)
2. Settlement rules maintenance per source structures
Thank you and best regards,
I would like to add to the question of Dmitrii
3. Tag function of settlement rules with UPA (for further traceability using the Allocation Flow Fiori App)
Thanks for the question. It's not on the roadmap yet, but it seems like an interesting idea.
talking about the functionality of Allocation Tags and Allocation Flow. Is there going to be in the future any functionality to download the allocation value flow into a tabular format? Cause currently it is only embedded and graphically visible.
Thanks and KD, Alexander
All I can tell you at the moment is that line item settlement for investment measures won't be in CE2308/OP2023, but that we know there are customers who need it.
We haven't got maintenance of the settlement rules by source structure on the roadmap yet.
One more question from my side.
I am reading through SAP note 3191636 and see the following:
Note that the classic planning transactions, e.g. in overhead accounting and margin analysis, are no longer available in connection with universal parallel accounting. The transfer programs that enable a transfer between classic planning tables and the new tables mentioned above are also not available.
For customers using SAP PPM one of the most important parts in that module is the ability to execute financial integration - transfer plan & budget from PPM to PS, transfer planned costs, commitments and actual costs back from PS to PPM. This solution is fully based on classic CO tables as per my knowledge.
Would it be still possible to execute financial integration and use above mentioned integration scenarios with UPA activated?
I would highly appreciate your advice.
Thank you and best regards,
If you use SAP PPM to update plan data to the CO tables, there is a copy program that takes the data out of the CO tables and updates it in ACDOCP (the new planning table).
For more information, see SAP Notes 2968212 - Transfer Programs between ACDOCP table and CO Tables : Corrections OP 2020 - SAP ONE Support Launchpad
3015820 - Transfer Plan Activity and Capacity from the ACDOCP table to the COSL table - SAP ONE Support Launchpad
Your challenge would currently be in the handling of commitments, as we follow the new commitments logic with the update to the extension ledger with UPA.