Monthly Archives: August 2017

Cost accounting (7)

22 Tuesday Aug 2017

Posted by in Cost accounting

≈ 2 Comments

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)

13 Sunday Aug 2017

Posted by in Cost accounting

≈ Leave a comment

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)

05 Saturday Aug 2017

Posted by in Cost accounting

≈ Leave a comment

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)

01 Tuesday Aug 2017

Posted by in Cost accounting

≈ 3 Comments

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.