Even when perfectly homogeneous cost pools can be defined, another problem may arise in practice. In principle, you should use as allocation base a measure of the underlying cost driver. Unfortunately, such a measure may not be readily available and too expensive to obtain. The selection of an allocation base is also the result of a trade-off between accuracy and cost of measurement. Architects of cost systems may thus have to rely on less perfect but more affordable surrogates as allocation bases.
For instance, it may be too expensive to place an energy meter on each machine to record energy consumption every time the machine is used. But if energy consumption is proportional to the duration of machine usage, you can use machine time to allocate costs without loss in accrue. Now, machine time may also be too expensive to measure because there is no on-board electronic system and you have to record time manually. But if every batch processed requires the same machine time, you can use the number of batches processed as allocation base. If every batch is made of the same number of units, the number of units produced can be used as allocation base. If you always produce the same number of units per working day, the number of working days would also be an accurate allocation base.
Solution. D, B, C, A. D is the least expensive because you only have to count the number of batches sent to production, a count which is probably already available because it is needed for other purposes. B requires a specific record for the sole purpose of allocating maintenance costs, so it implies an additional cost. But this cost is low since it is only about counting a number of interventions. C is more expensive because it requires keeping a record of when each intervention starts and when it ends. Finally, A requires separate time records (start and end) for each technician involved on each intervention.
A key point in the preceding examples is that every time you can make an additional assumption (another “if”) about the pattern of resource consumption, you can simplify measurement and make it less expensive. Reciprocally, the simpler and the less expensive the measure, the more assumptions it makes about the underlying patterns of resource consumption. Now, as long as all the assumptions made by a particular metric used as allocation base are valid, allocation can be less expensive without loss in accuracy.
Following this reasoning, Activity-Based Costing distinguishes between transaction drivers, duration drivers and intensity drivers based on the number of assumptions they make. Transaction drivers consists in recording the number of times an activity is triggered (e.g. number of batches processed). They can be used when each transaction makes essentially the same demands on resources (same duration, same intensity). Since it consists in counting a number of occurrences, it is relatively inexpensive. However, transaction counts become extremely inaccurate when each occurrence consumes a different amount of resources.
One way to circumvent that problem is to define a greater number of activities (e.g. number of bread batches and number of pastries batches instead of a global number of batches). But this also increases costs as more counts have to be kept. Another way is to use duration drivers which represents the amount of time required to perform an activity. Since it requires measuring time and not only counting interventions, it is more accurate but also more expensive. Moreover, it still assumes the same consumption of resource per unit of time spent on the activity. When the latter assumption is not reasonable, a detailed record of resources consumed should be kept at every intervention. This intensity driver is by far the most expensive measurement method which is almost equivalent to tracing costs.
Knowing whether a metric can be used as allocation base thus requires a good knowledge of the production process. Or a measure can be made valid by coercing operations (forcing every batch to work at the same temperature and as much time). But the latter is rarely a good idea…
Please indicate how clear and understandable this page was for you: