One of the biggest issues that accountants have with the Controlling Profitability Analysis (CO-PA) module, is that

is not easy to

reconcile it with the Financial Accounting (FI) module. Some users have said that they were told that CO-PA was not meant to

reconcile with FI, and should be accepted it as an analysis tool for evaluating the contribution margin for the various market

segments of the organization. However, in order for accountants to validate the figures reported by CO-PA, they need to ensure that

they are reconciled with accounts in the general ledger.

In order to address the reconciliation issues, we need to identify the different ways that actual data flows into CO-PA. They are as

follows:

1. Conditions from Sales Document: Sales order conditions (such as revenue, discounts, commissions, etc) are mapped to CO-PA

value fields. These conditions are also mapped to account keys which are linked to G/L accounts. You can therefore look at the

accounts that are linked to these account keys and tie them back to the value fields that the conditions are assigned to.

2. PA transfer structures: General Ledger accounts can be assigned directly to value fields by using PA transfer structures. These

G/L accounts are normally either posted directly to, during a financial posting or posted to automatically during an inventory-related

posting. Also, variance categories from Cost Object Controlling are mapped to value fields to reflect the production variances that

arise when a manufacturing order is settled. The total of the variance categories should be equal to the general ledger account that

is posted to for the production variances (this is the account that is configured in transaction OBYC, under transaction key PRD and

general modification PRF).

3. Assessments: These are created to map the postings to a cost center (for all or specific cost elements in that cost center) to value

fields in CO-PA. Assessments to CO-PA are normally used for costs that do not pass through the Sales and Distribution module,

such as Research and Development costs, General and Administration Costs and indirect selling expenses.

4. Manual Posting: By using transaction KE21N you can directly post to a CO-PA value field. This only updates CO-PA and not the

general ledger. It is normally used when there are adjustments that need to be made to CO-PA only, either for legacy balances or in

cases where there are errors which can no longer be corrected in the source data.

As you can see from the above methods, most value field assignments are either directly or indirectly linked to a general ledger

account (cost element). Therefore, in most cases you should be able to identify groups of cost elements that should be reconciled

with their corresponding value fields.

A few of the areas that you can expect to see reconciliation differences between the Financial Accounting (FI) module and the
Controlling Profitability Analysis (CO-PA) module are as follows:

A) Rebate Accounts: This is a very tricky one because it is not easily noticed. Rebates are usually posted in CO-PA as negative
values (as they derive from negative conditions). However, in the P&L account that is posted to for rebates (which is linked to the
condition type account key in transaction VKOA), it is a positive value. Therefore there could potentially be a mismatch between the
postings in CO-PA and FI due to the different signs.

B) Cost of Sales Account: In costing-based CO-PA, the cost of sales value field is updated when the billing document is posted (at
the same time that revenue is posted), while the cost of sales account in the FI module is posted when the Post Goods Issue (PGI)
transaction is made. This means that if a PGI is done in one month and the billing document is made in a subsequent period, there
will be a time-lag between the update of cost of sales in the general ledger and in CO-PA.

C) Cost Element Categories: If the cost element that is linked to a condition types account key does not have the cost element
category of 11 or 12, then the relevant CO-PA value field will not get updated. In most cases, when a value field is not mapped to a
sales condition, the billing document will not get passed to accounting, hence the condition will need to be mapped in order to
correct the issue. However, if the condition is mapped to a value field, but the cost element linked to that condition& rs quo;s
account key uses a different cost element category (other than 11 or 12) then you will not get a billing document error message.
This is because a CO-PA document will be created (but the relevant value field will not be posted to). This therefore means that it
will be more difficult to detect these issues since the system will not alert you to the fact that the CO-PA value field has not been
updated.
Production Variance Account: This is the account that is posted to when a manufacturing order which is delivered or technically
complete, is settled (transaction CO88). This variance account is configured under transaction OBYC, in transaction key PRD and
account modification PRF (if you are not using an account modification, then it is simply the account configured under transaction
key PRD, but for a manufactured product, such as one with a semi-finished or finished products valuation class). This account
should not be set up as a cost element, as the variance is normally posted to CO-PA by mapping variance categories to the PA
transfer structure (transaction KEI1). If you set up the variance account as a cost element then there will be a double-posting in CO-
PA.

You can use transaction KEAT to perform a reconciliation between FI and CO-PA. This report shows (for each billing document) the
differences between FI, SD and CO-PA for sales conditions such as revenue, cost of sales, rebates, commissions, etc. It helps
detect any errors in configuration that cause discrepancies between the modules. Another good way of performing a reconciliation (if
data volumes allow) is to drilldown into a value field line of a CO-PA report and compare it to the items in the corresponding general
ledger account.
It is important to reconcile CO-PA to the GL since we use the CO-PA line item report KE24 to provide monthly actuals data by
customer, product type, and contract size that is loaded in our Hyperion Planning forecasting system. In order to have an accurate
base for forecasting, we need to have accurate (with non-material difference) historical data.
So, how do we reconcile the CO-PA line item report KE24 to the GL?
1. Include manual journal entries (record type B) when running KE24
2. All manual journal entries that include revenue and COS must include profitability fields (sales order, customer) in order to post to
CO-PA. More details of the requirements are:
A. Profitability fields for all revenue accounts and manual COS accounts are mandatory
B. Profitability fields for the general COS account are not mandatory since, sometimes, journal entries are recorded to COS but are
not related to a specific sales order. These journal entries will be reconciling items between CO-PA and the GL.
3. The above steps minimize the reconciling differences between CO-PA and the GL however they do not eliminate them. There can
be timing differences since:
A. CO-PA posts both revenue and COS when an item is invoiced
B. GL posts COS during goods issue, and revenue when an item is invoiced
Run transaction KEAT to display postings to the GL in previous periods, and not yet billed.
4. Remaining reconciling differences between CO-PA and GL result from revenue and COS related to repairs sales orders. Most
repair order revenue and COS are not recorded in CO-PA due to the order billing types. We are working on finding ways where they
are not a reconciling item.