Search My Blog
 About Suresh

Suresh recently assumed the role of Chief Risk Officer and Managing Director, Advisory Services, of Kamakura Corporation where he heads, develops, and provides Enterprise Risk Management (ERM) and Basel III software and advisory consulting services to its clients worldwide.

 Connect
 Contact Us

Kamakura Corporation
2222 Kalakaua Avenue

Suite 1400
Honolulu HI 96815

Phone: 808.791.9888
Fax: 808.791.9898
info@kamakuraco.com

Americas, Canada
James McKeon
Director of USA Business Solutions
Phone: 215.932.0312

Andrew Zippan
Director, North America (Canada)
Phone: 647.405.0895

Asia, Pacific
Clement Ooi
Managing Director, ASPAC
Phone: +65.6818.6336

Austrailia, New Zealand
Andrew Cowton
Managing Director
Phone: +61.3.9563.6082

Europe, Middle East, Africa
Jim Moloney
Managing Director, EMEA
Phone: +49.17.33.430.184

Visit Us

Linked In Twitter Seeking Alpha
Careers at Kamakura
Technical Business Consultant – ASPAC
Asia Pacific Region

Business Consultant – ASPAC
Asia Pacific Region

Consultant
Europe

Kamakura Risk Manager Data Expert
Europe, North America, Asia & Australia

Client Relationship Managers

North America

 Archive
  

 Suresh Sankaran's Blog
Aug 28

Written by: Suresh Sankaran
8/28/2016 11:35 PM 

Introduction
Cost allocation is the process of identifying, aggregating, and assigning costs to cost objects. A cost object is any activity or item for which you wish to separately measure costs. Examples of cost objects are a product, a marketing campaign, a customer, a sales region, or a department.
 
Cost allocation is used for financial reporting purposes, to spread costs among departments or inventory items. Cost allocation is also used in the calculation of profitability at the department or subsidiary level, which in turn may be used as the basis for bonuses or the funding of additional activities. Cost allocations can also be used in the derivation of transfer prices between subsidiaries.  This document will focus on the use of cost allocations in the derivation of transfer prices between business units, but done at the transaction level, so that associated aggregations (product, customer, centre, and indeed any user-defined “unit”) can be analysed with ease.
 
Cost allocation is important because it the process through which costs incurred in bringing a certain product to market or rendering a certain service is calculated. If costs are not accurately calculated, a business might never know which products are profitable and which ones are losing money. If costs are misallocated, a business unit may be charging the wrong price to its customers and/or it might be wasting resources on products that are wrongly categorised as profitable.
 
Rationale
Organisations allocate costs mainly for the following reasons:
  • To provide information needed for decision making.
  • To reduce the frivolous use of common resources.
  • To encourage managers to evaluate the efficiency of internally provided services.
  • To calculate the full cost of products for financial reporting purposes and for determining cost-based prices.
If any one of these objectives are not met, or if the results generated are purely for review purposes, it may be a better alternative to manage ‘at the margin’, to identify the marginal profitability of each direct unit (business unit, product, customer, transaction, user-defined attribute), and manage these on the basis that if they contribute positively to the unallocated cost pool, they are worth continuing with, and if not, to take appropriate corrective action.
 
Unlike manufacturing organisations which are regulated through cost allocation, financial institutions do not report on GAAP that requires “Full Costing” for external reporting purposes. As a result indirect production costs need not be allocated for services rendered or products delivered. Furthermore, full cost information is not required as there is no need for “Cost Plus” pricing, and the organisation is not mandated to provide any pricing rationale other than not being usurious whereas In the case of manufacturing entities, not only is manufacturing overhead allocated, but so are other general and administrative costs.
 
Generally, as resources are consumed during production, cost allocations are made to the products, departments etc., much like a fee or charge. From a decision making standpoint, the allocated cost should measure the opportunity cost of using a company resource. Unfortunately this is difficult to implement in practice as opportunity costs can change quickly.
 
It may be argued that fixed costs should not be allocated at all. But without charging a fee (or allocating these costs), resources are often used frivolously or for nonessential purposes. Consider fixed costs associated with computer resources. Examples include recreational web surfing, playing games, sending personal e-mail etc.  A way to eliminate frivolous use is to charge for it.
 
Cost allocation is also useful because is causes management to evaluate the services for which they are being charged (e.g. costs allocated to their departments or products). For example, centrally administered services such as janitorial or computer services should be allocated to various departments.  If these services were free and no allocation were made, users would not consider them. But if a charge is levied, management has a strong incentive to evaluate these services and charges and consider alternatives. 
 
An entirely justifiable reason for not allocating costs is that no cost should be charged that the recipient has no control over. Thus, in the African Bongo Corporation example above, the company could forbear from allocating the cost of its power station, on the grounds that none of the six operating departments have any control over the power station. In such a situation, the entity simply includes the unallocated cost in the company's entire cost of doing business. Any profit generated by the departments contributes toward paying for the unallocated cost.
 
