The case for Activity-Based Costing (ABC) goes something like this: Traditional accounting methods do a good job of calculating product costs for the purposes of inventory valuation for financial statements, but a poor job of allowing a cost accountant to validate the cause-and-effect relationship assumptions on which managers base their daily decisions.

Most accounting systems can attach direct costs such as material and labor costs to the product, but resort to fairly arbitrary methods when it comes to assigning indirect costs to the product. These costs include procurement, quality management, maintenance, transport, shipping, and so on. The same accounting systems might apply sales and administration costs arbitrarily to the company’s customers, brands, or product lines. The problem is not confined to manufacturing. A service organization also needs to constantly evaluate its pricing and customer targeting decisions.

ABC, it is argued, moves away from arbitrary methods of cost assignment by asking what causes the costs to be incurred. For example:

• Instead of treating purchasing expense as a percentage overhead, an ABC practitioner would ask whether components are beingspecially procured for some products, where others use standard components.
  
  
• Instead of treating sales as a percentage overhead, an ABC believer would ask whether the customer requests complex configuration before placing an order or simply accepts a standard product.
  
  
• Instead of using an assessment cycle to distribute customer service costs to all segments equally, an ABC site would ask which customers regularly change their orders, order in unusual lot sizes, call the hotline, or need to be chased for payment.

Having determined the activities being used, the ABC concept is to put a price on these by asking what resources are used to perform the activities — how many minutes the hotline takes to handle an inquiry, how many hours a sales rep takes to make a quotation, or how many hours purchasing uses to procure those special components.

The purpose of my article is to help explain a couple of confusing points in regard to the terminology you would read in an ABC book, as compared to the terminology you would find in the ABC module’s (CO-OM-ABC) official documentation and menu paths in R/3. I believe that this word-choice conflict is the reason that a lot of SAP sites ignore or avoid even testing out the functionality in a sandbox system. At a minimum, if your site does not currently use any part of the CO-OM-ABC module, by the conclusion of this article you should have a much greater ability to take another look at what R/3’s ABC could do for you. Perhaps you will start experimenting with it as a way to form your own opinions on whether it could be useful to your site.

I hope it helps you to see how you can use CO-OM-ABC to move from “theory” to “practice,” and that if you are involved in an ABC project, you won’t find yourself coming home in the state I did on my first project. “How did it go?” asked my husband. “We never talked about ABC at all. We only talked about terminology!” I responded.

Textbook ABC Vocabulary

The textbooks on the most commonly used ABC methodology have a couple of vocabulary words worth mentioning before I turn my attention to the CO-OM-ABC module in R/3. These include “resource,” “activity,” “cost object,” “activity driver,” and “resource driver.”

The flow of incurred expense from resource to activity to product/customer is often shown as a cross (Figure 1). Shown this way, it is perhaps easier to see that ABC is about calculating resource costs, activity costs, and product/service/customer costs.

At the bottom of this cross are the “cost objects” — the products, services, and customers whose profitability is being determined. In the middle are the “activities” being performed to manufacture the product and serve the customer. At the top are the “resources” being used to perform these activities. The “activity drivers,” such as the number of calls made to a customer or the number of late payments, link the activities to the cost objects. Finally, “resource drivers,” such as the number of labor hours, link the resources to the activity.

Figure 1

The flow of incurred expense

Vocabulary in R/3

Moving from textbook ABC to CO-OM-ABC can be confusing and frustrating, not least because of the terminology issues.

Let’s start with the menus. Open up the ABC menu; you find something called a “business process” under master data. Is this the “activity” the textbooks talked about or something different? There are several menus for Cost Object Controlling (CO-PC-OBJ). Are the “cost objects” under master data the “cost objects” in the textbooks? What if you are not using logistics? What are the cost objects then? And where are the customers, brands, product lines, and regions the textbooks talked about? Why are resources only in the Production Planning (PP) menu?

If you abandon the menus and turn to the R/3 glossary, the situation is similar. One definition of “resources” does refer to CO-OM-ABC, but two more definitions just confuse you. You learn that the resource you found in the PP menu is actually a work center, and that a resource can also be an item in a cost estimate. Look up “activity,” and you learn that activities are tasks in networks for projects and in plant maintenance, but are not apparently used in CO-OM-ABC. A definition of cost objects in CO-PC-OBJ refers to production orders, product cost collectors, sales orders, and projects. As a bank or service provider, you find yourself asking whether there is a cost object for you.

Fortunately, first glances can be deceptive. I’ll attempt to clear up some of the confusion, while providing you with the real questions you should be asking about CO-OM-ABC.

Let’s start with the cost objects. There is plenty of confusion surrounding the word “cost object” in R/3. Even in German, SAP uses it in a narrower sense than is taught in the German business schools.

Cost Objects in Cost Object Controlling

The CO-PC-OBJ module is used to calculate costs for production orders, sales orders, and so on. If you are using the PP or Sales and Distribution (SD) modules, it is important to understand which cost objects are being used in your organization. This is because each cost object has its own environment for ABC with its own set of functions relating to that particular type of cost object. The type of cost object affects the type of activities you are likely to encounter. Thus, you might map the costs of production scheduling to the production orders or the cost of customer-specific configuration to the sales orders.

