Many users don’t understand the CO module as well as the FI module. Their lack of knowledge can affect the initial setup of CO at go-live and cause difficulties later on (e.g., if a company wants to implement cross-company controlling). It is difficult, but possible to change controlling area structures post go-live (e.g., merge or split controlling areas). I discuss the reasons for going through this process.

The Initial Design of the Controlling Area Structure

During the initial SAP implementation the project team has to consider many business requirements, resource availability, and system functionality. The project team makes multiple basic configuration decisions that affect the life of the SAP system, based on the best options available to them at the time:

• Company code to controlling area mapping
• Controlling area currency
• Group currency
• Chart of accounts (length of account)

These decisions may have been the correct choice at go-live, but the business process or organizational requirements have changed over time, and in retrospect, the project team realizes that it could have made better choices. Of course, the project team is not omnipotent and cannot anticipate activities such as the company merging with another company, starting a new line of business, or acquiring a foreign subsidiary.

Controlling Area Models

SAP system configuration allows either multiple company codes to be mapped to a single controlling area or one company code to be mapped per controlling area. To control this functionality use transaction OKP1 to define the controlling area to company code relationship (Figure 1). Select option 1 or 2 from the drop-down list.

Figure 1

Set the controlling area (CoAr) to company code (CoCd) relationship

A Single Controlling Area

In general I recommend that you use a single controlling area encompassing all company codes to maximize availability of cross-company code controlling functionality (Figure 2). However, the best controlling area design depends on your specific organization’s scenario.

Figure 2

A single controlling area

1:1 Controlling Area to Company Code

Having one controlling area per company code (Figure 3) is common in older systems that went live in 1996 or earlier. At that time SAP releases had a limitation requiring the controlling area and company code currency to match. This was an issue for multinational enterprises, as they had multiple company codes with different company code currencies. Often this design can occur as users are more familiar with FI-based legal structures than SAP CO concepts.

Figure 3

1:1 controlling area to company code

Hybrid Structure

A hybrid design (Figure 4) makes sense if different group companies have very different business processes that are CO intensive and that share CO configuration that causes issues.

Figure 4

Hybrid structure

Benefits of a Single Controlling Area

There are multiple benefits to having a single or reduced number of controlling areas that I now discuss.

Cross-Company Profit Center Reporting in SAP GL

To maximize the reporting power of the SAP General Ledger, I recommend that you consider using a cross-company code profit center structure, but to be effective the company codes must belong to the same controlling area (Figure 5). Despite the profit center being a key component of the SAP General Ledger, in essence, it is a CO object, not an FI organizational element. Therefore, it is highly dependent on its controlling area assignment. Even if you do not assign profit centers on a cross-company basis, when you create your profit center hierarchy, you are limited to selecting profit centers from a single controlling area. You cannot configure cross-controlling area hierarchies.

Figure 5

Cross-company profit center structure

Enterprise-wide CO Reporting

CO standard reports and users’ report writer reports are limited to a single controlling area. If you have multiple controlling areas and want to report on enterprise-wide CO data, you need to write custom Z reports to report across multiple controlling areas.

Enterprise-wide Allocations

A multicompany controlling area enables cross-company code allocation of overhead. For example, a corporate group has a central shared services organization, which is a separate company code that allocates its cost across all group companies (Figure 6).

Figure 6

Cross-company allocation

Cross-Company Settlements

In CO it is standard for you to be able to settle cost from one CO object to another as long as they are in the same controlling area, even if they belong to different company codes. Why would this rather esoteric functionality be of benefit to you? Consider the following examples:

Scenario 1. Manufacturing in a different company code to the sales company (e.g., separate manufacturing companies supplying a single marketing company within an enterprise). In this scenario, you have a make-to-order production order in one company code settling to a sales order in another company code.

Scenario 2. A service provided by a different company code to the sales company code (e.g., central service company code separated from the marketing company). This scenario is very common in Europe where a principal-commissionaire structure is used for sales, to help minimize taxes. In this scenario, you have the service order in one company code settling to a sales orderor contract in another company code.

Scenario 3. Production operation in a different company code to main production company code (e.g., a specialist subcomponent manufacturer). In this scenario internal activity allocation occurs across company codes.

All of the examples of cross-company logistics processes described in these three scenarios can occur only if both company codes belong to a single controlling area. For more details of cross-company controlling see the article by Marco Jordy, “Don’t Wait Until After Go-Live to Set Up Cross-Company Code Controlling.”

Enterprise-wide Costing

Cross-company costing is only possible within a controlling area. If the Cost Across Company Codes indicator is active (Figure 7), the system searches for an existing cost estimate in accordance with the valuation strategy within the controlling area, regardless of company code, prior to re-costing. To activate this functionality, use transaction OKYV.

Figure 7

Cross company costing configuration

Transfer Pricing Using the Material Ledger

Using the SAP standard model for transfer pricing based on the material ledger, all transfer pricing postings occur within a single controlling area. It is not available for transfers between company codes in different controlling areas. This is important if you need a true group or profit center valuation of inventory.

Often the requirement to implement group or profit center valuation drives the need for conversions, such as during these scenarios:

• Merging controlling areas
• Changing FI-GL currency types
• Activating second or third local currency in FI-GL
• Changing ML currency types

