Cost accounting (10)

19 Tuesday Sep 2017

Posted by in Cost accounting

≈ Leave a comment

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)

09 Saturday Sep 2017

Posted by in Cost accounting

≈ Leave a comment

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)

01 Friday Sep 2017

Posted by in Cost accounting

≈ Leave a comment

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)

22 Tuesday Aug 2017

Posted by in Cost accounting

≈ Leave a comment

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.

Cost accounting (3)

24 Monday Jul 2017

Posted by in Cost accounting

≈ Leave a comment

Tags

, , ,

The previous post focused on classifying a company’s costs into primary and secondary cost elements. Within this post, we will continue on this classification topic and demonstrate how cost elements can be used for analyzing cost accounting data in the D365 web client.

To realize this, a so-called cost accounting ledger needs to be set up, which defines processes and rules for measuring costs on cost objects. The next screenprint shows the cost accounting ledger used for the following illustrations.

As one can identify from above, two things need to be defined for the illustration of the demo data shown in the previous post. First, a cost element hierarchy that holds the cost elements that will be analyzed.

And second, the cost control unit, which holds the cost objects, such as for example the cost centers, departments, etc.

 More than a single control unit can be setup in this form and be linked to a cost accounting ledger.

After the cost elements and cost objects are defined, the data for the cost accounting ledger can be processed; that is, transferred from the general ledger into the cost accounting module. To process those data, the data source / data provider needs to be configured first. This configuration is made as illustrated in the following two screenprints.

 Data from multiple posting layers can be imported at the same time. This is something that has not been available in the ‘old’ cost accounting module.

Once the data source / data provider is configured, the GL data can be processed (transferred), as illustrated in the following screenprint.

The outcome of processing the data can be identified through the following cost element journal entries form.

To visualize the processed data in the cost controlling workspace, the workspace needs to be configured first by establishing a reference to (1) the cost control unit, (2) the cost elements and (3) the cost object.

With this workspace configuration in place, the following cost accounting data can be identified; in the screenshot below for the cost object ‘cost center 500 sales’.

 Please note that the cost controlling workspace does not differentiate between cost and revenues and simply adds up both elements. Moreover, the cost controlling form in the web client allows visualizing only one cost object at a time. A side-by-side comparison of the different cost objects – as illustrated in the sample data shown in the previous post – cannot be realized. This is because the cost controlling workspace is designed for the use of cost object managers and its access can be restricted by security rights. As a result, users have to apply Power-BI tools if they need a side-by-side comparison of the different cost objects analyzed.

 Details of the data illustrated in the cost controlling form can be viewed through the view details button/form, as exemplified in the next screenprint. In other words, even if multiple main accounts are summarized into a single cost element (‘travel costs’), details of the individual account data are still available.

In the next post we will take a look at how the total costs shown in the cost controlling workspace can be separated into a fixed and variable part. Till then.

Cost accounting (2)

17 Monday Jul 2017

Posted by in Cost accounting

≈ 1 Comment

Tags

, , ,

Within this second part, we will take a deeper look at the first pillar of a classical cost accounting system and investigate how a company’s costs can be classified for cost accounting purposes.

This investigation will be done based on the following sample data that have been recorded through a GL journal with the main accounts and financial cost center dimensions illustrated in the next figure.

To get those costs classified in the cost accounting module, a cost element dimension (that holds all cost elements required for the subsequent analysis) needs to be setup first.

Setting up a cost element dimension necessitates that a linkage to an existing Chart of Accounts (COA) is made. In addition, one has to define the main accounts that need to be imported into the cost accounting module. This definition can either be made by referring to main account types or account ranges, as exemplified in the next screenprint.

Once the cost element dimension is setup and defined, the only thing missing is starting the ‘import dimension members’ job through the respective button. After the import job is finished, the different cost elements that were imported from the general ledger (GL) module are classified as primary cost elements and can be identified in the ‘view dimension members’ form. The next screenprint illustrates this.

 Balance Sheet (BS) and Income Statement (IS) accounts can be imported into the new cost accounting module. Importing BS accounts was not possible in the ‘old’ cost accounting module without making a system modification.

 If one imported too many or wrong main accounts as cost elements, the fastest and easiest way to get this corrected is deleting the cost element dimension because subsequent imports won’t delete elements that have already been imported into the cost accounting module.

 

