Cost accounting (15)

Tags

, , , , ,

In the previous post, we had a look at how transactions that were recorded in the project module can be used as statistical measure for making cost allocations. This post will introduce two alternative options that illustrate how those allocations can be made.

 

Option 1: Project module

A first possibility how cost allocations between cost centers – based on recorded project hours – can be made is through project costing vouchers. Those vouchers can be realized by making use of a project group that has the ledger integration parameter for hour related postings activated. This is the case for the projects shown in the next screenprint.

Posting the very same hour transactions for the car pool cost center manager that have been recorded in the previous post results in a voucher that is shown in the next screenprint.

The voucher above shows that a project cost account (no. 853100) is – in combination with the operative cost centers – debited. The credit transaction is made on another profit and loss (P&L) account (no. 853200). As the debit and credit ledger accounts are both P&L accounts, no effect on company’s profit arises. However, because of the financial dimensions used, an allocation from the car pool cost center costs to the other direct cost centers occurs. This allocation effect is illustrated in the next figure.

  • A cost price of $180/hour has been setup in the project module for recording the project hours of the car pool manager.
  • From a cost accounting module perspective, the cost allocations made in the project module occur at the primary cost level. That is because the cost allocations are made outside of the cost accounting module
  • The cost center financial dimension of the car pool manager that is credited is set up at the employee level in the Human Resource module.

 

From the previous screenprint, one can identify that some costs remain at the car pool cost center no. 120. Those remaining costs are a sign that the cost price of $180/hour is not sufficient to allocate all costs from the car pool cost center to the other operative cost centers. Provided that the $180 is a market rate (price), the costs remaining on cost center no. 120 can be taken as a sign that the internal management of the car pool is more expensive compared to an external (outsourced) management of that cost center services.

 

Option 2: Cost accounting module

The second alternative for the cost allocation of the car pool cost center costs is the use of an overhead rate policy, which is exemplified in the next screenprint.

Making use of an overhead rate policy requires that a link to the statistical measure allocation base (‘4. PROJ HOURS’) is made (1). In addition, a secondary cost element that records the cost allocations (2) and the financial dimension to which the overhead rate is applied (3) need to be set up.

Most importantly, an overhead rate that is used for the creation of the cost allocations has to be determined (4). In the example shown above, a rate of $190 has been used to differentiate it from the cost rate that has been setup and used in the project module example shown before.

Similar to what has been shown in the previous post, a statistical measure provider template needs to be setup next for the transfer of the recorded project transactions (hours) to the cost accounting module.

The only difference in the setup of the statistical measure provider template used in this post compared to the one used in the previous post is that a range for the newly set up projects has been specified. This is necessary because the hours of the cost center manager have – for illustrative purposes – been recorded twice; a first time at the projects ending with the number 26ff and a second time at the projects ending with the number 27ff.

 

Processing the overhead rate policy through a cost accounting ledger results in the following costs for the different cost centers:

As shown in the previous posts, the next graphic summarizes the cost allocations made and the total costs that remain at the operative cost centers no. 210-250.

Please note that a rate of $190 is not sufficient for allocating all costs of the car pool cost center to the other ones. This can be identified by the $900 that remain at the car pool cost center after the allocations are made.

 

In the next post, we will investigate an approach that makes use of cost allocations in the project module and an overhead rate policy in the cost accounting module. Till then.

Cost accounting (14)

Tags

, , , ,

In this post, we will analyze how transactions – or more general records – that are entered in other D365 modules can be used as statistical measures for making cost allocations.

To illustrate how such cost allocations can be realized the same demo data that have been used in prior posts will be used again. However, this time, the costs of the car pool cost center no. 120 will be allocated to the other direct cost centers based on the hours that the cost center manager recorded in the project module. Details thereof as well as the allocation bases used can be found in the next screenprint.

 

Step 1: Record hours in the project module

For recording the hours of the car pool cost center manager, a project with several subprojects – one for each cost center – has been setup.

