# How Traditional Costing Methods Hinder the Development of Modular Product Architectures
## 3 Literature Review
### Methods for Allocation of Costs Related to Product Variety  
Several costing methods exist. In practice, they are embedded in costing systems to support companies in tracing cost objects, such as products or services [36]. Cost objects will traditionally incur two distinct types of costs. First, direct costs, such as the cost of direct labor and material costs, which, as a standard practice, are traced and are directly allocatable to specific products or services. These are contrary to the second, indirect costs, where development time, sales, marketing, depreciation, and facility expenditures are not directly allocated to a cost object. Instead, they are divided evenly across products and services through cost-allocation systems [37]. Traditional costing systems, also known as volume-based costing, allocate costs based on units or production volume and primarily operate through direct cost allocation [37; 38]. When it comes to indirect costs, this method is only effective in stable environments with limited product variety and small or fixed indirect costs [27; 36]. Typically, a fixed indirect cost is divided evenly between the cost objects or as a percentage of the direct costs [39]. [PERSON] and [PERSON] [40] developed activity-based costing (ABC) to provide the more accurate and efficient management of overhead costs. The level of activity consumed by a cost object serves as the basis for cost allocation [41]. It has been proven possible to use ABC to estimate an incurred cost as a result of specific design alternatives regarding part commonality [14; 42]. However, ABC has proven challenging to utilize due to its cost- and resource-heavy implementation and the difficulty of maintaining and updating the model [36; 43]. Reviewing the problems associated with the traditional estimation of ABC, [PERSON] and [PERSON] [43] evolved the model into a new approach named Time-Driven ABC (TDABC). It is simpler and more accurate, as it requires estimates of only two parameters: the unit cost of supplying capacity and the time required to perform a transaction or an activity. It delivers on all the same parameters as traditional ABC, with the benefit of eased initiation, maintenance, and updating [43]. However, TDABC is difficult to generalize across different types of products, making it challenging to create a generalizable and holistic tool [18]. Target Costing (TC) is another costing method for determining the allowable manufacturing and component costs of a product before development, based on the potential sales price in the market [7]. Traditional TC is limited to determining the direct costs that arise after the start of production and does not provide a solution for allocating indirect costs [6]. However, in a recent study, [PERSON] and [PERSON] [17] developed an extension to the TC, providing a guide specifically to make technical decisions about modular product architectures based on related costs. Yet, the study is limited to assessing the development cost and production investment and thus advocates for extending or developing a method that can entail various cost elements, including the implication of technical design on costs, and the cost effect associated with interdependencies between products, such as shared components [17]. A review of the above costing methods' implications and limitations reveals that they fail to adequately allocate indirect costs associated with increased product variety and complexity, costs that are critical to informed design decisions [10]. The cost allocations discussed in this section are listed below in Table 1.  
Now, provided we have the costing tools for assessing an increase in process cost, which several studies describe as a direct effect of increasing internal variety [5; 41; 44], also known as complexity cost in a major part of the literature [39; 45], enables the evaluation of individual product variants based on direct and indirect costs. A multitude of methods exist for allocating complexity costs. This is illustrated in the work of [PERSON] et al.