After the primary cost elements have been created through an import from GL, secondary cost elements can manually be created in the cost elements member form by selecting the new button. The next screenprint shows an example.

 Secondary cost elements are used in the cost accounting module only and are used for cost allocations and overhead calculations. Their usage will be shown in subsequent posts.

An investigation of the screenprint above shows that a 1:1 relationship between the company’s main accounts and the cost accounting elements exists. Sometimes cost accountants do not require this level of detail but would rather summarize different main accounts into a single cost element. Let’s assume that the cost controller is not interested in the details of the travel related expense accounts but wants to summarize all of them – in the example main accounts 6401 to 6405 – into a single cost element denominated ‘travel costs’.

Summarizing different cost element dimensions can be realized by preparing the required cost elements in Excel, uploading and mapping them. The next screenprints demonstrate how such an import works.

Step 1: Export the ‘imported cost element dimension’ data entity through the data management

Step 2: Prepare the cost elements in the exported Excel template

Step 3: Upload the cost elements through the data management import form

Step 4: Create a new cost element dimension and select the ‚imported dimension members’ data connector

Step 5: Configure the dimension member provider

 The data connector is the source identifier that has been specified in the Excel template. For details, please see step 2 further above.

Step 6: Select ‘import dimension members’
The outcome of this import can be controlled through the ‘view dimension members’ form and is illustrated in the next screenprint.

Step 7: Map cost elements
The last step required consists of mapping the imported cost elements with the GL main accounts that have previously been imported into a different cost element dimension. The next screenprint shows how the different cost elements/main accounts are mapped for the travel cost accounts.

 The ability to map cost elements from different cost element dimensions allows incorporating cross-company accounting scenarios in the cost accounting module; something that has not been possible in the ‘old’ cost accounting module. The next illustration shows a scenario where business data from three different companies (US, FR & DE) that all use their own COA can be analyzed together through the definition and mapping of cost accounting elements.

Cost accounting (1)

14 Friday Jul 2017

Posted by in Cost accounting

≈ 1 Comment

Tags

, , ,

Recently, a new cost accounting module has been released for Dynamics 365 for Finance & Operations Enterprise Edition (In the following short ‘D365’). Previous Dynamics AX versions also had a cost accounting module integrated. The previous module and its functionalities have, however, been discarded and not a single line of code has been reused for the new cost accounting module.

Before jumping into the new cost accounting module functionalities, let’s start with some general notes on the cost accounting theory in order to prepare the playground for the subsequent setup and analysis of the new cost accounting module functionalities.

If you search for the term cost accounting, you will easily find numerous definitions that describe what cost accounting is all about. Rather than trying to create an own mediocre definition here, let’s rather focus on the different pillars of a classical cost accounting system, which are illustrated in the next drawing.

 

The first pillar of a classical cost accounting system is made up by the so-called cost type accounting system, which classifies a company’s costs for example by the nature of their traceability (direct vs. indirect costs), by functions (production, administration, selling, etc.), by behavior (fixed, variable, semi-variable), etc.

The second pillar of a classical cost accounting system consists of the cost center accounting system, which is responsible for associating the classified costs to its origin, such as for example a cost center.

The cost object accounting system – sometimes also referred to as product cost accounting system – establishes the third pillar of a classical cost accounting system. This last pillar can be differentiated into a unit or item based and a time based cost object accounting system.

 

The following figure summarizes the different pillars of a classical cost accounting system and shows its association to the financial accounting system.

 Please note that the financial accounting system (that is governed by GAAP) is often referred to as external accounting system while the cost accounting system is regularly referred to as internal accounting system.

 

If you take a look at the figure above, you will find that several cost accounting elements are already integrated in other D365 modules. As an example, cost allocations can be executed through allocation rules in the general ledger module, item costs can be calculated through the costing sheet and the use of financial dimensions and main account allocation terms allows de facto the implementation of a direct costing approach.

Provided that those features are already available in D365, the question for the necessity of a separate cost accounting module arises. This question will be answered in the following posts, which describe the different cost accounting module functionalities and compares them with the already available features in the other D365 modules.