Dynamics 365 – Cost

Accounting Ledger Teaser

February 22, 2017
An exciting new functionality is now available in Dynamics 365 for Finance and
Operations. A Cost Accounting Ledger is now available to take Cost Accounting to a
new level. In previous AX versions, cost accounting functionality has been available,
but with the creation of the Cost Accounting Ledger, Microsoft has opened up a
completely new realm of possibilities.
The Cost Accounting Ledger is a stand-alone structure, defined with currency and a
calendar. Multiple cost accounting ledgers can be put in place as the organization
requirements dictate and creativity runs wild. Management Reporter can then utilize
the cost accounting ledgers to report out the many views of cost that a company
needs to see.
Foundationally, Cost Elements are used to classify or categorize the cost
transactions, and Cost Objects are used to aggregate the costs.
Before Cost Accounting Ledgers can be implemented, the set-up to be done
includes:

 Cost Element Dimensions

 Cost Object Dimensions
 Statistical Dimensions (optional)
 Dimension Hierarchies
 Cost Accounting Ledgers

Cost Element Dimensions

Let’s walk through the setup required. First, establish the Cost Elements to be used
in the Ledger.
Navigate to Cost Accounting > Dimensions > Cost Element
Dimensions

The main accounts can be imported into Cost Accounting, to be used as Cost
Element Dimensions, by using the Data Connector. Cost Element Dimensions can
also be imported using Excel. And Cost Element Dimensions can be entered
manually. If Secondary Cost Element Dimensions are desired, they must be entered
manually.

Cost Object Dimensions

Next, the Cost Objects. Something meaningful to be used to analyze cost. Navigate
to Cost Accounting > Dimensions > Cost Object Dimensions.
Cost Object dimensions can be imported using the connector or Excel, as the Cost
Element Dimensions can be. Or they can also be manually entered. Cost Object
Dimensions are used to roll up, or aggregate, the costs. Think of product families,
projects, cost centers, and departments as Cost Objects.

Statistical Dimensions
Statistical Dimensions are optional and used in allocations or statements. Think of
hours or square feet.
Navigate to Cost Accounting > Dimensions > Statistical Dimensions to set up
Statistical dimensions.

Dimension Hierarchies
Hierarchies can then be established based on the Dimensions created for reporting
purposes. One way to view the data using the hierarchy is by using the Cost
Controlling Workspace. Yet another is by using Excel.
Navigate to Cost Accounting > Dimensions > Dimension Hierarchies to establish
a hierarchy.

Cost Accounting Ledger

Now on to the CA Ledger set up. Navigate to Cost Accounting > Ledger Setup >
Cost Accounting Ledgers
Create Cost Control Units to define the Cost Accounting Ledger Flow.
Once the Setup is complete, General Ledger transactions are imported to the Cost
Accounting Ledger using the connectors defined during the set up.
Note: Creation of Cost Behavior Policies should be used to determine if costs are
variable, semi-variable or fixed.
Cost accounting (1)
14 Jul 2017 12:58 AM
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.

17 Jul 2017 9:00 AM

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.

23 Jul 2017 9:00 PM

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.

1 Aug 2017 2:00 AM

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.

5 Aug 2017 8:00 AM

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.

13 Aug 2017 6:01 AM

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.
22 Aug 2017 10:40 AM

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.

1 Sep 2017 1:36 AM

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.

9 Sep 2017 1:31 PM

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.

19 Sep 2017 9:06 AM

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.

1 Oct 2017 1:09 AM

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.

12 Oct 2017 8:23 AM

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.

22 Oct 2017 2:20 AM

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.

1 Nov 2017 1:38 AM

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.

8 Nov 2017 2:43 PM

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.

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 (15)

08 WednesdayNOV 2017

POSTED BY LUDWIG REINHARD IN COST ACCOUNTING

≈ LEAVE A COMMENT
Tags
Controlling, Cost accounting module, Cost center accounting, Management Accounting, overhead rate
policy, Statistical measure provider templates

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 (16)

19 SundayNOV 2017

POSTED BY LUDWIG REINHARD IN COST ACCOUNTING

≈ LEAVE A COMMENT
Tags
Controlling, Cost accounting module, Cost center accounting, Management Accounting, overhead rate
policy, Statistical measure provider templates

The previous posts showed three different approaches how cost allocations in the cost
accounting module can be made based on recorded project hour transactions. The
approaches used

1. project hour quantities that were imported into the cost accounting module for
making cost allocations based on the recorded project hour quantities,
2. project hour transaction vouchers that were generated by making use of the project
module ledger integration, and
3. overhead rate policies that allocated the costs to other cost centers based on project
hour quantities recorded in the project module.

A major disadvantage of the first approach is that the complete cost center costs of the
car pool cost center are allocated to the other operative cost centers irrespective of
whether those costs are too high or low compared to an external market price.
The second and third approach did not completely allocate the car pool cost center costs
but did not provide a benchmark of the required cost rate needed to allocate the
complete cost center costs.

In this post, we will investigate how such a benchmark can be obtained by making use of
the overhead rate policy feature, which is described on a step-by-step basis in the
following.

Step 1: Record hours in the project module

To get the cost allocation and overhead rate policy incorporated, hours are recorded in
the project module first.

Please note that no additional projects and postings have been created but that
the transactions shown and recorded in the previous post have simply been reused. The
next screenprints consequently document the previous postings and resulting costs only.
Step 2: Setup statistical measure provider template
Also the second and third setup steps are identical to what has been shown in the
previous posts. Therefore, reference is made to what has been described there and the
following screenprints are included for reasons of completeness only.

Step 3: Setup statistical dimension measure

Step 4: Create cost accounting ledger

The set up of the cost accounting ledger slightly differs from the cost accounting ledgers
that have been used before. That is because the project cost and payroll allocation
accounts (853100 and 853200) have not been included in the cost element and
dimension hierarchies used before. The next screenprints document the minor changes
that have been made to the newly created cost element dimension (‘DEMF CE P16’) and
the newly created cost element dimension hierarchy (‘DEMF CEH P16’).
Step 5: Create cost allocation policy
The cost allocation policy that is used in this post is identical to the one that has been
used in post no. 14 except that the newly set up cost element dimension (‘DEMF CE P16’)
is used.

Step 6: Create cost rollup policy

Also the cost rollup policy is identical to the one used in post no. 14 except for the newly
set up cost element dimension hierarchy.
Step 7: Create overhead rate policy
The overhead rate policy used in this post differs from the one used previously in the
overhead rate policy type (‘fiscal period’ vs. ‘user specified’). Because of the ‘fiscal
period’ type selected, one cannot enter an overhead rate in the rule section, as D365
calculates the rates automatically.

Step 8: Process data in cost accounting ledger and configure workspace

After processing the data and policies and after setting up a cost controlling workspace,
the following costs can be identified for the various cost centers used:
The next overview summarizes the cost allocations made.
From the previous screenprint it can be identified that two allocations were made; one in
the project module for the hours recorded with a cost price of $180/hour and a second
one in the cost accounting module, where all remaining costs of the indirect cost centers
no. 110-130 were allocated.

Only the cost allocations made in the cost accounting module result in secondary
cost transactions. The cost allocations made in the project module are considered to be
primary costs from a cost accounting module perspective.

After allocating all costs from the supporting or indirect cost centers no. 110-130 to the
direct operative cost centers no. 210-250, the initially raised question on the benchmark
cost rate for the car pool cost center has not been answered. An investigation of the
overhead rate policy form – shown in the next figure – allows answering this question.
The overhead rate policy form shows a cost rate of $1640.43 for 40 units (hours) of work
for the car pool cost center. Dividing the amount by the units results in a rate of $41.01
per hour. Because the cost accounting module allocated the remaining costs only that
were not previously allocated through the postings in the project module, the $41.01
represent a cost rate difference. That is, in order to allocate the full costs of the car pool
cost center, a rate of ($180 + $41.01 =) 221.01 is required.