Traditional cost allocation approaches
The very term "allocation" implies that there is no overly precise method available for charging a cost to a cost object, so the allocating entity is using an approximate method for doing so. Thus, the user may continue to refine the basis upon which you allocate costs, using such allocation bases as square footage, headcount, cost of assets employed, or electricity usage. The goal of whichever cost allocation method you use is to either spread the cost in the fairest way possible, or to do so in a way that impacts the behaviour patterns of the cost objects. Thus, an allocation method based on headcount might drive department managers to reduce their headcount or to outsource functions to third parties.
 
Cost allocation typically has three steps:
  • Identify the cost objectives
  • Form cost pools
  • Select an allocation base to relate the cost pools to the cost objectives
The first step in the cost allocation process is to determine the product, service or department that is to receive the allocation. The object of this cost allocation is called the cost objective.
 
The second step in the cost allocation process is to form cost pools. A cost pool is a grouping of individual costs whose total is allocated using one allocation base. For example, maintenance department costs might constitute a cost pool. Cost pools are often formed along department lines.
The third step in the allocation process is to select an allocation base that relates the cost pool to the cost objectives. If the cost objectives are products or services rendered, then direct time spent, direct amount spent or product delivery time are examples of characteristics that could be used as allocation bases. Ideally, the allocation base should relate costs to cost objectives.
 