Which activity drivers are available depends on the type of cost object you are using. For example, if you are using a production order, you can access production-related quantities such as the quantity of goods manufactured, scrap quantities, or rework quantities, or you can read the number of non-standard components in the bill of material. For a sales order, you can access sales-related quantities such as the order quantity. The term “hierarchy of activities” you may encounter in textbooks typically refers to the batch-specific and unit-specific activities that are mapped to the cost objects in CO-PC-OBJ.

Cost Objects in Profitability Analysis

Arguably, the more important cost objects for the purposes of ABC are not in CO-PC-OBJ at all. The products, services, and customers whose costs you are trying to determine are typically the profitability segments in Profitability Analysis (CO-PA). Even when you think you are looking at product costs, you may still find yourself mapping these activities not to the product cost estimate, but to CO-PA, simply because you do not want these costs to be included in inventory valuation.

Before I look at inventory issues, let’s consider CO-PA as an application. CO-PA in R/3 is a multidimensional cube with segments that represent the products, the product groups, the customers, and the customer groups. Organizations implementing CO-PA generate their own operating concern during customizing, so there is no such thing as a standard CO-PA. To return to the “hierarchy of activities,” product-sustaining activities map to the profitability segment for the products and channel-sustaining activities map to the profitability segment for the sales channel.

At this stage it is important to understand the impact of this multidimensionality. Many activities map not to one characteristic, but to an intersection, such as the combination of product, customer, and region. Some activities, such as configuration for a sales order, are very specific, while others, such as development or marketing activities, map to aggregates in CO-PA, such as a product group or a customer group.

There is only one environment for ABC in costing-based CO-PA. This differs from the cost object environments because the CO-PA operating concern is always customer-specific, and R/3 cannot know in advance what functions are likely to be required. Therefore, when you generate your environment for ABC in CO-PA, you are asked which characteristics you want to use and which value fields, such as the sales volume or the number of transactions handled, you wish to access.

Inventory valuation concerns can also lead to confusion in the area of cost objects. Because the product cost estimate is the basis for stock valuation in FI, the costs of developing, marketing, and shipping the product may be mapped not to the cost estimate, but directly to the profitability segment for the product. This is because it is generally considered unfair to include these costs in inventory valuation. If you consider the cost of handling engineering changes, it may be the changes to the bill of material and routing that are being counted, but it is unfair to burden one particular production order with the costs of the change. Instead, the costs are charged to the profitability segment for the product.

Alternatively, product-related activity costs may be mapped to the product cost estimate but flagged as not relevant for inventory valuation in the cost component structure. Most of the costs to serve a customer are not considered part of the cost of goods sold for the financial statements, and so they are mapped to the profitability segment for the customer.

Cost Objects for Internal Services

You may find that your activities do not map to CO-PC-OBJ or CO-PA at all, but back into Cost Center Accounting (CO-OM-CCA). This is often the case in a shared service scenario, where the activity is not being performed for a customer or product, but as an internal service. Examples here include handling business trips, hiring staff, or installing software. CO-OM-ABC is used to calculate the prices of one unit of each activity, and the costs are then assigned to the cost centers in accordance with the number of staff hired or software updates performed for this department. In this case, the “activity” itself becomes a product or service, and the organization uses CO-OM-ABC to build up a service catalog, price each of the services available, and charge these costs to the department using the service. To model this sort of scenario, you need neither CO-PC-OBJ nor CO-PA, but only CO-OM-CCA and CO-OM-ABC.

Activities

Moving on to activities, SAP contributed to the confusion by introducing the term “activity type” in the early days of R/3. When CO-OM-ABC came along, the term “business process” was coined for activities and the confusion was complete. So are your activities really activity types or business processes?

In the context of ABC, there are actually two sorts of activity types. Organizations that have implemented the R/3 SD, PP, PS, PM, and SM logistics modules are already using activity types in their routings, networks, and maintenance plans. Often they have only a handful of activity types — typical ones being machine hours, labor hours, and setup hours. The costs for these activities map to the cost objects sales order, production order, network, maintenance order, or service order.

The other sort of activity type is a “resource driver” in ABC terms. This is the sort of activity type that exists in combination with the resource (cost center) — for example, labor hours from sales or marketing. Organizations can then use either direct or indirect activity allocations to map these costs either to a business process or a profitability segment.

The “activities” you met in the ABC textbooks are the business processes. These represent activities such as handling customer complaints or inquiries or procuring special components. The technical difference with respect to an activity type is that business processes can use resources from multiple cost centers. They have their own process capacity, such as number of possible calls per month, and a process price. It makes sense to model activities as business processes whenever the activity crosses more than one cost center.

