In today’s world, companies tend to split their organization into small legal entities. One reason is globalization, which requires separate companies for each country in which you operate. Another reason is that the group can better manage multiple, small entities. Many of my customers separate their sales organization from their production. It is also very common to set up a separate company for each production plant.

SAP manages separate legal entities through company codes, the leading organizational element in FI. In the Controlling (CO) module, the main organization element is the controlling area. A controlling area, as defined by SAP, represents a closed system for cost accounting purposes. This means that you only can carry out all transactions available in CO — for example, reposting of costs — within the boundaries of one controlling area.

SAP allows the assignment of multiple company codes to the same controlling area, known as cross-company code controlling. An alternative is to set up separate controlling areas for each company code. Let’s call that individual controlling. The decision about the controlling area is especially complicated, since no external restrictions (such as legal entities) point to one of the available options. Instead, the decision depends on the functionality required in CO and logistics.

A wrong choice in the setup generates problems in the intercompany processes after go-live. Here is an example: One of my customers has multiple production facilities, each a separate legal entity. In the design phase we found that the plants were completely independent of each other. My customer predicted that this wouldn’t change in the future. Based on that, we implemented individual controlling. Unfortunately, shortly after go- live, the business changed and increased customer-specific production led to a change in the production process of the plants. Now one of the plants produces semi-finished parts for the other plants. Functionality that is now required, such as sales order costing between the plants, is not available because of our choice to implement individual controlling. A merger of the two controlling areas was considered, but found to be expensive. Manual workarounds were implemented as a solution.

To make an informed decision about the implementation of cross-company code controlling, you need to know the prerequisites for having a common controlling area. You also must consider the advantages and disadvantages of each option. Let’s start with the prerequisites for cross-company code controlling.

Chart of Accounts

All company codes assigned to the controlling area need to use the same chart of accounts. This is necessary since SAP reuses FI account numbers as cost elements in CO.

This SAP requirement means that all accountants use the same account numbers when posting a document. It is not enough to use SAP’s group chart of accounts functionality, which allows each company to have its separate set of accounts and link them to the account numbers of the group.

Most of my customers didn’t have a full-blown group chart of accounts, but only a common reporting structure, which each company had to fill at month-end with its numbers and send to headquarters for consolidation. My customers needed to create this group-wide chart of accounts first. You should not underestimate the time spent on this controversial topic. Tackle it early in the project, perhaps in a separate working group.

When the system is rolled out and more and more company codes come on board, you have to address the conversion from the local chart of accounts to the group chart of accounts in each rollout. Believe me, the finance department will not like the idea of learning a whole new set of accounts.

Fiscal Year Variant

All company codes must use the same fiscal year variant, which defines the month in which your fiscal year starts. Many companies start in January, having a fiscal year identical with the calendar year, but others choose to start in another period to ease year-end closing. In my experience, the group usually defines when a fiscal year starts and all companies within the group adhere to it. That’s why this prerequisite usually does not pose a problem in the implementation.

The fiscal year variant also defines the number of special periods used for year-end closing. SAP offers a maximum of four, which I propose you use in cross-company code controlling. Next I’ll discuss the advantages and disadvantages of cross-company code and individual controlling. Let’s start with the most important issue: the effects on the available functionality in logistics. Cross-company code controlling has strong advantages here. Many processes are only available when cross-company code controlling is active.

Group- Wide Product Cost Estimate

If you need a group- wide calculation of production costs without intercompany profits, you have to use cross-company code controlling. This issue was the deciding factor for most of my customers who started to use cross-company code controlling.

Because their organizations are broken down into so many small entities, the entities are linked in their production. Standard materials produced in one plant might consist of half-finished products from other company codes. The companies sell one another semi-finished products with a profit. Therefore, the cost estimates for the end products contain those profits.

It is very interesting for the group to know the production costs of their products without those profits (e.g., for group-wide profit margin analysis). SAP’s product costing functionality works only within one controlling area. Choosing cross-company code controlling allows you to calculate product cost with and without intercompany profits. In Customizing, use transaction OKKN (costing variants) to define it in the screen shown in Figure 1.

Figure 1

Activate cross- company costing within costing variants

This becomes more important within a customer-specific production scenario. If you divided your organization into sales and production companies, or if multiple production companies contribute to the production, you need to know the production costs of non- standard material to give a sales price to the customer. You can use the cost estimate functionality in the sales order to calculate the costs. This functionality only works within companies that have the same controlling area.

Associated Plant Functions

The function Production in alternative plant allows logistics to reference a material consumed in one plant to the plant where the material is actually produced. The transfer of the product happens through material transfer postings in Materials Management (MM) without using purchasing functionality such as transfer orders (Figure 2). The function Operation in associated plant allows you to include an operation carried out in another plant as a step within a routing (Figure 3).

