Personal Insights

What is Combined Profitability Analysis?

From this blog post you will learn the following about the Combined CO-PA (cPA )

  • cPA  analysis overview
  • Implementation Strategy
  • Advantages over cost-based CO-PA approach
  • Data Structure for the cPA 
  • Technical Prerequisite for activating cPA 
  • Configuration steps for the currencies / Process Flow – Testing
  • How to include custom currency types
  • Process Steps
  • Recommendation

Combined Profitability Analysis Overview –

The combined profitability analysis is a further development of the costing-based profitability analysis. It combines the flexibility of the costing-based approach with the feature of the account-based type by updating the G/L posting lines that are relevant for the P&L statement in a document in addition to the costing-based value field view.

This means that it is possible to analyze the update of a profit-related transaction (such as the invoicing of a customer or consumption through delivery) both in the structure of a contribution margin scheme divided into value fields & in the form of the accounts to which posting takes place in financial accounting. SAP introduced a new form of Profitability Analysis (CO-PA), cPA. cPA reveals a lot of new functionalities. It uses value fields and has much more functionality than costing-based CO-PA. It has all the capabilities to replace the cost-based CO-PA.

The cPA allows you to reconcile to the general ledger (G/L) accounts as it has the information from the FI-GL, due to this the biggest challenge of costing-based CO-PA—reconciliation with the SAP General Ledger— is solved. cPA allows reporting across value fields and G/L accounts in contrast to the cost base where we have only the reference to value field which could be updated from numerous accounts, which is configuration dependent along with statistical condition types. The cPA also introduces the Rec type “L” document which are posted during post good Issue. It does not replace account-based CO-PA.


When cPA  is compared with account-based CO-PA, the major differences are:

  • Account-based CO-PA is based on G/L accounts, whereas cPA  is based on value fields.
  • Account-based CO-PA allows the use of attributed profitability segments, whereas cPA does not support the use of attributed profitability segments.


Implementation Strategy 

Brown Field Implementation:

The classic costing based CO-PA analysis is already in use.

In this scenario, the existing value field structure and the configuration of the valuation and quantity update are automatically copied to customizing for the cPA . (There is no setting that can be copied from a productive account-based profitability analysis, if one exists.) Typically, the costing-based and the cPA then run in parallel mode for evaluation purposes. Following a successful evaluation, the costing-based CO-PA is then deactivated.

In the simple brownfield implementation scenario, where the cPA should merely be added to the costing-based profitability analysis, efforts are restricted to the following:

Generation of data structures and environment using activation in transaction KEA0
Activation of the cPA for the relevant controlling areas in transaction KEKE
Check of plus/minus sign logic for the copying of statistical condition types from SD in transaction KEPLC07

Default account assignment for result of goods issue account created as cost element for deliveries

Following these activities, the cPA then updates the values both to currency view 10 (“Company Code Currency”) and B0 (“Operating Concern Currency”).

The quantity update is restricted to 00 (document quantity view).

Existing profit-related documents such as billing documents, G/L postings, and goods movements can be subsequently posted to the cPA .

Billing documents – KE4SP
G/L documents – KE4SP_FI
Goods movements – KE4SP_MM
Sales orders for the generation of incoming sales orders – KE4T (once the sales orders have been successfully prepared with transaction KE4F)
However, the prerequisite for this is the configuration and activation of the update of incoming sales orders with the record type “A” in transaction KEKF


Greenfield – no profitability analysis is yet in use.

If profitability analysis is not yet in use in the operating concern in question, a value field structure and valuation rules (and possibly also currency translation customizing) must be defined. There is no relevant setting that might have to be copied from a productive account-based profitability analysis, if one exists – without the further setup of value fields, the cPA already updates the same amounts as the account-based profitability analysis.

Minimal customizing includes the following steps:

Creation of the operating concern with specification of the type of profitability analysis using transaction KEA0

Definition of value fields (and activation of the data structure)

Definition of the attributes such as the fiscal year variant and selection of the databases for storing the documents
(The selection of an operating concern currency is technically necessary, but the update of this currency is determined in the selection of the currency views.)

  • Generation of the environment
  • Creation of further currency views and, if appropriate, record-type-dependent currency translation with

transaction KEPLC04 if more than only the first local currency needs to be updated (optional)

  • Creation of further quantity views and, if appropriate, of transfer or conversion rules for quantities with transactions KEPLC05 and KEPLC06 if more than the document quantity needs to be updated (optional)
  • Configuration of a valuation strategy for the mapping of cost-of-sales accounting through the filling of relevant value fields with the cost component split elements of a costing
  • Default account assignment to the profitability analysis for profit-related accounts in transaction OKB9
  • Check of plus/minus sign logic for the copying of statistical condition types from SD in transaction KEPLC07
  • Finally: Activation of the cPA for the relevant controlling areas in transaction KEKE


Advantages over cost-based CO-PA approach –

cPA  have several advantages over the traditional cost-based CO-PA, few of them are

  • Carrying multiple currency types
  • Integrated with the GL
  • Multiple quantity View
  • Pivot browser from the reporting aspect is much more useful than tradition Ke24 reports
  • Record type L at the instant of PGI for the reconciliation


Data Structure in cPA –

Like Costing Based CO-PA where we have (CE1, CE2, CE3, CE4) table, cPA comes with its own set of tables which all prefix as CE9*

The cPA table are fully integrated with the GL (ACDOCA) and can be broadly divided into 4 tables as below. All these table have document number as the key entries.

Document header – It contains all the information related to the header
Accounting segment – it contains the information related to the GL accounts and help in reconciliation at the account level
Value field segment – It contains the information on the Value field, similar to the cost based CO-PA
Quantity segment – it contains the quantity view information, if it is activated in the customization


Technical Prerequisite for activating cPA –

In order to activate the cPA some technical requirements must be fulfilled. One of the following requirements must be fulfilled to be able to activate cPA in your system:

The system must be on S4CORE level SP1.

2370683—Various enhancements in the profitability analysis. To be able to implement this SAP Note, you must be on SAP S/4HANA Finance 1610 or higher.

1955893 –This note should be only implemented if the development class KEPSL does not exist yet in your system (use transaction SE21 to check).

Post the implementation you need to create the data structure in Transaction code – KEA0 as below.
Note** You would be observing a new checkbox for the cPA  along with the account based and Cost base CO-PA.


Configurations Steps for the currencies

Currency types defined for the company code YYYY

Defined Currency types at the Ledger level.

cPA  configuration for the Currency. Define currency types for operating concern YYYY (no BADI  activated) Tx code – KEPSL.

Display currency types mapped to record type B

Currency Translation set up for currency type 10 & record type B. The same set up repeated for the other currency types (30 & 31). FI-PA transfer structure is set up for two cost elements mapped to two distinct value fields (this is done to ensure the posting is through ). cPA uses the same basic customization as of cost based.


Process Flow – Testing

Accounting documents # posted in company code YYYY, Document display

Display accounting document in table ‘ACDOCA’

ACDOCA structure got updated with freely definable currency & amount in freely definable currency.


Impact on cPA

Display cPA  document/ Pivot browser. Document #6 with item 1 & 2 posted for each GL account/cost elements and value fields. Document got posted with all the currency types defined in the operating concern currency type set up.

cPA table structure got updated with all the currency types (10, 30, 31) defined in the operating concern currency setup.


Problem with the custom Currency types

The Currency types which are defined at the Ledger level are not available at the operating concern level. We cannot see the currency types Z1, Z2, Z3, which available at the ledger level

How to include custom currency types

The Modification required the appending the fixed value custom Currency type. Here we have added our custom currency types.

Adding the currency type to the cPA configuration for currency

Currency Translation Rule as set in the General Ledger

Modification of Class – CL_KEPSL_CONF

Modification to the Functional Module – KESPL_DOCUMENT_CLOSE

Modification to the Functional Module – KESPL_DOCUMENT_PROJECT

Re posting of the Record type -F document showing currency type – Z1


This code Modification Works when all the company code in the system have all the custom currency type required in cPA. For handling the company code having restricted number of currency types, we need some further code modification as below and defined In the PILOT note.

Program – LKEPSL_CURRF01

We can skip this statement for the custom currency

IF   <R>-CURTP(1) =Z* we need to exclude this code
Else do it
** stop processing if PSL currency key cannot be determined
*{   DELETE         DEEK905844                                        1
*\    IF   <R>-CURTP(1) <> ‘0’
*\    ENDIF.

We can delete T rules for condition IF <R>-CURTP(1) =Z*


Recommendation – It is always recommended to have account-based CO-PA. If the account-based CO-PA does not fulfills the requirement, you can always evaluate the cPA for the solution for the business case.

Useful References –