If a ‘fiscal period’ overhead rate policy is applied to the cost accounting ledger
that has been used in the previous post no. 14, the same rate can be identified. For
details, please see the next screenprint.

In the next post, we will investigate how cost allocations that are made in D365 can be
tracked and analyzed. Till then.

Cost accounting (17)

 01 FridayDEC 2017

POSTED BY LUDWIG REINHARD IN COST ACCOUNTING

≈ LEAVE A COMMENT
Tags
Controlling, Cost accounting module, Cost center accounting, Management Accounting, Track cost allocations

Within the previous posts, many different ways how cost allocations can be made have
been illustrated. As the cost allocation transactions recorded are quite complex, summary
Excel documents that showed the allocation bases and amounts have manually been
prepared.

Preparing those summary Excel documents manually is time consuming and feasible only
for the simplified examples used.

If the manual preparation of those summary Excel documents is not feasible in practice,
the question arises, how one can follow up and track cost allocations in live
environments?

To answer this question, the following four cost accounting ledger Excel export options
have been reviewed:

The costs allocations made for this post are identical to what has been shown
in post no. 8 on the new cost accounting module. That is, the supplies cost center costs
are allocated to the other cost centers based on the number of employees. The car pool
cost center costs are allocated based on the number of company cars and the product
management cost center costs are allocated to the other cost centers based on
production quantities. For details, please see post no. 8.

Excel export option 1:

Making use of the first Excel export option (‘cost entries with dimension hierarchies’)
results in the following

outcome:
As one can identify from the highlighted columns in the previous screenshot, the first
Excel export option is not very helpful because it exports the primary costs only. The
secondary costs, that is, the cost allocation data are, however, missing.

Excel export option 2:

The second Excel export option (‘statistical entries and cost entries with dimension
hierarchies’) resulted in the same outcome that is shown in the previous screenprint and
did also not include the cost allocations posted on the secondary cost elements.

Excel export option 3:

For the third Excel export option (‘statistical entries with dimension hierarchies’), the
Excel export returned no data.

Excel export option 4:

The last Excel export option (‘cost accounting ledgers’) finally resulted in the following
outcome, which does not help with the intended detailed analysis of the cost allocations
made.
As none of the previous Excel exports resulted in the intended outcome, the following
data export option was investigated:
Making use of this data export functionality finally resulted in the intended outcome. That
is, the Excel export also included the cost allocation data, which are highlighted in green
color in the next screenprint.

After exporting the primary and secondary cost accounting data to Excel, a pivot table
was created. This pivot table is almost – except for the allocation base information –
identical to the summary Excel documents that have previously been prepared manually.

The last data export functionality shown results in a dynamics Excel export. That
is, subsequent cost accounting ledger transactions do not require a new Excel export but
a simple data refresh only. The next screenshots prove this standard behavior by making
use of a step-wise illustration.
Step 1:
Additional repair costs are recorded on the repair cost account no. 855000 for cost center
240 in a General Ledger journal.

Step 2:
Those costs are transferred to the cost accounting module for example through a periodic
batch run.

Step 3:
After the data are transferred to the cost accounting module, the Excel document is
refreshed and shows the additional costs recorded.
The data export functionality used for the illustration of the cost allocations made helped
illustrating the recorded cost allocation amounts. It did, however, not provide any
information on how those allocations were made.

In order to find out how cost allocations were made, one can analyze the cost allocation
journals that have been created in D365. Let’s take the $32,983.43 that have been
allocated from cost center 110 as an example.

By making use of the cost entries button, one can identify the other cost centers that got
those costs allocated.
While this information can be retrieved from the Excel pivot chart shown above, the
allocation base information that is shown next, is available only in the D365 cost
accounting module.

As the current data export functionalities do not support the export of the allocation base
data, an idea has been created on the D365 ideas portal and it would be great if you
could vote for it. Here is the link: https://ideas.dynamics.com/ideas/dynamics-
operations/ID0002454
Many thanks and see you again in the next post on cost accounting security.