All projects used in this post are setup with a project group that does not generate a voucher for hour transactions. This has been realized by making use of the ‘never ledger’ project accounting integration setup. As a result, time recordings made in the project module record quantities only.

In a later post, a different project group will be used for the setup of projects that will result in the creation of ledger vouchers.

 

Step 2: Setup statistical measure provider template

Once all costs are recorded for the different projects, a statistical measure provider template is setup. This template is required to transfer the recorded project hour data into the cost accounting module.

When setting up this statistical measure provider template, one has to select the source table that holds the data, which will be used for the definition of the cost allocation basis. In the example used, the data are held in the ProjEmplTrans table (1). In addition to the table that holds the statistical data, one has to specify (2) the function (sum vs. count), (3) the sum field (hours) and (4) the date field (project date) in order to get the data correctly transferred into the cost accounting module.

 

Step 3: Setup statistical dimension measure

The next required setup for using the recorded project hours as statistical measure in the cost accounting module is the creation of a new statistical member (‘4. PROJ HOURS’), which is shown in the next screenprint.

The statistical dimension measure is needed for establishing a link between the statistical measure provider template and the cost accounting ledger. For details, see further below.

 

Step 4: Setup cost accounting ledger

Thereafter, the cost accounting ledger can be setup in the same way as it has been shown in the prior posts.

Please note the reference that is made to the statistical dimension ‘DEMF STAT ELEMENTS’, which includes the newly created statistical dimension member for the project hours.

 

Setting up the cost accounting ledger necessitates the configuration of the statistical measure data providers. This configuration of the project hour related measure is shown in the next screenprint and requires that a link between the statistical dimension measure (‘4. PROJ HOURS’) from step 3 and the previously setup statistical measure provider template (‘P14_LRE_ProjectHours’) from step 2 is made.

 

Step 5: Create cost accounting policy

Finally, the cost allocation policies can be created. Please note that the cost allocation for the car pool cost center is made on the basis of the project hours recorded.

 

Step 6: Process data and overhead calculation

The outcome of processing the cost allocation policy on the sample data can be observed from the next screenprints.

 

In the next post, we will take a look at the overhead rate policies and how they can be used for making cost allocations. Till then.

Cost accounting (13)

Tags

, , , ,

This post focuses on cost distribution policies and how they differ from cost allocation policies. According to the D365 documentation, cost distribution and cost allocation policies differ in a way that cost distributions always occur at the level of the primary cost element of the original costs.

Applied to the previously used example, cost distribution policies should distribute the costs from the indirect cost centers to the direct ones, as indicated by the arrows shown in the next figure.

To verify this, the following cost distribution policy has been setup:

Please note from the previous screenprint that cost distribution policies also refer to a cost object dimension (‚INDIRECT CC’), as cost allocation policies do. Yet, different from cost allocation policies, a cost element node needs to be specified. The remaining cost behavior and allocation base columns are once again identical to what has been shown for cost allocation policies.

 The cost distribution policy used in this post makes once again use of the previously used employee related statistical allocation base.

After setting up the cost accounting ledger and processing the data and the cost distribution policy, the following costs can be observed from the cost controlling workspace for the different indirect cost centers:

As one can identify from the prior screenprints, some costs remain at the indirect cost centers no. 120 and 130. The underlying reason for this outcome are cost distributions that are made within the group of the indirect cost centers. Those distributions are caused by the employee allocation basis used. The next graphical overview aims to illustrate the underlying issue.

To avoid that costs remain at the indirect cost centers, the cost distribution policy is slightly modified in a way that a hierarchy allocation base (‚DEMF_P13_B’) is used.

 The major advantage of using a hierarchy allocation base is that one can specify to which cost objects cost distributions (or cost allocations) shall be made. In the example shown above, to the direct cost centers (‘DIRECT CC’) only.

Reprocessing the cost distributions with the modified cost distribution policy finally results in the cost data shown in the next figures.

