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.

Cost accounting (5)

Tags

, , , ,

Within this post, we will focus on another two cost accounting topics that are related to the first pillar of a classical cost accounting module before we move on to the second pillar and take a deeper look at the cost center accounting features.

 

Part 1: Corrections
Sometimes it is necessary to make corrections to the data recorded (transferred) to the cost accounting module. As an example, let’s assume that $150 taxi costs that are posted in combination with the admin cost center no. 400 do actually belong to the sales cost center no. 500.

In the ‚old’ cost accounting module, cost accountants could simply correct such errors by making use of cost accounting journals that did not have an influence on the financial accounting system. In other words, adjustments that were made in the cost accounting module had no effect on the other finance modules.

With the new cost accounting module, this option is no longer available and necessary changes to transferred accounting data must either be made by importing adjustment transactions through data entities directly into the new cost accounting module or – better – by recording adjustments in the originating finance modules.

 

Part 2: Combine data from different companies
The previous (old) cost accounting module was limited to a single company and could not analyze data originating from different companies. This has been changed in the new cost accounting module, which allows analyzing data from multiple companies that are either setup in D365 or that use other (external) ERP systems.

Within the following, we will have a look at a simplified example where financial data from two companies (DEMF & USMF) will be analyzed together. To understand and follow the example, please note that the two companies use different Chart of Accounts and different currencies. The financial data used for the following illustrations can be identified in the next figure.

To get the financial data analyzed together, three cost element dimensions need to be specified:

  • The first one (CA_CostElements) has already been used before and holds the main accounts/cost elements from company USMF
  • The second one (CA_CostElements2) holds the cost elements that were previously imported and that will be used for the combined analysis of the data.
  • The last cost element dimension illustrated in the previous screenprint holds the main accounts/cost elements that originate from company DEMF.

Because the second cost element dimension will be used for the combined analysis, the DEMF and USMF cost elements need to be mapped to this dimension. The next screenprint exemplifies this for the DEMF cost elements.

Once the different cost elements are mapped, a cost element dimension hierarchy needs to be setup because it is required for the configuration of the cost accounting ledger.

The cost accounting ledger refers then to this cost element dimension hierarchy and the cost control units (cost centers). As the setup of the cost control units is identical to what has been shown in the previous posts, reference is made to those previous explanations to conserve space.

The next required setup step consists of configuring the data provider for the cost accounting ledger, which is necessary for getting the cost accounting data transferred to the cost accounting ledger. Because two companies are now connected to the cost accounting ledger, two data provider need to be specified. This is illustrated in the next screenprint.

 Please note that the data providers need to be configured in a way that they refer to the cost element dimensions of the specific entity.

Once the configuration is made, the data can be imported into the cost accounting ledger as shown before. The next step is then the setup of the cost controlling workspace, which links the control unit, the cost element and the cost object hierarchies.

After the cost controlling workspace is setup, the combined business data can be analyzed, as exemplified below.

 Please note that an exchange rate of 1 EUR = 2 USD has been used for the currency conversion of the EUR data in order to consolidate them into the combined USD data that are illustrated in the cost controlling workspace.

 

This post ends the series on the first pillar of a classical cost accounting system – the classification of a company’s costs. The previous posts showed that also the new cost accounting module allows classifying costs according to their behavior (fixed vs. variable), their nature (primary vs. secondary) and by functions (admin, travel, etc.). Compared to the previous cost accounting module, users have more options in regards to the data that can be analyzed in the new cost accounting module (cross-company & integration of posting layers). Those enhanced options come, however at the price that additional / more complex setups are required.

The following posts will investigate how cost center accounting functionalities are supported in the new cost accounting module. Till then.

Cost accounting (4)

Tags

, , ,

This post builds upon the previous one and shows how one can separate fixed and variable cost elements. To split the total costs of a cost element into a fixed and variable part, a cost behavior policy for the cost elements used in the cost accounting ledger needs to be specified.

Within the cost behavior policy form, combinations of cost elements and cost objects can be used for specifying fixed and variable cost parts at different levels. The following screenprint exemplifies this.

Once the fixed and variable cost parts are specified, the cost behavior policy needs to be linked to the cost control units of the cost accounting ledger, which can be achieved by selecting the ‘policy assignment for cost control unit’ button shown in the previous screenprint.

Thereafter, an overhead calculation can be executed in the cost accounting ledger to get the total costs split up into a fixed and variable part.

The last step required for illustrating the fixed and variable cost parts in the cost controlling workspace is the assignment of the actual overhead calculation version in the workspace configuration form.

Afterwards, the fixed, variable and total costs can be identified in the cost controlling workspace…

… and the cost element details form.