SAP offers two choices for Profitability Analysis, or CO-PA as it is widely known. One is based on account codes (account-based CO-PA), and the other (costing-based CO-PA) is based on value fields, also known as key figures.

Although the end is the same for both, the means are different, setting the stage for discussions leading to which one is better.

Account-based CO-PA offers the immediate advantage of easy reconciliation with General Ledger Accounting (FI-GL), but you could also design costing-based CO-PA to reconcile with FI-GL. So, that’s where account-based CO-PA starts losing its key advantage. The argument that costing-based CO-PA offers only key figures (value fields) does not favor account-based CO-PA, as the CXOs are usually interested in key figures. Moreover, with time, SAP has increased the number of key figures available from 120 to 200, which are usually sufficient. Apart from making it on par with costing-based CO-PA, there are several other improvements delivered in account-based CO-PA.

However, before you can step over from costing-based CO-PA to account-based CO-PA, you need to consider their unique capabilities, a redesign of SAP processes if required, the required change management exercises, and a systematic transition. I address these areas in this article.

Table 1 shows the advantages with which the costing-based CO-PA used to race past the account-based CO-PA until SAP ERP Central Component (ECC) and how these differences stand now in SAP S/4HANA Finance.

Table 1
A comparison of the advantages of costing-based CO-PA with the innovations in SAP S/4HANA Finance

Account-based CO-PA not only is on a par with costing-based CO-PA in SAP S/4HANA Finance but also has other inherent advantages, owing to the new data model in SAP S/4HANA Finance:

• When account-based CO-PA is active, all the CO-PA characteristics (whether standard or user defined) from the operating concern are added to table ACDOCA.
• The CO-PA information is now managed in the same table ACDOCA as FI-GL. Using Fiori, you can now drill down from an income statement to see the sales revenue by customer, product, and region.
• With the merger of the general ledger account and cost element in SAP S/4HANA Finance, secondary costs are now also updated in FI-GL, putting aside the reconciliation woes.

So, can you just cross over the fence to account-based CO-PA and pull the plug on costing-based CO-PA? Definitely not. It requires much deeper thought and consideration. However, remember that costing-based CO-PA can still be used as earlier, but there will be no further innovations in it.

Possible Impact to the Business Process of a Switchover to Account-Based CO-PA

In this section I describe the various considerations that can affect the business on account of migration from costing-based CO-PA to account-based CO-PA.

1. Statistical condition types: Costing-based CO-PA allows you to update statistical condition types to CO-PA and then use these condition types for analysis in costing-based CO-PA. Costing-based CO-PA allows you to post values in costing-based CO-PA without affecting FI-GL. This comes in handy when you want to analyze profitability, including certain additional parameters, without affecting the income statement in FI-GL.

Impact: If you are using statistical condition types (e.g., ZX01) and updating them in CO-PA, too, you must consider the impact on profitability reporting after the switchover to account-based CO-PA. Since the statistical condition types don’t post to FI-GL, they don’t also update account-based CO-PA.

Possible remedy:

• The business process must change (i.e., the profitability analysis must exclude the statistical values and the analysis must be done based on actual values only).
• If the statistical values are needed for profitability analysis, you must address that issue through a workaround. You should perhaps use such condition types as real condition types in the sales and distribution (SD) pricing procedure and start posting them in FI-GL. Offset such postings with a new condition type (having condition record of -100 percent based on condition type ZX01) in the SD pricing procedure.

2. Valuation using costing sheets: Costing-based CO-PA allows you to calculate (accrual) values for additional valuations in CO-PA, such as freight costs, packaging costs, and sales commission with the help of costing sheets. These values are posted only in costing-based CO-PA without affecting the FI-GL.

Impact: During the switchover to account-based CO-PA, you must consider that this feature is not native to account-based CO-PA.

Possible remedy:

• The business process must change (i.e., the profitability analysis must exclude the accrual values and analysis must be done based on actual values only).
• If these accrual values are needed for profitability analysis, a workaround is necessary. Assign a new condition type in SD pricing procedure (e.g., ZX02). The calculations performed in CO-PA costing sheets must be performed in the SD pricing procedure using an SD routine (user exit) assigned to the condition type. You must then post such values to FI-GL. Offset such postings using a new condition type (having a condition record of -100 percent based on condition type ZX02) in the SD pricing procedure.

