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 Roessler‘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.
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.
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.
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).
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), 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.
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:
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
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 via Overhead Accounting jobs, as shown in Figure 8.
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.
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
Okumaya devam et...
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 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 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 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), 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 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 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
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 via Overhead Accounting jobs, as shown in Figure 8.
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 9: Product Profitability in Ledger 0L
Figure 10: Product Profitability in Ledger 2L
Closing Comments
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
Okumaya devam et...