The next graphic has been prepared for a better overview of the cost distributions made.

Before ending this post, please note the following concluding remarks:

  1. The distributed costs won’t be shown as secondary costs even if a cost rollup policy is defined and assigned to the cost accounting ledger.
  2. The same outcome that has been shown above can be achieved by making use of a cost allocation policy that is not linked to a cost rollup policy.

The next post will introduce how to import statistical measure data from other D365 modules. Till then.

Cost accounting (12)

Tags

, , , , , ,

In this post, we will take a look at a more advanced allocation scenario where fixed and variable parts of selected cost elements are allocated from indirect to direct cost centers based on separate allocation bases. The next graphic illustrates the allocation approach applied in this post.

 

Step 1: Setup dimension hierarchy

To get this allocation approach incorporated into D365, the previously used dimension hierarchy that differentiates between direct and indirect cost centers is used once again.

 

Step 2: Setup cost behavior policy

The next setup required concerns the cost center behavior policy of the different cost elements. The following screenprint documents how this setup has been made.

Please note the different fixed percentage rates for the cost elements 853000, 854000 and 855000 from the screenshot shown above. To ensure that no other fixed costs are setup and caught by the allocation policy, an additional cost element dimension hierarchy node (‘DEMF CEH’) – with a fixed percentage rate of 0.00% – has been included in the cost behavior policy rule section.

 

Step 3: Setup hierarchy allocation bases

The third setup step relates to the hierarchy allocation bases that will be used for allocating the fixed and variable costs.

The first hierarchy allocation base (‚DEMF_P12_FIX’) that will be used for the allocation of the fixed costs from the indirect cost centers to the direct cost centers refers to the numbers of bikes produced.

 Please note that the allocation base (‘3. BIKE PROD STAT DATA’) is a statistical member that has already been used in prior posts.

The second hierarchy allocation base (‘DEMF_P12_VAR) also allocates costs to the direct cost centers. However, different from the fixed cost part, the employment related statistical measure (‘1. EMPL STAT DATA’) is used as allocation base for the variable costs.

 

Step 4: Setup cost allocation policies

The cost allocation policy shown next, combines the different ‘pieces’ that have been setup and explained before. Because the setup of cost allocation policies have already been explained in previous posts, no further explanations are made here and reference is made to the previous posts on the new cost accounting module.

 

Step 5: Setup cost accounting ledger & process data

After the cost accounting ledger is created and the costs and policies processed – not shown for reasons of brevity – the following costs can be observed from the cost controlling workspace for the different cost centers used.

 Please note especially the fixed and variable cost columns for the different direct and indirect cost centers.

For a better overview of the fixed and variable cost allocations made, the following graphic has been developed, which summarizes the different costs and allocations for the cost centers used.

In the next post, we will take a look at cost distribution policies and how they differ from cost allocation policies. Till then.

Cost accounting (11)

Tags

, , , , ,

Similar to what has been shown in the previous posts on cost allocations, also this post will shown an allocation technique that makes use of a dimension hierarchy that includes additional summary nodes. The allocation technique shown below will once again be based on the financial data that have been used in prior posts.

However, this time a hierarchy allocation base is setup for making the cost allocations.

The hierarchy allocation base that is setup and illustrated in the previous screenprint defines that the previously used formula – which calculates the total direct costs – will be used as the allocation base for those cost centers that belong to the ‘DIRECT CC’ node of the cost object dimension hierarchy.

This cost allocation base is then used in the cost allocation policy shown next and defines that all cost centers that belong to the ‘INDIRECT CC’ node will be allocated to the operative (‘direct’) cost centers based on the total costs that have been recorded on the operative cost centers.

 Different from what has been shown in part 7 of this series on the cost accounting module, the cost allocations ignore the cost relationships within the group of the indirect cost centers because the hierarchy allocation base specified refers to the ‘DIRECT CC’ node only.