3. Valuation using user exit COPA0002: Additional valuations in costing-based CO-PA can also be performed using the user exit COPA0002 to post additional values in costing-based CO-PA independent of FI-GL

Impact: During switchover to account-based CO-PA, you must consider that this feature is not available in account-based CO-PA.

Possible remedy:

• The business process must change (i.e., the profitability analysis must exclude the additionally calculated values through a user exit and the analysis needs to be done based on actual values only)
• If these additional values are needed for profitability analysis, a workaround is necessary. Assign a new condition type in the SD pricing procedure (e.g., ZX03). The calculations performed in the exit COPA0002 must be performed in the SD pricing procedure using an SD routine (user exit) assigned to the condition type. You must then post such values to FI-GL. Offset such postings using a new condition type (having condition record of -100 percent based on condition type ZX03) in the SD pricing procedure.

4. Possible impact on settlements: During settlements to costing-based CO-PA (e.g., settlement of an internal order to CO-PA), you can credit the internal order using a single settlement cost element (from the allocation structure) and use the PA transfer structure to populate the amounts in the desired value fields in costing-based CO-PA, such as rents or advertisement costs.

(Note: PA transfer structure is the object in the SAP system for mapping cost elements to value fields.)

Impact: If you continue to use the same allocation structure after the switchover to account-based CO-PA, you won’t be able to get the same split in account-based CO-PA. You would rather see the amount populated in the settlement cost element (without the desired split).

Possible remedy (showing these adjustments in the configuration is not the subject of this article):

• After the switchover to account-based CO-PA, you would have to make modifications in the allocation structure to incorporate new settlement cost elements in order to have the same split in account-based CO-PA

To keep it simple, you need the same number of assignment lines, with the same cost elements in the allocation structure, as existed in the PA transfer structure (make allocation structure 1:1 with the PA transfer structure).

5. Possible impact on assessment cycles: During allocating the Sales, General and Administration Overhead (SG&A) to costing-based CO-PA, you can credit the cost centers using a single assessment cost element assigned in the assessment cycle. You make use of the PA transfer structure to populate the amounts in the desired value fields in costing-based CO-PA, such as salaries and interest costs.

Impact: If you continue to credit the cost centers using one assessment cost element after the switchover to account-based CO-PA, you won’t be able to get the same split in account-based CO-PA. You would rather see the amount populated in the assessment cost element (without the desired split).

Possible remedy (showing these adjustments in the configuration is not the subject of this article):

• After the switchover to account-based CO-PA, you would have to use an allocation structure in order to have the same split in account-based CO-PA
• You will need the same number of assignment lines, with the same cost elements in the allocation structure as existed in the PA transfer structure (make allocation structure 1:1 with the PA transfer structure)

6. Stand-alone adjustments to CO-PA data: Costing-based CO-PA allows you to make stand-alone postings to CO-PA independent of FI-GL, using transaction code KE21N. These postings can be to make corrections in the posted data or to feed the sales information from a third-party system for the purpose of profitability analysis.

Similarly, you can reverse and repost only the costing-based CO-PA document (transaction codes KE4S and KE4S00) without reversing the FI documents. This can be the case, for example, if the financial document is correct, but the characteristic derivations were not performed correctly.

Impact: During the switchover to account-based CO-PA, you must remember that these features are not native to account-based CO-PA. You can’t make any manual adjustment or correction posting into account-based CO-PA unless it is also posted in accounting.

Possible remedy:

• After the switchover to account-based CO-PA, you would have to reverse and repost the finance document or the document from the feeder interfaces such as SD (customer invoice), even though a correction has to be made only in the profitability analysis data
• This can be a concern in some countries including Brazil and India, where the reversal of a tax invoice must be intimated to the revenue authorities

7. Sign handling in CO-PA: This is a very tricky area. The way signs (+/-) are updated in costing-based CO-PA is very different from the way the (+/-) signs are updated in FI-GL.

For example, both the sales revenue and discounts are usually posted into CO-PA as an absolute amount (as positive), whereas in FI-GL, sales revenue is posted as negative and discounts are posted as positive. Hence, account-based CO-PA is also updated accordingly, as FI-GL.

Impact: No impact on the business process, as such

Possible remedy:

• After the switchover to account-based CO-PA, you must carefully create the CO-PA reports, keeping the new sign logic in mind.
• Also, wherever necessary, train the end users accordingly.