However, CO-OM-ABC can use both business processes and the combination cost center/activity type to map “activities” to profitability segments or cost objects. Note also that while ABC textbooks imply that activities are always consumed by cost objects, you can model activity-to-activity and activity-to-resource relationships in R/3. This is particularly important for support activities that enable product- or customer-related activities to be carried out.

Resources

The resources in the CO module are the cost centers. Most costs enter the CO module from FI assigned to a cost center — notable exceptions are material costs in CO-PC-OBJ and direct sales costs in CO-PA. Those costs that are not linked with activities in a routing, for example, are then assigned to products using overhead surcharges or to the profitability segments using assessment cycles.

Implementing CO-OM-ABC always involves revisiting the premises behind CO-OM-CCA, and this can be confusing. In a stand-alone ABC tool, users start in the general ledger and map costs to resources. In R/3, salaries, wage costs, and depreciation enter the CO module from FI already tied to a cost center with the profit and loss account represented as a cost element. Where it makes sense, you can also assign costs directly to a business process. The good news is that you should not have to change any logic concerning how costs enter the CO module.

Implementing CO-OM-ABC mainly involves changing how the costs leave the cost center, because you are defining activity types as resource drivers for all relevant cost centers and mapping combinations, such as labor hours in sales to the relevant business processes.

Resource/Activity Drivers

You will find the term “cost drivers” in the R/3 glossary, but you will search in vain for the terms “resource drivers” and “activity drivers.” They may be the heart and soul of ABC, but in R/3 they are hidden in the quantity columns in the template. The number of potential drivers in R/3 is huge: statistical key figures in CO-OM-CCA, such as number of employees or square footage; value fields in CO-PA, such as sales volume or number of transactions; key figures in the Logistics Information System, such as number of sales orders or number of purchase orders; quantities in the bill of material, such as number of non-stock items; or quantities in the routing, such as number of work center changes or workflow quantities. One of the keys to successful implementations is to use quantities that are already being tracked in R/3 as resource and activity drivers for ABC.

Templates

The word you won’t find in the ABC textbooks, but will need for finding your way through the CO-OM-ABC documentation, is “template.” The template is the glue that links the resources, activities, and cost objects. It specifies that a product needs special procurement activities for some components and a production scheduling activity. It defines the customer care activities required for a customer group. It may help to think of it as a non-production routing, but it differs from a routing in that it is not attached to a single cost object, but can apply to several. Selection for Product Costing is via the overhead key in the material master and via a combination of freely selectable characteristics for CO-PA. Each business process can have its own template that defines how many labor hours are being provided by each cost center involved in the process. Templates can also be used to define value flows between cost centers.

First Steps in R/3

Most textbooks define the implementation procedure for ABC in four steps:

1. Define activity dictionary.
2. Determine how much the organization is spending on these activities.
3. Identify the organization’s products, services, and customers.
4. Select activity cost drivers that link the activity costs to products, services, and customers.

I will now show you where to find these steps in R/3.

Step 1: Define the activity dictionary. The activity dictionary in R/3 is the business process hierarchy. This is similar to a cost center hierarchy. It is simply a grouping of all the “activities” you intend to use for ABC. You can access this using Accounting>Controlling>Activity-Based Costing>Master Data>Standard Hierarchy>Change. In this hierarchy, you can see who is responsible for each business process, and you can access the master data for each of the business processes. Figure 2 shows a sample business process hierarchy from an IDES system.

Figure 2

Sample business process hierarchy

Step 2: Determine how much the organization is spending on these activities. You can use several methods to determine how much your organization is spending on its activities in R/3: assessment cycles, indirect allocation cycles, and template allocation. Assessment cycles and indirect allocation cycles are fairly rough and ready in that they split either an amount (assessment) or a number of hours (indirect allocation) on a cost center to several business processes. The template is the nearest thing to a non-production routing, allowing you to map any cost center/activity type or business process to the business process. It is entered in the business process master record, rather than being dynamically selected. To create a template, go to Customizing and choose menu path Controlling>Activity-Based Costing> Templates>Maintain Templates and select the environment SBP. Figure 3 shows a sample template for the assignment of cost center/activity types to the activity, “Process Complaints.”

Figure 3

Template for processing complaints showing the number of hours used for each complaint

Step 3: Identify the organization’s products, services, and customers. An organization that has implemented CO-PA has already completed this step. It has defined the characteristics that are relevant for its analyses — for example, customer, customer group, product, product group, region, brand, and sales office. For ABC, you need to generate additional tables for each of the relevant characteristics for your allocations. You may also need to go back to CO-PA and activate additional characteristics, depending on the granularity you need for ABC. To access this step in Customizing, choose menu path Controlling>Profitability Analysis>Flows of Actual Values>Transfer of Overhead> Set Up Template Allocation>Generate Template Allocation for CO-PA. Once you select the operating concern, you are asked which characteristics are relevant for your allocations — Customer group, Division, Sales Organization, Distribution Channel, Plant, Customer, and Product in this example.

If you want to assign activities to sales orders or production orders, you need to find out which environments are relevant for your organization. There are additional environments for banking that you will not find in standard R/3. (See Table 1.)

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.