SAP Simple Finance: New Options in Profitability Analysis

sapinsider.wispubs.com/Assets/Articles/2014/December/FI-Expert-SAP-Simple-Finance-New-Options-in-
Profitability-Analysis

SAP Simple Finance links the profit and loss items in Financial Accounting with the
relevant items in Managerial Accounting. Thus expense items link with Cost Center,
Order, and Project Accounting. Revenue and cost items link with account-based
profitability analysis (CO-PA).

In the past, SAP tended to advise companies to use costing-based CO-PA rather than, or
in addition to, account-based CO-PA. SAP’s latest product offering, SAP Simple Finance,
uses SAP HANA as its primary database, opening up new options for profitability
reporting. In this context SAP is choosing account-based CO-PA over costing-based CO-
PA. With SAP Simple Finance, you get one version of the truth for profitability reporting
with the transparency you previously only got with costing-based CO-PA.

Account-based CO-PA has been enhanced in SAP Simple Finance to provide detailed
information on the cost of goods sold, production variances, and invoice quantities that
were previously only available in costing-based CO-PA. Costing-based CO-PA continues to
exist as an additional option alongside account-based CO-PA.

The characteristics you use for profitability reporting are the same in both types of CO-
PA. You set up an operating concern that defines the characteristics that your
organization will use (typically products, customers, customer groups, divisions, and
plants). These are stored in table CE4. The difference is in the way the transactional data
is stored with reference to these characteristics.

In costing-based CO-PA you store the values (revenues, cost of goods sold, production
variances, overhead, and so on) for reporting as value fields or key figures in the CE1
table. The configuration steps essentially map your accounts (such as revenues and sales
deductions) and cost elements (such as cost of goods sold, production variances,
assessments, and settlement) to value fields. For many years the limit was 120 fields,
rising to 200 fields in recent releases (see SAP Note 1029391).

By contrast, account-based CO-PA uses accounts or rather cost elements for the
revenues, sales deductions, cost of goods sold, and so on. There’s actually no limit to the
number of accounts you can use, but there was a limitation in the posting logic such that
cost of goods sold and variances were always assigned to a single account/cost element
and it is this limitation that SAP has removed with SAP Simple Finance.

CO-PA Using SAP HANA

In this section, I’ll look at how working with SAP HANA changes some of the givens about
CO-PA in terms of how data records are selected and aggregated. I’ll then look at how
account-based CO-PA differs from costing-based CO-PA and how activating account-
based CO-PA can allow you to provide radically better granularity in your income
1/11
statement.

Characteristics

Irrespective of whether you use costing-based CO-PA or account-based CO-PA, SAP

HANA changes the way your data records are stored. In a classic database, each invoice,
sales order, assessment, allocation, or settlement in CO-PA is stored as a row in the
database. To calculate the revenue per region, the system must select all invoices for the
region by querying each data record and then aggregating the values for those records
selected. The same records in SAP HANA are stored in columns. To calculate the revenue
per region in SAP HANA, only the region column must be queried and the relevant
amount aggregated. This brings enormous performance advantages and means that
many of the tricks that developers used in the past (such as indexing certain tables) are
no longer required.

The first accelerator to be delivered for SAP HANA supported costing-based CO-PA (for
details, refer to SAP Note 1627644). This was followed by an accelerator for account-
based CO-PA (refer to SAP Note 1823814). The approach was to move the CO-PA tables
into a separate SAP HANA database (sometimes called the side car approach) and
redirect all queries to read from this database rather than the classic database. If your
organization moved to SAP Business Suite powered by SAP HANA or the Financials Add-
On for SAP Business Suite powered by SAP HANA, then your queries no longer need to
be redirected since SAP HANA is your main database.

Whichever deployment option you choose, navigating through the 50 characteristics in

an operating concern has never been easier. Be aware, however, that the restriction that
the operating concern may not contain more than 50 characteristics remains since some
functions are still hard-coded to handle this structure. If you already use account-based
CO-PA, it’s worth checking which characteristics have been chosen for costing-based CO-
PA only and which are in both.
SAP’s recommendation in the past was to only store those characteristics in account-
based CO-PA that were genuinely needed for reconciliation. To check the settings, follow
IMG menu path Controlling > Profitability Analysis > Structures > Define Profitability
Segment Characteristics (Segment-Level Characteristics).
Figure 1 shows the settings for the profitability segments in one of SAP’s demo systems.
As you can see, I am only keeping characteristics such as product and customer in
costing-based CO-PA but not in account-based CO-PA for performance reasons.

2/11
Figure 1

Profitability segment characteristics

Transactional Data
To understand the difference between costing-based CO-PA and account-based CO-PA, I
use the CO-PA line-item report (transaction code KE24) to compare two sets of data. If
you choose costing-based CO-PA, you’ll see line items such as the ones shown in Figure
2.

Figure 2

Line items in costing-based CO-PA

3/11
Reading from left to right, you see:

The CTy column, which is the currency type (one of the settings on the operating
concern)
The Recor… column, which is the record type (in my example, you see B for FI
postings, A for sales orders, C for settlement, and F for billing)Columns for
characteristics, such as period, company code, plant, customer, and product
Value fields: invoice quantity, revenue, material input, production labor fix,
production labor variable, production machine fix

There are more columns that are not shown in Figure 2. They can easily be included by
extending the layout in SAP List Viewer (ALV).

Configuring CO-PA is about deciding which characteristics are important and how to map
all the accounts or cost elements into value fields. As you think about what happens
here, think also of the record types your organization is using and how these map to the
information you are capturing in the general ledger.

This process is relatively straightforward for your billing documents, journal entries, and
settlement. However, the general ledger does not capture sales orders, so you won’t find
record type A in account-based CO-PA. If your organization has configured its own record
types, then these probably aren’t captured in the general ledger either. Such a list helps
you to decide whether you have use cases that require you to continue running costing-
based CO-PA alongside account-based CO-PA in the future.
Now run the line-item report in account-based CO-PA, the results of which are shown in
Figure 3. The first thing you notice is that this looks the same as the line-item reports for
Cost Center Accounting (KSB1), Order Accounting (KOB1), and Project Accounting (CJI3).
This is because account-based CO-PA uses the same line-item table (COEP) as the other
CO applications. This means that you always run the report for a controlling area and
that each record is assigned to a cost element and is available in transaction currency,
object currency, and controlling area currency.

4/11
Figure 3

Line items in account-based CO-PA

The difference is that you aren’t using a one-dimensional account assignment, such as a
cost center or a work breakdown structure (WBS) element, but a multidimensional
profitability segment (PAOBJNR). You can see the details of this assignment in the pop-up
screen in which the details for the profit center, customer group, and material group for
the selected transaction are displayed. The benefit of this view is that it is easier to line
up the cost elements in this view with the accounts in the general ledger because they
haven’t undergone a transformation into value fields like the values shown in Figure 2.

Reporting on Transactional Data

With regard to reconciliation, note that the profitability segments shown in Figure 3
effectively explain the general ledger. With SAP Simple Finance you actually link the FI
postings for profit and loss items with their sister CO postings in Cost Center Accounting,
Order Accounting, Project Accounting and account-based CO-PA by extending the COEP
table. An SAP HANA view is then used to allow you to build drill-down reports on these
combined tables. Figure 4 shows a sample income statement in one of SAP’s test
systems. You can start from this view (the accountant’s view of the world) and drill-down
to the account assignments in CO (hitherto the controller’s view of the world).

Figure 4
5/11
Income statement in SAP Simple Finance

Figure 5 shows the same figures with a drill-down to the relevant cost centers. Note that
the values in Figure 5 are actually less than the same values in Figure 4. This is because
not all the selected postings are assigned to the cost center. In this example, some of the
postings were to orders and projects, and these do not appear when I drill down by cost
center.

