Skip to Content
Product Information
Author's profile photo Janet Dorothy Salmon

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.

Figure%201%3A%20End-to-End%20Value%20Flow%20with%20Universal%20Parallel%20Accounting

Figure 1: End-to-End Value Flow with Universal Parallel Accounting

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.

Figure 2: Project Settlement with and without Universal Parallel Accounting

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.

Figure 3: Project Settlement with Ledger-Specific Fiscal Year Variants

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.

Figure%204%3A%20Project%20Settlement%20with%20Multiple%20Currencies

Figure 4: Project Settlement with Multiple Currencies

Value Flows in Detail

We’ll now walk through the various processes to explain the differences caused by the introduction of Universal Parallel Accounting.

Universal Allocation

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).

Figure%205%3A%20Universal%20Allocation%20Showing%20Ledgers

Figure 5: Universal Allocation Showing Ledgers

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.

Cost Rates

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.

Figure%206%3A%20Cost%20Rates

Figure 6: Manage Cost Rates – Plan App

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

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.

Settlement

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.

Figure%208%3A%20New%20Settings%20in%20Settlement%20Profile

Figure 7: New Settings in Settlement Profile

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

Period-End Closing

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.

Figure%2010%20-%20Overview%20of%20Period%20End%20Close%20Jobs

Figure 8: Overview of Period End Close Jobs

Reporting

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.

Figure%208%20-%20Product%20Profitability%20in%20Ledger

Figure 9: Product Profitability in Ledger 2L

Figure%209%20-%20Product%20Profitability%20in%20Ledger%202L

Figure 10: Product Profitability in Ledger 0L

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

Closing Comments

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

Assigned Tags

      8 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Amit Kulkarni
      Amit Kulkarni

      Hello Janet,

       

      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 !

      Regards

      Amit

      Author's profile photo Janet Dorothy Salmon
      Janet Dorothy Salmon
      Blog Post Author

      Hi Amit,

      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.

      Regards, Janet

      Author's profile photo Paulo Vitoriano
      Paulo Vitoriano

      Hi Janet,

      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.

      Thank you,

      Paulo

       

      Author's profile photo Janet Dorothy Salmon
      Janet Dorothy Salmon
      Blog Post Author

      Hi Paulo,

      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).

      Regards,

      Janet

       

      Author's profile photo Alexander Sterin
      Alexander Sterin

      Hi Janet,

      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,

      Alexander

      Author's profile photo Janet Dorothy Salmon
      Janet Dorothy Salmon
      Blog Post Author

      Hi Alexander,

      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.

      Regards, Janet

      Author's profile photo Javier Fernando Ruiz Salcines
      Javier Fernando Ruiz Salcines

      Hi Janet,

      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?

      Best regards,

      Javier

      Author's profile photo Janet Dorothy Salmon
      Janet Dorothy Salmon
      Blog Post Author

      Hi Javier,

      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.