Figure 2

Special procurement indicator 80 – Production in alternative plant within MRP 2 view of material master (transaction MM02)

Figure 3

Process Operation in associated plant triggered by assignment of work center from different plant in routing (transaction CA02)

Both processes work only between companies sharing the same controlling area. However, these two functions are usually not very important for your decision. For a couple of reasons, most of my clients do not use these two processes between plants of different companies. The first is that these processes are unable to generate tax postings. You also are not able to realize profits between the company codes. In the case of Production in alternative plant, you also have no transfer stock, which you could use to manage inventory currently on the road.

You can use these three logistics functions — Group-wide product cost estimate, Production in alternative plant, and Operation in associated plant — between company codes only if you choose cross-company code controlling. They are not available in individual controlling. In case you need just one of those processes, or you might need it in the future, you should choose cross-company code controlling.

Let’s discuss additional advantages and disadvantages within the CO module.

Controlling Processes Between Company Codes

CO processes from one company code into another are allowed only if they belong to the same controlling area.

These processes include:

• Allocation of costs between cost centers
• Direct or indirect activity allocation
• Settlement of projects or orders
• Transfer prices

This means, for example, that you only can settle costs incurred on an internal order in one company to an asset of another company when both company codes share the same controlling area.

You must report all these postings to FI using SAP’s reconciliation ledger function. Note that your SAP system cannot generate tax entries in those postings.

You have to decide based on your own requirements if this is a deciding factor for you to choose cross-company code controlling. For some of my customers the inability to generate tax entries made cross- company code processes in CO useless for them.

Companies that decide on cross-company code controlling for other reasons might want to disallow these cross-controlling processes. See the sidebar, “How to Prevent CO Postings Between Company Codes,” on the next page, which shows you how to implement the necessary checks in the system. The issues discussed point above all toward using cross-company code controlling as much as possible. However, you need to consider the disadvantages.

Currency Issues

The issue of use of controlling area currency versus company code currency is only relevant if you have company codes with different currencies assigned to the controlling area. If this is the case (e.g., production plants in Canada and in the US), you need to pick one of the currencies as your controlling area currency.

All postings in CO are stored in three currencies — the transaction currency, the object currency, and the controlling area currency. In the case of cross-company code controlling, the currency of the company code is always stored as the object currency.

One disadvantage is that all CO reports predelivered by your SAP system by default show controlling area currency. However, you probably want to enable local controlling departments to show their local currency. You can accomplish this in two different ways. The first alternative is to change the report currency in the user setting of transaction RPC0 to Object Currency (Figure 4). The disadvantage of this option is that you have to ensure that all new users are set up this way. The second alternative is to copy and adjust all standard reports you want to use, which is very easy — you just have to change the basic key figures you use in your reports to the equivalent ones in object currency.

Figure 4

Change user’s report currency in transaction RPC0

A similar disadvantage occurs in planning functionality. To enter plan data, you need to use planning layouts, which define the screen layout you use for plan data entry. For example, you use transaction KP06 for cost center planning. You can enter planning data either in company code currency or controlling area currency. Which one you enter is defined in the layout. All SAP-delivered layouts are based on controlling area currency. Using cross-company code controlling, you need to change those layouts to allow planning in company code currency (Figure 5).

Figure 5

Change planning layouts via transaction KP66

Exchange Rate Conversion

SAP converts every posting that hits CO from the company code currency into the controlling area currency at the time of the posting. To do that, it uses the conversion rate from SAP’s exchange rate table. In reality, I find that companies usually are required to convert their P&L and balance sheet values into group currency based on an exchange rate that the group controlling department defines for each month. This exchange rate is not known at the time of the posting. Therefore, the values stored in SAP in controlling area currency might not reflect the correct figures. The CO values in controlling area currency often are not used for group reporting.

Authorizations

Many companies want their controllers to see only the numbers for their local company, not for the whole group. Usually, authorizations check the controlling area. In cross-company code controlling, all company codes are assigned to the same controlling area. Therefore, you cannot use the controlling area to restrict this access. Instead, you need to define authorizations based on the cost objects. This complicates the authorization concept somewhat, but you still can manage the process. You can use the following authorization objects to restrict access in a cross- company code environment:

• Authorization based on cost centers: K_CCA
• Authorization based on internal orders: K_ORDER
• Authorization based on profit center: K_PCA
• Authorizations based on activity-based costing: K_ABC

Segregation of Period-End Closing Routines

Each month-end, you perform period-end closing steps such as cost center distribution, results analysis, and order settlement. These programs select data by controlling area. However, closing operations are usually in the hands of local controlling departments. Having only one controlling area makes it harder to segregate those departments. This does not mean that it is impossible. You have to fill the selection criteria of the programs correctly.