As before, the next screenprints summarize the allocation results.

 Please note that the total costs on the direct or operating cost centers no. 210-250 are identical to what has been shown in part 7 of this series. Yet, a detailed investigation of the allocations made reveals that the allocations within the group of the indirect cost centers are skipped.

In the next part, we will extend the hierarchy allocation base allocation technique and investigate how it can be applied to costing scenarios that make use of fixed and variable costs. Till then.

Cost accounting (10)

Tags

, , , ,

This post continues the previous one in a way that allocations are made once again by referring to summary nodes in a dimension hierarchy. However, this time multiple allocation bases – shown in the next overview graphic – are used for making the allocations.

To realize the multiple base hierarchical allocation approach, a new cost object dimension has been setup that includes three additional summary nodes (‚110 INDIRECT’, ‘120 INDIRECT’ and ‘130 INDIRECT’). In the example used, each of those summary nodes holds a single cost center only.

In practice, each summary node typically holds multiple cost objects that are allocated to other ones by making use of the same allocation base.

 

With the new cost object dimension hierarchy in place, one can then refer to the different indirect summary hierarchy nodes when setting up cost allocation policies. This is exemplified in the next screenprint that shows how the different indirect cost object nodes are linked to allocation bases for cost allocation purposes.

In the example illustrated in the previous screenprint, all cost centers (respectively their costs) that belong to the ‘110 INDIRECT’ hierarchy node are allocated to the operative or ‘direct’ cost centers based on the number of employees working there.

The cost center costs of the ‘120 INDIRECT’ group are allocated based on the number of company cars and the cost center costs of the ‘130 INDIRECT’ group are allocated based on the total direct costs of the other ‘direct’ or operative cost centers.

 This example illustrates once again that previously used statistical measures and formulas can be re-used multiple times in the new D365 cost accounting module. This ability can be very beneficial for example if one wants to run simulations or tests based on previously used allocation bases.

 

As in all prior posts on cost allocations, the next screenprints document the obtained allocations and are summarized in an Excel document at the very end of this post.

In the next post, we will investigate how one can make use of hierarchy allocation bases. Till then.

Cost accounting (9)

Tags

, , , ,

Within this post, we will once again use the financial data that have been used in all prior post on cost allocations.

However, this time all costs that have been accumulated on the indirect cost centers no. 110-130 will be allocated to the ‘direct’ or operative cost centers no. 210-250 by making use of a specific cost object hierarchy setup that is illustrated in the next screenprint.

The major difference to the cost object hierarchies that have been used in the previous posts is that two additional summary nodes (‘INDIRECT CC’ and ‘DIRECT CC’) have been introduced. As those additional nodes summarize the cost centers below, they can be used for cost allocation purposes in the cost allocation policy form, which is shown below.

The cost allocation policy form shown above specifies that the cost of all cost centers that are associated with the ‘INDIRECT CC’ node will be allocated to the other direct cost centers based on the number of employees working for those cost centers.

Please note that the employee data that will be used for making the allocations are the same that have been used in the prior post. Making use of them does not require to import another Excel file with the statistical measure data or something alike. The only thing required is that a link between the statistical measure(s) and the cost accounting ledger is established. As this establishment and the related processing steps are identical to what has been shown in the previous post, those steps are skipped for reasons of brevity. The next screenprints document the allocations that result from the cost allocation policy shown above.

As in the prior posts, the following Excel screenprint summarizes the allocations made together with the basis values that were used for making those allocations.

The next post extends this one and shows how multiple cost object summary nodes can be used for making cost allocations. Till then.

Cost accounting (8)

Tags

, , , ,

This post builds upon the previous one and illustrates a third cost allocation approach that can be used in the standard D365 application. The third approach illustrated below makes once again use of direct costs that were recorded in the financial modules.

This time, the allocations are made based on different statistical dimensions (no. of employees, no. of company cars and production data) that are setup as statistical members in a first step.

Because the statistical data that are used for the cost allocations are not tracked in D365, they need to be imported via the data management framework. In the example used, the statistical dimension member data were prepared in an Excel file that was uploaded through the data management import framework.

The target fields of the respective data entity and the uploaded Excel data are illustrated in the next screenprints.

Once the statistical members are defined and the statistical member data uploaded, the allocation policy can be set up. This time in a way that the costs of the first supporting cost center no. 110 are allocated based on the number of employees working in the other cost centers. The costs of the car pool cost center are allocated to the other cost centers based on the number of company cars used there and the costs of the product management costs are allocated to the other operative cost centers based on the number of bikes produced.

Next, a cost accounting ledger is setup and the statistical measure data provider configured.

This configuration is done in a way that a link to the import source identifier from the uploaded Excel file is made. In addition, a link to the Excel column that includes the cost object data must be established.

As an example, in the screenprint above it is specified that statistical data for the employee statistical measure are imported. Through the dimension mappings field, one can determine the column of the Excel document that holds the cost object data. In the example used that information is tracked in the ‘dimension2’ column. For details, please see the Excel screenprint further above.

Once this setup is made, the statistical measure data need to be processed, that is imported into the cost accounting ledger.

All other processing steps are identical to what has been shown in the prior post and for reasons of brevity skipped.

As in the previous posts, the next illustrations summarize the different cost center costs and allocations.

The next screenprint summarizes – as before – the executed allocations for the different cost centers together with the allocation basis measures that have been uploaded.

In the next post, we will focus on another (hierarchy based) allocation technique. Till then.

Cost accounting (7)

Tags

, , , ,

In the previous post, the costs that have been accumulated on the indirect cost centers no. 110, 120 and 130 were allocated to the other cost centers based on amounts that have been recorded on selected cost elements (ledger accounts 851000 and 852000).

Within this post, we will investigate an alternative, formula-based allocation method that allocates the costs of the indirect cost centers (based on the amounts that have been recorded on multiple cost elements) to the operative cost centers no. 210-250.

As in the previous post, the allocations will be made based on the following accounting data that have been recorded in the finance modules.

To implement the formula-based allocation approach, a formula allocation base needs to be setup first. Setting up this allocation base requires first that an association to the existing predefined allocation bases is made (1). In the example shown below, all cost elements (ledger accounts) that have been used are simply selected and associated with an abbreviated alias.

Once the association to the predefined allocation bases is made, the formula that calculates the allocation base is defined in a second step (2) by making use of mathematical operators.

Currently, the following mathematical operators are available for specifying allocation based formulas.

The next step consists of defining the allocation policy; this time, by specifying that the costs of the indirect cost centers no. 110, 120 and 130 shall be allocated to the other operative cost centers (no. 210-250) based on total direct costs. This is realized by associating the previously defined formula allocation base to the indirect cost centers and is illustrated in the next screenprint.

Once the allocations are processed – not shown for reasons of brevity; for details, see the prior post – the following costs remain at various cost centers:

From the screenprints shown above, one can identify that the costs of the indirect cost centers no. 110, 120 and 130 have been cleared. However, different from the previous post, more allocations are made. Take cost center 110 as an example, which does not only allocate its own primary costs ($32000) to the other cost centers but also the secondary costs it receives from the other operative cost centers ($626.01 from the car pool cost center and $1841.20 from the product management cost center).

Executing such kind of allocations necessitates the use of an iterative approach that allocates the costs of the indirect cost centers several times until all costs are allocated to the operative (‘direct’) cost centers no. 210-250.

The next Excel document summarizes the different allocations made and highlights the fact that allocations are not only made from the indirect cost centers (110-130) to the operative cost centers (210-250) but also within the group of indirect cost centers.

In the first post on the cost accounting module it was mentioned that cost allocations can also be made in the General Ledger (GL) module by making use of the allocation functionality. The GL allocation functionality suffers, however, from the fact that it cannot handle iterative cost allocations as the cost accounting module can. For complex allocation scenarios, the cost accounting module is thus the one to go for.

