Category Archives: Cost accounting

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.