For example, in results analysis, you can select the company code, or in cost center distribution you can define allocation cycles separately for each company code. Make sure that the local controlling departments fill the selection criteria correctly. The easiest way is to set up program variants for all closing routines and company codes.

Activate CO Components

You define in Customizing which CO components (e.g., Profit Center Accounting, Cost Center Accounting) you activate. This Customizing setting is done by controlling area. That means that all company codes assigned have to use the same CO components.

Search Helps

Search helps (formerly called matchcodes) help users find the cost objects they want to post to. These search helps show all objects that exist in the controlling area. Assigning multiple company codes means extending the value list of the search helps. For example, a search help for cost centers shows all cost centers of the group, not only those of the local company. The same is true for the search helps of all other cost objects. The local accountants are interested only in the cost objects of their company. To solve this issue, they either can use search helps that include the company code (which only some provide), or include an identifier for the company code in the number of the cost object. You should check if it is necessary to add additional search helps that contain the company code as selection criteria.

Customizing Settings

Many Customizing settings depend on the controlling area, but not on the company code. Order types for internal order are a good example. In cross-company code controlling, all companies share the same order types. This restriction automatically leads to harmonization and to the use of the same concept in the different companies of the group. This might be a disadvantage for groups that have companies that are very different from each other. It’s important to reuse the same settings as much as possible and not to set up, for example, different order types for each company code.

Effects on CO-PA

The decision for a joint controlling area also means that you need to use the same operating concern for costing-based Profitability Analysis (CO-PA). That’s because you can link a controlling area to only one operating concern. This means in turn that all companies need to use the same characteristics for reporting their profitability and the same value fields to report their contribution margins.

It’s important to harmonize the contribution margin scheme for all companies as well as the reported characteristics. If not, you end up defining different value fields and characteristics for all companies. That means in turn that with every document in CO-PA, you have a lot of unused characteristics and value fields (the ones used by other company codes) thereby increasing data volume dramatically.

Selecting an Option

The decision whether to use cross-company code controlling depends on many factors, because arguments exist for both options. Therefore, I can give a recommendation based only on the circumstances of each implementation. The most important factor in your decision should be the processes you require in logistics. Keep in mind that these processes might change in the future. You therefore at least should consider a possible change in those processes in the next couple of years.

The inability to predict the processes the company might use in the future makes many implementation teams unsure in this decision. It’s usually best to decide for cross-company code controlling in these situations. The decision for cross-company code controlling does not restrict any logistics processes. However, as you have seen, it comes with some disadvantages you must address during your implementation.

How to Prevent CO Postings Between Company Codes
Many companies decide to implement cross-company code controlling, but are afraid that it might lead to erroneous cost allocations between companies. You have to distinguish between postings coming through the FI interface (e.g., FI documents, SD invoices, MM material consumption, vendor invoices) and postings within CO (e.g., repostings, cost allocations).

For all postings coming through the FI interface, the system checks if the company code entered in the posting is the same company code to which the CO object is assigned. In case the company codes differ, the system issues error message KI100 - The CO account assignment object belongs to company code XXXX, not YYYY (Figure A).

Figure A

Error message in FB50 preventing cross-company code assignment

This check is controlled by Customizing setting Company Code Validation in the setup of the Controlling Area (Figure B).

Figure B

Activate check preventing cross-company cost assignment

Only if the check mark in the CoCd Validation field is set does the system check if the cost object assigned in the document line has the same company code in its master data as the FI document itself. The check mark in the CoCd Validation field is defaulted in the SAP standard delivery; therefore, you do not have to fear that your accountants mistakenly will assign a wrong cost object. You can change this message from an error message to a warning in Customizing via transaction OBA5 (change message control), as shown in Figure C. I do not recommend you do that. Rather, I advise you to review this Customizing setting during your implementation.

 

Figure C

Change system message KI100 from an error to a warning message via transaction OBA5

Error message KI100 is displayed only in postings coming through FI, not in CO internal repostings and cost allocations (e.g., reposting of costs between cost centers, distribution, or assessment). The system generally allows these postings, which is a risk. To prevent them from happening, you can use a validation rule.

To do that, use transaction OKC7 (change validation). Create the validation for call-up point 2 – Internal CO posting: send/recip. val. SAP predefines the available call-up points. The system executes call-up point 2 when a CO internal reposting between two cost objects occurs. Within the validation, compare the company code of the sender with the one of the receiver in the check rule. If they differ, issue an error message (Figure D). After defining the validation, you need to activate it in transaction OKC7 for the respective controlling areas.

Figure D

Create a validation to prevent cost allocation between company codes