The need for system changes occurs as material ledger implementation is often a phase 2 or 3 activity after go-live, rather than an initial key module. Despite this later implementation, the material ledger for transfer pricing is highly dependent on configuration made at go-live (e.g., the controlling area structure and currency type assignment to company codes).

Requirements

To allow company codes or controlling areas to be merged, the following requirements must be met:

• All company codes and the controlling area must use the same chart of accounts.
• All company codes and the controlling area must use the same fiscal year.

If these requirements are limitations to your controlling area merger, these settings can be changed at the same time as the controlling area merger as part of the conversion process

In general the above requirements help support good group reporting, applying consistency across group companies. Local reporting requirements such as local fiscal years or local chart of accounts can be met with existing GL and CO functionality, (e.g., non-leading ledgers, alternate chart of accounts, or the special-purpose ledger [FI-SL]).

Configuration Changes

When you reorganize your controlling areas you need to consider the impact on configuration. Many items of CO configuration are by controlling area, not company code. Therefore, when you merge controlling areas you need to consider any clashes in configuration. There are multiple approaches to the dealing with overlapping configuration:

• Define one source controlling area as primary source of configuration for the merger
• Define different source controlling areas based on the configuration table
• Adjust configuration as final step of merger
• Adjust configuration as a pre-merger step
• Develop a hybrid approach

The key point is to review configuration early in the merger project.

Controlling Objects

All CO postings are linked to controlling objects that have unique identifiers. Some of the controlling objects have the controlling area name embedded as part of their unique identifiers. For these types of controlling areas, you need to develop a mapping system to avoid duplicate cost object names. The types of controlling objects that need to be considered are:

• Reconciliation object
• Business process
• Cost center/activity type
• Cost center
• Profit center

Consider the following scenario, in the Cost Center (Figure 8) multiple controlling areas have cost center 1000.

Figure 8

Cost center 1000 exists in multiple controlling areas

What needs to be done on merger to keep the data in the cost centers unique? There are several options for this:

• Define a rule for generating a new cost center number (e.g. add the controlling area as a suffix or prefix)
• Create a new cost center numbering scheme and include the mapping in a Z table so that the conversion process can pick up the mapping

Merging cost centers often is not possible as a cost center must belong to a single company code. An example is shown in Figure 8. Merging all cost centers listed as 1000 into a single cost center 1000 results in only one of the original company codes being able to use cost center 1000 post conversion. This limitation causes issues for transactions in the remaining company codes, all of which need to be mapped to a cost center that is valid for their company code.

Other controlling objects (e.g., WBS element or internal order) have unique numbering across controlling areas so that no cross-controlling area numbering duplication occurs.

For more information on CO objects, see “Do You Mean ‘CO Object’ or ‘Cost Object’?”

How to Reorganize

With regard to controlling area reorganization or other complex changes in the SAP system (e.g., group currency activation or a change in chart of accounts), note that these configurations are for all intents and purposes set in stone. The only way to change the settings is to reimplement the system. This is a costly and time-consuming option that most users do not consider.

If it is this difficult, why reorganize the controlling area structure? The answer is there are solutions to this issue that are both less expensive and quicker than reimplementing. What you were told was set in stone is actually changeable, with a small amount of effort and specialist knowledge. A company cannot do this conversion on its own. It needs to rely on SAP or a specialized consulting firm. Reorganizing your controlling area structure has the following benefits:

• Extend the useful life of your SAP system
• Avoid the high cost of reimplementing the SAP system
• Maximize return from an existing SAP investment

SAP and specialist consulting firms provide SAP system conversion services that make updates at the database level directly to the existing data in the SAP tables. These updates make the tables look like the new Controlling structure was in place from the initial system go-live. This conversion is in fact a more predictable project than a new SAP implementation, despite it initially appearing to be more complex.

Your controlling area structure can significantly affect the functionality of the CO module. Often SAP users are unaware of this functionality until a year or two after go-live when they really understand the SAP CO concept. However long you have been live with an SAP system, it’s not too late to reorganize your controlling area structure, and it can be achieved as a manageable project.

Rohana Gunawardena

Rohana Gunawardena heads the SAP practice division at Exium Inc. Exium is a leading business and technology consulting firm that enables companies to achieve their strategic business goals. Exium specializes in delivering superior IT solutions using ERP systems, with a special focus on SAP products. Rohana has been working with SAP since 1992. During his career he has assisted multiple clients on detailed system correction projects, such as correcting inventory balances, controlling area reorganizations, retrospectively activating group currency, and optimizing inter-company accounting transactions. He has spoken at many SAP conferences and has published more than 20 articles in Financials Expert, SCM Expert, and SAPtips on various aspects of SAP. His presentations have focused on Financials module selection, the order-to-cash process, global rollouts, business segment reporting, cross-module integration, and the financial impact of SCM transactions. Rohana is widely acknowledged as a leading SAP expert. Rohana is a Fellow of the Institute of Chartered Accountants in England & Wales. Previously Rohana has worked with the consulting practices of Accenture, Deloitte, and PwC.

Rohana will be presenting at the upcoming SAPinsider Financials 2018 conference October 16-18 in Prague. For information on the event, click here.

You may contact the author at Rohana@Exium.com .

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