When indirect costs are fixed, establishing a cause-and-effect relationship is infeasible. Therefore, purveyors use other criteria:
  • Relative benefits (the allocation base should result in more costs being allocated to the cost objectives that benefit most from incurring the cost).
  • Ability to bear costs (the allocation base should result in more costs being allocated to products which are more profitable).
  • Equity (the allocation base should result in allocations which are fair and equitable.
Organisational units in most financial institutions are often classified by department; either direct or service. Since service departments, like most head office functions, are support departments, their costs are pooled and allocated to direct departments.
It is recommended that Budgeted rather than Actual service costs should be allocated to direct departments, because, if budgeted costs are allocated, service department inefficiencies cannot be passed on to production departments.
 
Problems with cost allocation
A number of problems may arise when costs are allocated. They may be brought about by:
  • Allocations of costs that are not controllable
  • Arbitrary allocation
  • Allocations of fixed costs that make the fixed costs appear to be variable costs
  • Allocation of overhead to products using too few overhead cost pools
  • Use of  only volume-related allocation bases
Responsibility accounting requires tracing revenues and costs to organisational units and individual managers with related responsibility for generating revenue and controlling costs. Furthermore cost allocations should be consistent with responsibility accounting, and care should be taken to ensure that only costs for which the individual manager has control are allocated; if not, this may lead to disastrous consequences including loss of morale.
 
As might be expected, cost allocation fairness is the topic of heated management discussions. Unfortunately, allocations of costs are inherently arbitrary. It is impossible to determine the “true” or “correct” allocation.
 
Another potential problem is that cost allocation may make fixed costs appear variable. This happens when fixed costs are unitised or stated on a per unit basis. Examples include fixed general and administrative costs like head office function salaries. These costs should be allocated in a lump-sum regardless of total volume. The reason is that as business levels increase, more and more fixed costs are added, despite the fact that, by definition, fixed costs are static and do not change with respect to changes in activity levels.
 
Assigning costs using just one or two cost pools can cause serious product costing distortions. While easy to implement and use, this approach is not as accurate. Ultimately, a cost-benefit decision has to be made. The question is “does the benefit of more accurate allocation methods (e.g. more accurate product costs) outweigh the cost of obtaining this information?”
 
Some financial institutions, in a bid to appear totally mathematical and unbiased, allocate overhead to products using only measures of production volume (labour hours, product delivery time). The problem is that not all overhead costs vary in relation to volume.  This “Traditional Approach” assumes that all costs are proportional to production volume. In reality this is not true. For example, setup costs are not proportional. A setup might work for a 400,000 customer base just as well as a 200,000 customer base. As a result, low-volume items are under-costed and high-volume items are over-costed.
 
The ABC approach
In the Activity-based costing (ABC) Approach, financial institutions identify the major activities that cause overhead costs to be incurred. Some of these are related to production volume, but others are not. The steps are as follows:
  • Identify activities.
  • Group costs of activities into cost pools.
  • Identify measures of activities (the cost drivers)
  • Relate costs to products using the cost drivers
Activity-Based Management (ABM) is a management tool with the goal of improving efficiency and effectiveness. It is similar to ABC, except that where ABC focuses on cost measurement, ABM focuses on the activities themselves.
 
 
Cost allocation in Kamakura Risk Manager
Cost allocation within the KRM framework is incorporated through the funds transfer pricing module of KRM, Academic thought process in Kamakura attempts to rationalise overheads as a part of the cost or value of funds rather than as a separate allocation process, as this helps in the pricing of any homogenous structure within the organisation.
 
The first step within KRM is to clearly bring in the support centre amounts and store them in the table that is designed to store all external variables, the EXPLVARS table.  This ensures that all support costs, correctly captured, are now in one central location, ready for allocation. 
 
 
Since the data in this table is stored by date, the user can bring in information relating to prior months, budgets, and forecasts so that easy comparisons can be made.  This feature is not available within traditional cost allocation processes, as most systems can only support one allocation process.  KRM, on the other hand, through its disassociation of cost allocation from traditional profit source segmentation structure, can give the user the immense flexibility of loading actual costs, budgets, and forecasts, and allow for the same or different mapping routines to allocate these to direct centres, enabling easy comparison, trends analyses, and so on.
 
The second step within KRM is to bring in those variables that are to be used as factors for the allocation routines.  Therefore, information like number of staff, processing times, physical count of assets like ATMS, and anything that is typically used in the allocation process as a variable can be brought in, again by date, and stored in the same EXPLVARS table.  Now, we have successfully brought in the costs as well as the variables used in the allocation process.
 
The third logical step is to write the allocation rules themselves, and this is done in the FTP adjustments area within KRM.
 
 
The formula builder within KRM contains a rich tapestry of MS-Excel-like formulas that can be used even by beginners to simplify the allocation process from one centre to the other.
 
When setting Transfer Pricing assumptions using the TP Set IDs (TP_PARAM table), KRM allows up to 5 adjustments to the original FTP rate derived by KRM, FTP Adjustments screen (Setup / Transfer Pricing menu, TP_ADJUST table).  These adjustments factors can be defined over time while also using formula functions. It is our recommendation that one adjustment be reserved for cost allocation purposes, and you can create multiple allocation rules within this one adjustment.
 
Since the adjustments are linked at the transaction level, this separates primary Transfer Pricing assumption (methods, curves, etc.) defined by the Transfer Pricing ID from transaction-specific adjustments for liquidity, optionality, reserves, etc., and for allocations as well.  Furthermore, since the adjustments are done at the transaction level, it is imperative that all cost allocations are divided by the number of active transactions within the front-facing or direct centres.
 
The last step within the cost allocation process is to link the transactions of the direct business units to the cost allocation FTP adjustments.  
 
 
The mapping at the transaction level can be done either as part of the ETL (Extract, Transform, and Load) process, or can be done after the data is brought in through a simple SQL query to modify the portfolio table:
 
 
To illustrate, the whole process can be encapsulated as follows:
  1. Let us assume that there are two direct centres A and B, and two support centres C and D.
  2. Let us assume that Centre C is allocated based on headcount, and Centre D based on number of telegraphic transfers initiated.  Centre C has total costs of USD 100k and Centre D USD 250k.
  3. Load into EXPLVARS the following information:
  4. Set up the allocation rules, as specified above.
  5. Run the FTP process for 31 July 2016.
  6. The following outputs will be available in the FTP_OUT table:
This spread is standalone, and can be used to generate any kind of aggregation based on any user-defined field in the portfolio table. 
 
Benefits
  • Apart from getting an allocation cost at the transaction level, the user can generate any kind of hierarchical information on the costs that are to be aggregated, and this information is kept specific to the individual centres, or can be grouped based on any user-defined criteria.
  • The process of allocation can be incorporated across any type of expense, including actual amounts, budgets, and forecasts.  One can also perform ‘what if’ analyses by changing very quickly the methodologies to reprocess results.
  • Whilst the methodologies used are from the profitability generation process, the results themselves are now used in the pricing of transactions, the inclusion of overheads in the FTP framework to encompass ‘all in’ pricing, and the process generates transaction-level results that are meaningful.
  • This process does away with the politics associated with sequential versus simultaneous allocations, complicated allocation routines, and incomprehensible results.
  • The results lend themselves to ‘what if’ pricing.
  • Any mathematical, statistical, or distribution criteria can be used.
  • References can be made to lags, leads, and averages.
  • References can be made to any other dynamic variable.
Reporting
Here are some of the sample output that can be generated after costs allocation through the FTP process.
 
 
 
 
 
Conclusion
The traditional methods relating to cost allocation have become outmoded and are being replaced with risk-related metrics, because of the easy way in which one can incorporate dynamic expense allocation and management.  This means that senior management focus is on materiality, and the unit manager reviews only the controllable expenses.  This makes for good organisational focus, and bodes well for any facet of management control including allocation, review, and comparative review.

Copyright ©2016 Suresh Sankaran

Tags: