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 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.

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

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.

Figure 3

Line items in account-based CO-PA

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

Income statement in SAP Simple Finance

Figure 5 shows the same figures with a drill-down to the relevant cost centers.

Figure 5

Income statement with drill-down by cost center

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 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

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.

Figure 7

Settings for splitting the COGS according to cost components

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.

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

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).

You now have completed your journey through the value flows into CO-PA. You learned that 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.

Janet Salmon

Janet Salmon joined SAP in 1992. After six months of training on R/2, she began work as a translator, becoming a technical writer for the Product Costing area in 1993. As English speakers with a grasp of German costing methodologies were rare in the early 1990s, she began to hold classes and became a product manager for the Product Costing area in 1996, helping numerous international organizations set up Product Costing. More recently, she has worked on CO content for SAP NetWeaver Business Warehouse, Financial Analytics, and role-based portals. She is currently chief product owner for management accounting. She lives in Speyer, Germany, with her husband and two children.

You may contact the author at janet.dorothy.salmon@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.