Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Showing results for 
Search instead for 
Did you mean: 
33,553

Actual Costing and Account based CO-PA in S/4HANA


Warning: This blog gets into certain nitty-gritties of the Controlling module. It is ideally suited for people with knowledge in this area.

The basics


The blog written by sap.shakeel titled “Has Account based CO-PA evolved enough to be recommended in S/4HANA” details some of the features of Account based CO-PA in the context of S/4HANA and also espouses his views on the usability of the functionality.

I would like to supplement his thoughts with certain other insights as well. But before that, a few generic impressions…

Firstly the unified Financials backbone provided by S/4HANA is one of the most important simplifications. It addresses one of the key concerns that the Finance departments had in terms of having to deal with external and internal (management) accounting data separately in SAP.

In hindsight, the design of separate data structures for FI & CO seems like a convoluted complication thrust upon customers. It enhanced the “value” of the CO consultant on whom depended the implementation of the most complex concepts of managerial accounting. The design and structuring of various aspects of the CO module played an important role in its effective utilization.

However, the complexities (especially those related with reconciliation between FI & CO) relegated usage of CO functionalities to the bare minimum, necessary to sustain the overall accounting (E.g. Cost Center Accounting, Product Costing, etc.).

With the opportunities provided by HANA, SAP has rightfully unified the separate modules and their data structures. On the one hand this relieves the Finance users from redundant and non-value adding work of reconciling and at the same time also tries to bring in some of the special features of the separate data structures into the unified module (e.g. Cost Component split in Account based COPA, etc.).

Has Account based CO-PA evolved enough to be recommended


While Shakeel has given a detailed comparison and concluded that while his heart is still with Costing based CO-PA his thinking mind would go with Account based CO-PA as that is where the future developments lay, here are a few more points to consider regarding the new advancements in Account based CO-PA (in specific scenarios) :

Cost Component Split: In S/4HANA, it is possible to split the COGS Account into its Cost Component Split posting the respective Cost Components to Account based CO-PA. The solution provided is that after the usual entry is posted debiting Cost of Goods sold Account, the same account is reversed and the split is taken to different accounts as per their assignment to Cost Components in the new configuration.






























Std Cost of Product A 1000
Cost Component Split
Material 700
Activity 200
Overhead 100


 




























































COGS for 10 nos of Product A
COGS A/c Dr 10000 Regular Entry at the time of Goods Issue for Delivery
To Inventory A/c Cr 10000
Material Cost Comp A/c Dr 7000 Split of COGS into Cost Components - new functionality in S/4HANA
Activity Cost Comp A/c Dr 2000
Overhead Cost Comp A/c Dr 1000
To COGS A/c Cr 10000


 









































In Costing based COPA In A/c based COPA
Value Field Account
Material Cost Comp 7000 Material Cost Comp A/c 7000
Activity Cost Comp 2000 Activity Cost Comp A/c 2000
OH Cost Comp 1000 Overhead Cost Comp A/c 1000


Effectively, with the accounting of the Cost Component Split, SAP has brought A/c based COPA to the same level as Costing based COPA in terms of this functionality.

Now, let us assume that Actual Costing is activated.






























Assume Actual Cost for Product A is: 1200
Cost Component Split
Material 800
Activity 250
Overhead 150


 

For Costing based COPA, we run the Periodic Valuation (Transaction KE27) by which the Actual Cost Components can be taken to new and separate Value fields. The Revaluation of Consumption for COGS option in Actual Costing will not be used in this case.



























In Costing based COPA
Value Field
Actual Material Cost Comp 8000
Actual Activity Cost Comp 2500
Actual OH Cost Comp 1500


Hence for reporting based on Actual Costs, these Value Fields can be chosen

For Account based COPA however, the Periodic Valuation will not work. For that, only the revaluation of Consumption option in Actual Costing will come into play. At the time of revaluation of Consumption posting, the delta amount is taken only to the original COGS Account.



















Account
COGS A/c                                Dr 2000
PRD Variances A/c                  Cr 2000


This means that the Actual Cost reporting in A/c based COPA will look like this:
























Account
Material Cost Comp A/c 7000
Activity Cost Comp A/c 2000
Overhead Cost Comp A/c 1000
COGS A/c 2000


Needless to say, this representation is problematic whereby the total variance accrued to the goods sold is shown as a consolidated amount and not split into the Cost Components though that split is available in Actual Costing.

This simplification item thus becomes redundant in the wake of activation of Actual Costing

 

Splitting of Production Variances: In S/4HANA, it is possible to split the Production variances into their respective categories while posting to Account based CO-PA. The solution provided is similar to the Cost Component Split solution mentioned above, in that, after the usual entry is posted debiting (or crediting) respective Variance Account, the same account is reversed and the split is taken to different accounts as per their assignment to category in the new configuration.






















Prod Variance in production of Product A 2000
Input Price Variance 1500
Input Qty Variance 500


 

Accounting entries:














































PRD Variance A/c Dr 2000 Regular Entry at time of settlement of Prod Order (Accounts determined from OBYC)
COGM A/c Cr 2000
Input Price Variance A/c Dr 1500 Split of Variance into Variance categories  - new functionality of S/4HANA
Input Qty Variance A/c Dr 500
PRD Variance A/c Cr 2000


 

Now here is a crucial question… how do we deal with the CO Account assignment for these postings?

Well, at the outset, the GL accounts assigned to the different categories will obviously have to be taken to CO-PA. As for the main Variance Account determined from MM-Account determination (OBYC), it is redundant as the account gets nullified – so it can either be taken to a Cost Center (using default account assignment) or can be created as a non-cost element.

But herein comes the twist… when Actual Costing is activated… the period end Actual Costing run, basically reverses the Variances and takes them to Inventory or Consumption (including Cost of Goods sold). So continuing with the above example, assuming that all quantity of product A was sold, the total variance will have to be taken to COGS.



















Account
COGS A/c                                Dr 2000
PRD Variances A/c                  Cr 2000


In this case, taking the Production Variance split originally to CO-PA becomes detrimental as these amounts are effectively nullified (in terms of value) by the Actual Costing run and taken into either the Consumption accounts or Inventory Accounts. Multi-level settlement in Actual Costing is able to allocate these variances to the final product that is sold.

Hence the original split postings remain at the respective material level whereas their reversal happens using another account. In CO-PA, then COGS is already loaded with the proportional variance whereas the split is still redundantly shown as a cost.

The solution then is to not activate the Variance Split if Actual Costing is activated.

This simplification item thus becomes redundant in the wake of activation of Actual Costing

 

Kitting process: Now here is a scenario for which, I would like to say that I haven’t been able to find a solution… Kitting process is one in which a Sales Order is created for an item that is basically a set of other items. The pricing is for the header item whereas the supply is individual quantities of other items together. Technically, the first Sales Order item contains this “header” material and the subsequent Sales Order items are linked to this first “header” item as the higher level item. The pricing and billing is for this 1st item (the header material). The Delivery and Goods issue happens for the lower level items.

In Costing based CO-PA, it was possible to view the revenue and cost of goods sold (COGS) at the level of the header material by using the “VPRS” condition type of the header level item to post the cost to CO-PA. However, in Account based CO-PA, the posting of COGS happens alongside the Goods issue. The ACDOCA table has a field called MATNR (representing the Material number) and a field called ARTNR (representing the CO-PA characteristic. But since both of these fields refer to the same Data element, the system disallows different values to be stored in these two fields. Hence, inherently, it is impossible to capture the header material as Product value for CO-PA while posting the COGS. This then is a big gap in being able to do the Profitability Analysis of such kitted items.

The unification into Universal Journal hence does not support an effective Profitability Analysis for kitting process

 

Conclusion


The issues mentioned above are specific scenarios in which either the simplification item is redundant or the concerned process is just not supported. However the larger benefits accruing from Account based CO-PA over-ride these pitfalls. Clearly, there is a simplification and this simplification has a significant improvement in not just the period-end activity of reconciliation, but also on the way users / customers see CO-PA. I would strongly recommend going with Account based CO-PA for every S/4HANA implementation as the benefits outweigh the issues.
5 Comments
Labels in this area