8. Top-down distribution (TDD): Companies using TDD in costing-based CO-PA must re-create the TDD variants for account-based CO-PA

Impact: No impact on the business process, as such

Possible remedy:

• Re-create the TDD variants in account-based CO-PA

Additional Activities to Be Performed for Switching Over to Account-Based CO-PA

In this section, I briefly explain what additional tasks need to be performed after switching over to account-based CO-PA in SAP S/4HANA.  

1. New customizing tasks in SAP S/4HANA: As explained above, account-based CO-PA in SAP S/4HANA offers new features to split the COGS into multiple general ledger accounts, to split the production variances into multiple general ledger accounts, and to populate the sales quantities into multiple UoMs.

Should you need to use these features, you must perform the relevant additional customization. You would also need to write a small piece of ABAP code in order to populate the sales quantities in multiple UoMs. (Showing these tasks is not the subject of this article.) You can refer to Janet Salmon’s article, “SAP Simple Finance: New Options in Profitability Analysis, for more details.

2. Update MM-FI integration: For posting COGS into FI-GL, the general ledger account assigned in transaction OBYC – Transaction Event Key GBB – Account Modifier VAX is used when account-based CO-PA is not active. However, when account-based CO-PA is active, the Account Modifier VAY is used, instead of VAX.

The general ledger account assigned in Account Modifier VAY must be a cost element. You must complete this customizing activity accordingly.

One obvious question that would arise is, what would happen to the sales orders where the post goods issue (PGI) has been posted while costing-based CO-PA is active, but the account-based CO-PA is activated before the invoice is posted? A possible solution, after activating the account-based CO-PA, is:

• To create the general ledger account in GBB-VAX as a cost element (transaction code FS00), define the automatic account assignment to a profitability segment (transaction code OKB9)
• Subsequently transfer the posting to Controlling (transaction codes OKBA or OKBB)
• Adjust the profitability segment to include relevant details, using line item reposting (transaction code KB61)

3. Updating the profitability segment in sales orders: When account-based CO-PA is active or if the transfer of sale orders to costing-based CO-PA is active, the profitability segment is determined at the time of sales order.

In your existing system, if the transfer of a sales order to costing-based CO-PA is not active, it is a good idea to run transaction KE4F, so that the sales orders are updated with the profitability segment.

4. Re-create reports: Since account-based CO-PA uses cost elements, instead of value fields, you must re-create your profitability reports after switching over to the account-based CO-PA.

The format of the reports in account-based CO-PA would, ideally, remain the same as in costing-based CO-PA. So, the existing reports in costing-based CO-PA should act as a good reference point.

5. Adjust assessment cycles: After the switchover to account-based CO-PA, you must adjust your assessment cycles to account-based CO-PA in the cycle header.

Assessment cycles in CO-PA require you to specify the Tracing Factor (TF) Basis in the cycle header in transaction code KEU1. If you are using account-based CO-PA, the TF Basis must be set to 2.

Managing the Historical Information in Costing-Based CO-PA

The migration process to SAP S/4HANA as well as to SAP in general does not offer any tools to migrate the historical information in costing-based CO-PA to account-based CO-PA. You must consider if the historical data from costing-based CO-PA is needed for future analyses. If yes, then how much of that is needed (for example, historical data of three previous years)? Accordingly, this must be undertaken as a separate project to migrate the historical information into account-based CO-PA.

While it would be an ideal situation to migrate the historical data to account-based CO-PA in the same timelines as SAP S/4HANA migration, it is quite unlikely to happen. Considering the criticality of the SAP S/4HANA migration and the complexity of the historical data migration from costing-based CO-PA to account-based CO-PA, it is advisable to keep both the projects separate.

Hence, there might be a transition period post migration to SAP S/4HANA, in which both account-based CO-PA and costing-based CO-PA are active simultaneously. Once the historical data is migrated, the plug on costing-based CO-PA can be pulled (by deactivating the costing-based CO-PA in the operating concern using transaction code KEA0).

There could be another option to handle the historical data in costing-based CO-PA, which is to make use of data warehousing tools to store the historical information. This can then be used for future analyses. However, this also needs to be taken up as a separate project.

For more information related to this topic, read these articles:

“SAP Simple Finance: New Options in Profitability Analysis"

"Revealing a New Type of Profitability Analysis (CO-PA): Combined CO-PA"