In the next post we will take a look at a third alternative allocation scenario that makes use of statistical measures for allocating costs. Till then.

Cost accounting (6)

Tags

, , , ,

This and the following posts will focus on the second pillar of a classical cost accounting system – the cost center accounting pillar. As mentioned in the previous posts on cost accounting, the cost center accounting system associates costs to its origin. The next figure illustrates this association for different kinds of costs (illustrated in the first column) with its origin cost centers.

Because the first three cost centers no. 110, 120 and 130 support all the other operative cost centers, the costs that have been accumulated on the supporting cost centers shall be allocated to the other ‘direct’ or ‘operative’ cost centers.

Within this post, the total direct costs of the supporting cost centers will be allocated to the operating cost centers (no. 210-250) based on the amounts that have been posted on other ledger accounts (cost elements). The next posts will show other, alternative allocation methods and provide a comparison with the allocations that will be generated in the following.

 

Before costs can be allocated, the different cost elements need to be specified first in the cost element dimension form. In the example used, the primary cost elements were transferred from the General Ledger’s Chart of Accounts (CoA) whereas the secondary cost elements (‘Allocation 110 Supplies’, ‘Allocation 120 Car pool’, ‘Allocation 130 Product management’) were created manually in the cost accounting module to track cost allocations in detail.

The second required setup for running cost allocations concerns the cost objects; in the example used, the cost centers, which were also transferred from the D365 ledger modules. For details, please see the following screenprint.

Once cost elements and cost objects are defined, they can be classified in cost element and cost object dimension hierarchies. The set up of those hierarchies is illustrated in the next figures.

The next setup relates to the cost allocations that shall be executed. Those cost allocations are set up in the cost allocation policy form, which is exemplified below.

 

In the cost allocation policy form that is illustrated above, the costs of cost center ‘110 Supplies’ are allocated to the other cost centers based on the amounts that have been posted on ledger account (cost element) 851000.

Similarly, the costs of the other supporting cost centers ‘120 Car Pool’ and ‘130 Product Management’ are allocated to the other cost centers based on the amounts that have been posted with ledger account (cost element) 852000.

With the so-called spring release that became publicly available in July 2017, additional predefined allocation bases became available. The next screenprint illustrates some of those predefined allocation bases, which comprise main accounts, cost elements and statistical elements that have been imported into the cost accounting module.

To identify the cost allocations made, a cost rollup policy is set up in addition to the previously shown cost allocation policy. Cost rollup policies establish a linkage between the cost object from where the costs are allocated from and the secondary cost elements that detail the cost allocations for the various cost objects.

Cost allocation and cost rollup policies do not allocate costs without being assigned to a cost accounting ledger. For that reason, a cost accounting ledger is set up next.

Please note that the arrows shown in the cost allocation and cost rollup policy forms identify the button through which the association between the policies and the cost accounting ledgers is made.

Similar to what has been shown in prior posts on the cost accounting module, the cost accounting ledger needs a linkage to the cost elements, the cost element hierarchy, cost objects and the cost object hierarchy, which is exemplified in the next figures.

After the cost accounting ledger is setup and after the source data are processed – for details, please see the prior posts – the cost allocation can be executed through the overhead calculation button.

For the illustration of the cost allocations in the cost controlling workspace, the workspace needs to be setup first. This set up is illustrated below.

 The only major difference in the setup of the cost controlling workspace to what has been shown in the prior posts is that a linkage to the overhead calculation version needs to be made. This is indicated by the arrow in the previous screen.

 

Once also this is made, the cost object data can be analyzed in the cost controlling workspace. The next screenprints document the obtained results.

For a better overview, the allocated costs data are summarized and highlighted in the following Excel document.

In the next post, we will take a look at an alternative cost allocation methodology that allocates the costs of the supporting cost centers based on the total direct costs recorded on the other cost centers. Till then.