Figure 5

Income statement with drill-down by cost center

Figure 6 shows the drill-down by customer. Again, not all the values in Figure 4 will be
assigned to customers. Some will probably be captured at a higher granularity, such as
region or profit center. Of course, the cost center reports, order reports, and CO-PA
reports that view this data separately continue to exist, but the new view shows where
SAP Simple Finance is taking new directions.

Figure 6

Income statement with drill-down by customer

One thing to be aware of is that this linkage between FI and CO presupposes that the two
records have equivalent posting lines. It’s relatively common for the FI postings to be
summarized, so the FI line items for a payroll posting might not include the cost center
even though the cost center record does. In CO-PA you might be invoicing a customer for
6/11
hundreds of products, but if your organization is running up against the 999 line-item
limit, your organization may have chosen not to keep a separate line in FI for each of the
products sold. During migration to SAP Simple Finance, the system will try to create a
link. Going forward, you should avoid summarization in FI to keep the two tables at the
same granularity.

Functional Enhancements to Account-Based CO-PA

Although users in the past recognized that account-based CO-PA provided inherent
reconcilability, there were three key gaps that meant that they would typically opt for
costing-based CO-PA over account-based CO-PA:

Cost of goods sold were posted to a single material account

Quantities were recorded in the unit of measure in the delivery or invoice
Production variances were posted to a single price difference account

Costs of Goods Sold (COGS)

With SAP Simple Finance, there is a new posting logic that allows companies to report
their COGS in account-based CO-PA at the same level of detail as in costing-based CO-
PA. In the past, the general ledger would record the material movement at the standard
price, while costing-based CO-PA would show the detail in the standard cost estimate
that was used to calculate this standard price. SAP Simple Finance includes new
configuration settings to link the cost components in the standard cost estimate with
sub-accounts for each cost component.

To activate this split, follow IMG menu path Financial Accounting (New) > General Ledger
Accounting (New) > Periodic Processing > Integration > Materials Management > Define
Accounts for Splitting the Cost of Goods Sold in the IMG. Figure 7 shows sample settings
where I use a cost component split that contains nine cost components to break out the
standard costs used for inventory valuation (essentially the settings for the cost
components defined in transaction OKTZ). The delivery or goods issue is configured to
update the COGS account 893015, but I want to see separate accounts rather than this
summary account. I’ve therefore created new accounts for each of my cost components
and added them to this table. Notice that the ninth cost component is flagged as the
default. If a cost component hasn’t been explicitly assigned to an account, it is assigned
to the final account in my list.

7/11
Figure 7

Settings for splitting the COGS according to cost components

The other major difference between this posting and what happens in costing-based CO-
PA is that it happens when the delivery is made rather than when the invoice is posted.
This means that the general ledger and CO-PA can never be out of sync, but you need to
be careful if you typically have a long delay between delivery and invoicing because you
will be recording costs that are not matched to an invoice.

Quantities

One thing to be aware of in account-based CO-PA is that the quantity is recorded once
with the invoice (the invoiced quantity) and once with the delivery (the delivered
quantity). Therefore, if you aggregate over the quantity column, the two figures tend to
balance each other out, leaving only a figure for deliveries awaiting invoicing. This takes
you back to the account model I described earlier. To understand the quantities that
have been invoiced, you have to be careful to report only on the revenue accounts.

Plenty of companies working with costing-based CO-PA choose not to report on the
quantities captured in logistics, but to convert these quantities into comparable units
(such as pounds or kilograms) that are consistent across product lines. To do this, they
use an exit in costing-based CO-PA to populate one or more additional quantity fields.
In SAP Simple Finance, the transaction table (COEP) has been extended to include three
extra quantities and their units of measure for just this purpose. To access the new
configuration in the IMG, follow menu path Controlling > General Controlling > Additional
Quantities > Define Additional Quantity Fields. Figure 8 shows how I configured these
fields in one of SAP’s test systems. In this case, if you only want to aggregate over
quantities that have been invoiced, then build the exit to update only in this case.

8/11
Figure 8

Configuration of quantity fields

Production Variances
With SAP Simple Finance, there is a new posting logic that allows users to report their
production variances in account-based CO-PA at the same level of detail as in costing-
based CO-PA. In the past, the general ledger would record the total variance or price
difference, while costing-based CO-PA would show the detail calculated when variance
calculation was run in Product Cost Controlling. SAP Simple Finance includes new
configuration settings to link the variance categories with sub-accounts for each
variance.

To activate this split, follow IMG menu path Financial Accounting (New) > General Ledger
Accounting (New) > Periodic Processing > Integration > Materials Management > Define
Accounts for Splitting Price Differences. Figure 9 shows sample settings that split either
all variances under a particular category to an account (the first line) or distinguish the
variances in a category further to include individual cost element groups (second line).

Figure 9

Settings for splitting the production variances according to variance categories

9/11
Allocations and Settlement

While some changes were needed in SAP Simple Finance to provide sufficient detail for
the product costs in account-based CO-PA, Cost Center Accounting, Order Accounting,
and Project Accounting continue to use the mechanisms that have been there since the
advent of account-based CO-PA to build their charge models. You can build assessment
cycles and indirect activity allocation cycles to allocate costs from a cost center to a
profitability segment.

During such an allocation, you make a decision during configuration as to whether, for
example, the trade fair was serving the region of Western Europe (one of perhaps a
dozen regions) or all customers in Western Europe (thousands of customers). This affects
the number of records created and the detail available for reporting. With the advent of
SAP HANA, some of the performance constraints of the past become irrelevant, and you
can build assessment cycles that disaggregate to a more granular level.

Bear in mind as you go through this process that a cost center can only allocate once –
the cost center can either be part of an assessment cycle taking its costs to account-
based CO-PA or to costing-based CO-PA. There is no migration path for existing
assessment and indirect activity allocation cycles.

If you allocated to costing-based CO-PA with no account-based CO-PA in the past, the
results of the allocation would be shown on a reconciliation object. Effectively, you would
credit the cost center, debit a reconciliation object (a placeholder for all the dimensions
in CO-PA), and create separate records to account for the allocated costs in costing-
based CO-PA.
If you allocate to account-based CO-PA, you credit the cost center and create debits for
each of the regions served or customers served. This simple sender-receiver relationship
is much easier to visualize and check. As you can see in Figure 3, all postings are
assigned to a cost element, so it’s also worth checking whether your assessment cost
elements provide sufficient detail for your reporting needs and potentially adding more.

What I stated earlier about assessment cycles applies equally to settlement. You can
build settlement rules that charge the costs for internal orders and WBS elements to
account-based CO-PA, but make sure that your settlement cost elements provide you
sufficient transparency for reporting purposes.
Top-Down Distribution

Finally, it seems to be one of those urban myths that you can’t do top-down distribution
in account-based CO-PA. You can in SAP Simple Finance and have been able to since
Release 4.7. Again, you can set up top-down distribution in account-based CO-PA just as
you set up assessment cycles. The main difference, however, is that you have to think in
cost elements. You need to include the cost element in your selections for top-down
distribution as you disaggregate (e.g., bonuses from a high-level characteristic, such as a
region, to the detailed characteristics, such as products or customers).
10/11
This completes your journey through the value flows into CO-PA and where a switch
from costing-based CO-PA to account-based CO-PA requires some rethinking. SAP HANA
as a database technology made sub-second drill downs through the millions of data
records in a real operating concern a reality. With SAP Simple Finance, SAP is going
further and redesigning the applications step by step as the constraints that shaped the
original designs change.

11/11