Project related intercompany cost allocations (1)


, , ,

In my last post I illustrated a standard functionality that allows allocating indirect costs, such as licensing costs to projects. While the major focus in the earlier post was on intra-company cost allocations, I would like to extend the focus in this post by taking a look at standard functionalities that allow intercompany cost allocations for projects.

Rather than trying to illustrate those functionalities from a pure technical, rather abstract perspective, I decided to take a look at project related intercompany cost allocations based on the following three examples.


Example 1: Employees engaged in company USSI work on projects in company FRSI

Part A: Scenario
Within this first example I will take a look at the standard intercompany timesheet functionality that allows employees recording times on projects that are setup in different companies without having to change the company. You might have read some posts about this feature before. Yet, irrespective of that and risking that you have already heard / read about it, I would nevertheless like to start with this elementary example, as it establishes the basis for the following, more complex intercompany cost allocation scenarios.

In this first example I assume that an employee engaged in company USSI is doing some software installation work for a customer project that is setup in company FRSI. In order to allow the USSI employee recording her time on the FRSI project and to charge FRSI for the hours worked, the following setup is required.


Part B: System setup

Setup B.1: Intercompany customer – vendor relationship
The first thing that needs to be setup is an intercompany relationship between a customer and vendor account, which is required for recording the intercompany cost and invoice transactions later on. The next screen-print exemplifies this setup for the intercompany customer account in company USSI.
Note: When establishing the intercompany customer-vendor account relationship you need to ensure that those accounts are setup with a financial intercompany dimension as illustrated above. That is because the project posting profiles do not allow setting up ledger accounts based on a company criteria. If you decide not making this kind of setup, the consolidation of your financial results might get more complex later on. For details, please see further below.

Setup B.2: Project category
The next setup required is related to the project categories. In this respect you have to ensure that the category that you need for recording the hour transactions is setup in both companies.
Note: If the category is not setup in both companies, Dynamics AX will show the following error message and won’t let you continue processing your transaction until the error is resolved.

Setup B.3: Intercompany accounting
Once all project categories required have been setup, an intercompany accounting relationship between the companies involved in the transaction needs to be established, as illustrated in the next screen-print.
Establishing this relationship is not required for creating timesheet and/or intercompany postings but rather for allowing users selecting the different companies in the timesheet form.
Please note that if the intercompany accounting relationship between USSI and FRSI is missing, employees working in USSI cannot select and post their hours on projects that are setup in FRSI. The next screen-print illustrates this.

Setup B.4: Project setup company FRSI
When setting up the project in FRSI, it has to be ensured that the project is linked to a financial intercompany dimension. Otherwise, the separation and identification of intercompany transactions during the financial consolidation process might become difficult.
Please note that the other financial dimensions used in this example (Department 023 and Project 00000027) are not necessarily required for the time recording process. They have, nevertheless been setup here for illustrative purposes in regards to the vouchers created. For details, please see further below.

Setup B.5: Employee setup company USSI
After setting up the project in FRSI, the employee engaged in company USSI is setup. This setup does not require some special considerations except that it is advisable linking the employee to its department / cost center and intercompany financial dimension, as exemplified in the next screen-print.

Setup B.6: Intercompany sales price
Setting up intercompany transfer prices for hours recorded is something easy from a pure technical system perspective, as the only thing required is entering a price that will be charged to the other company for the hours worked.
From an accounting and taxation perspective things are, however, more complex when it comes to the setup of intercompany transfer prices in an international company environment. This complexity is mainly caused by a number of (sometimes differing) intercompany transfer pricing rules applicable in the countries involved in the intercompany trading relationship. Within the context of this post it is impossible illustrating you even the most basic intercompany transfer-pricing regulations. For that reason reference is made to the general international transfer-pricing framework – the OECD transfer pricing guidelines. Based on the OECD guidelines overarching “arm’s length” transfer pricing principle, an intercompany sales price of 300 USD is setup and used in this example for the subsequent hour transactions recorded.
Please note that Dynamics AX allows determining intercompany transfer prices based on the sales price that external customers are charged for through the selection of one of the following (yellow-highlighted) transfer pricing models.


Part C: Process steps

Step C.1.: Process intercompany time sheet
With all those setups in place, the USSI employee can record her hours in the timesheet form as usual by referring to the company and project she worked for. Please note that this selection defaults the financial dimension values of the intercompany project in the timesheet form, as illustrated in the next screen-print.
The resulting voucher records the cost and payroll allocation in USSI. Notable in regards to the voucher created are the financial dimension values that are recorded together with the cost account (540100) and the payroll allocation account (602100).

Step C.2.: Post intercompany project invoice
The next process step consists of creating the intercompany project invoice in company USSI. This can be realized by using the corresponding intercompany project invoice functionality. Example:
Once all transactions to be invoiced are selected and posted…
… the following intercompany invoice voucher results.
Please note that the intercompany receivable account (133100) is determined by the customer posting profile setup in the Accounts Receivable module. The intercompany sales revenue account (402100) on the other hand, is determined by the corresponding account setup in the project module ledger posting form.

Step C.3.: Post pending vendor invoice FRSI company
At the time the intercompany project customer invoice is posted in company USSI, a corresponding intercompany vendor invoice is created in company FRSI that can be found in the pending invoice section of the Accounts Payables module.
Posting this invoice results in the following voucher.
(Please note that the USSI and FRSI companies use different Chart of Accounts).

In order to differentiate between the different transactions posted, the following accounting overview has been created:
What can be identified from the illustration above is:

  • First, that the costs for the hours recorded in company USSI cannot be identified at the project level in company FRSI – at least as committed costs – until the intercompany project invoice and pending vendor invoice have been created.
  • Second, that the orange and yellow highlighted transactions can easily be identified in the financial consolidation process due to the financial intercompany dimension used. (Please note that the financial intercompany dimension (“FRSI”) used when creating the intercompany invoice is determined by the setup of the intercompany customer account illustrated in setup step no. 1 further above. The financial intercompany dimension that is used when recording the costs and intercompany vendor invoice is, on the other hand, determined by the project setup in company FRSI.)
  • Third, that a comparison of the cost and (inter-company) revenue – highlighted in green color in the next screen-print – allows an easy identification and comparison of the intercompany profit made in the internal transaction. This helps users checking and justifying the appropriateness of the company’s transfer pricing policy e.g. against auditors.

Note: As indicated above, the setup of financial intercompany dimension values is crucial for the whole intercompany process. That is because the project module ledger posting setup does not allow specifying intercompany cost and revenue accounts based on companies involved in the trading relationship. Please see the next screen-print for details.
What happens if the financial intercompany dimension is missing at the project level can be identified in the next illustration.
The arrows and red highlighted fields above highlight the missing financial intercompany dimensions that cause problems when it comes to the financial consolidation of the intercompany accounts – especially if several companies are involved in the inter-company trading relationship.
In addition, also a check of the appropriateness of the intercompany transfer pricing policy will get more complex if the financial intercompany dimension is missing, as the project cost and project revenue postings cannot easily brought together.


Intermediate result
I hope that this post gave you some new insights into the intercompany timesheet functionality even if you have already heard & read something about this feature before.
Against the background of this standard functionality, let’s continue then by having a look at some other, more complex, project related intercompany cost allocation scenarios in the next part.

Project cost allocations


, ,

In an earlier post I presented the indirect cost functionality available in the project module. For details, please see my earlier post.

A major outcome of this earlier post was that the standard indirect cost functionality’s usability is currently rather limited because of the constraint that indirect costs can only be defined in relation to project-hour costs respectively project-hour transactions.

Within this post I would like to take a different look at the indirect costs topic by investigating how indirect costs, such as insurance costs, licensing fees, depreciation expense and alike can be allocated to different projects in order to allow users taking a look at the full costs of a specific project.

An important consideration in this context is the question what kind of indirect project costs are allowed to be allocated to projects? Most of the major Accounting Standard setters, such as the IASB or the FASB, answer this question by defining that only those indirect costs that have a direct relationship to projects can be allocated. For details, please see e.g. IAS 11.

The aim of the following sub-chapters is illustrating how indirect costs that are directly attributable to several projects – such as e.g. insurance and licensing costs – can be assigned to them. Subsequently, I will illustrate how costs that are not directly attributable to projects can be allocated to those projects in a way that allows project managers taking an (internal) look at the full costs of a project.

Let’s start by having a look at the first example that illustrates how insurance related expenses can be allocated.


Example 1: Allocation of insurance related expenses
The first example starts with a vendor invoice for insurance expenses that is recorded in an ordinary vendor invoice journal and posted on the insurance expense account no. 606200. The expense account is posted in combination with the operations department no. 023 because the operations manager is primarily responsible for all insurance contracts in the company.
To get those costs allocated to the different customer projects no. 000009 to 000012 (illustrated in the next screen-print), an internal cost project (no. 000008) has been setup. Please note that this internal cost project was setup and linked to its own project financial dimension no. 000008 and an internal “cost allocation department” no. 099.
My next step was creating a project expense journal in order to post the amount invoiced by the vendor against a project insurance allocation category (“ALLOC INSURANCE”).

Note: The aforementioned project category is linked to ledger account 606250 that is used to track those insurance costs that have been distributed to projects.

The offset account used (account no. 679999) for my transaction defaults from the expense journal and has been setup as a fixed offset account.

Note: The offset account could also have been specified by making use of the default offset account feature available in the project module.

The financial dimensions – department 099 and project 000008 – finally default from the internal cost project that has been setup.
Posting this journal results in the following voucher that debits an insurance expense allocation account no. 606250 and thereby ensures that the insurance related costs are “shifted” to the project module and available for further processing.
Once the insurance costs have been shifted to the project module, I used the standard project adjustment functionality to allocate the costs from the internal cost project no. 000008 to the different external customer projects. Details of this allocation can be identified in the following screen-prints.
Note: From the previous illustrations and explanations you can easily identify that I used the standard project adjustment functionality as “cost allocation tool” to get the costs distributed to the other projects. A major disadvantage of doing the cost allocation this way is that you have to enter the “allocation key” manually yourself. However, as this standard functionality allows allocating costs to different projects out of the box, most of the work is already done and with a modest system modification you can easily get this cost allocation fully automated.
Alternatively, the cost allocation can be realized by using the Excel-add-in. As the Excel-add-in allows addressing the different customer projects directly through a direct upload into project expense journals, a subsequent allocation via the standard adjustment functionality is not necessary.

The outcome of the cost allocation executed through the adjustment functionality can be observed in the next screen-print which shows the resulting ledger voucher:
The next illustration summarizes all vouchers generated within this 3-step allocation procedure. An important outcome in this context is that the original insurance costs posted on ledger account no. 606200 can still be identified. In addition, the allocation account no. 606250 and allocation department no. 099 are cleared through the adjustment posting generated.
The next financial statement report presents the data in a slightly different reporting format.
What can be identified from the financial statement illustrated above is that the sum of the insurance expense recorded on the company’s different departments adds up to 0,00 EUR indicating that all costs have been allocated to the company’s projects. This can also be identified in the last report column which summarizes the costs of all (external) customer projects.


Example 2: Allocation of licensing costs
At this point you might have asked yourself why the previously illustrated 3-step allocation procedure was used and why the insurance expense hasn’t directly been posted on the internal cost project? Within this second sub-chapter I will answer this question by recording licensing expenses that shall be distributed to the different external customer projects.

The second example starts once again with recording a vendor invoice in the Accounts Payable module. This time, the invoice is recorded on the internal cost project no. 000008 directly. Please see the next screen-print.
Please note that the procurement category used is linked to the corresponding project category, which defines the ledger posting generated.

Once the invoice is recorded, the previously illustrated adjustment functionality is used once again for distributing the licensing costs to the different customer projects.
As in the previous section, the next illustration summarizes the vouchers generated in this 2-step allocation procedure:
An important difference to the previously used 3-step allocation procedure is that the vouchers debit and credit the same internal cost allocation department no. 099, which has been setup at the internal cost project level. As a result, users cannot immediately identify the licensing costs directly from an analysis of the different departments. For details, please see the next screen-print.


Example 3: Allocation of depreciation expense
Within this last chapter I want to exemplify how costs that are not directly related to projects can still be allocated and shown at the project level even though this is not allowed by the major accounting standard setters.
The procedure required to realize this is basically identical to the 3-step allocation procedure shown previously. The major difference to the procedure used before is that “statistical” ledger accounts are used for showing those costs at the project level. Let’s have a look at the individual steps involved here.
The first step consists of posting the depreciation expense for the fixed asset(s). In the example used 4000 EUR are posted on the depreciation expense account 607200 in combination with the finance department 024 that is responsible for managing the fixed asset.
The next step involves posting a project expense journal with reference to a project category that records the expense on a statistical cost account (no. 907250). The offset account used (no. 907251) is also a statistical account and setup with the project expense journal as fixed offset account.
The last process step consists of allocating the statistical depreciation costs to the different external projects.
All transactions involved in this last example are summarized in the next illustration…
… and (internal) financial statement.
As mentioned before, the major difference in this third example compared to the first one is that the lines highlighted in light blue color are not included in external financial statements and used for internal cost analysis purposes only.


Within this post I illustrated how the standard project cost adjustment feature can be used for allocating indirect costs to projects. A major advantage of the approach illustrated in this post compared to the indirect cost feature is that any kind of costs can be allocated to projects irrespective of other transactions recorded. I would like to close by summarizing that even though the cost allocation approach illustrated here is not ‘perfect’ in the sense that allocations are not fully automated; it does nevertheless provide a good basis for implementing a more advanced and automated project allocation functionality that is required in companies where indirect costs need to be allocated to a large number of projects.

Management Reporter – Unit Security


, , ,

Within this post I would like to present a feature that allows you restricting the access to data included in Management Reporter financial reports. A common business scenario where this feature can be applied are situations where business unit/cost center managers shall only have access to the data of the business unit/cost center they are responsible for.
Let’s have a look at the following Income Statement report that shows the total amounts split up by business units to see how the Management Reporter unit security feature can be applied.
Assume that we want to restrict the report data access for Phyllis, the manager of business unit BU001, in a way that she has Access to the Income Statement data of her business unit only. This restriction can be accomplished by setting up a report with a reporting tree that includes the respective users in the unit security column. Because the report includes all business units next to each other in separate columns, the reporting tree elements need additionally to be linked to the respective columns. This is linkage and the unit security setup is illustrated in the next screen-print.
With this setup in place, Phyllis will see the following report, once she opens it.


The security restriction setup does also apply to the Management Reporter drill down functionality in Dynamics AX. That is, if Phyllis wants to see the voucher transaction details that make up a specific amount shown in the report and drills down into the Dynamics AX voucher transactions, she will only see the filtered transactions for her business unit. This system behavior is illustrated in the next screen-print:
A second thing to note here is that the Management Reporter unit restriction does not control whether or not Phyllis can open and access all transaction details through the Dynamics AX client directly. In the example used Phyllis can, for example, log into the Dynamics AX client and access the complete voucher details including the amounts that were recorded for the other business units. Example:
If you have users that can circumvent the Management Reporter unit restriction this way, you have ensure that you also implement the extensible data security framework in Dynamics AX. Otherwise, the unit security feature does not make much sense. Please see the following sites 1 / 2 for additional information on the extensible data security framework.


Report modification 1
Now let’s have a look at some Management Reporter design considerations that you should be aware of when making use of the unit security feature and reporting trees in general. Let’s imagine that the Income Statement report shown previously is modified in a way that also the cost centers that make up a business unit are included in separate report columns. If you follow the same unit restriction setup shown previously also for the sub-elements of the business units …
… users won’t see all details once they open their report. In the example used Phyllis, will see the following data when opening the report:
The data for the cost centers that make up the business unit cannot immediately be identified but rather have to be opened separately by selecting one of the business units. Example:


Report modification 2
Because of the previous data illustration issue, the report is modified once again in a way that the business unit and total columns are now setup as computed columns. (Please see the yellow highlighted section in the next screen-print).
With this setup in place, Phyllis will get the following message once she opens the report.
By selecting one of the cost center elements, she will finally be able to see the data for the selected cost center but not automatically for the other ones without selecting them separately.


Report modification 3
To avoid that the Income Statement report opens with an error message for the business unit / cost center managers, the report design is further modified as follows:
The major difference to the previous setup is that cost center sub-elements that make up the business division are now intended in the reporting tree. This setup finally ensures that Phyllis is able to see all data of the business unit she is responsible for when opening the report.
If Phyllis drills down to the different sub-elements, the report will filter the selected data respectively. Example:


I hope the different examples gave you an impression what to look out for when designing Management Reporter reports that include reporting trees and make use of the unit security feature. The major take away from this post is that setting up the unit security feature in Management Reporter does not make much sense if users can circumvent those restrictions by extracting the data directly from the AX client. To avoid such scenarios you have to ensure that the extensible data security framework is applied concurrently in the AX client.

Summarize vendor payments to one line for bank reconciliation


, ,

Recently, I came across a requirement where payments were made from a specific bank account. As only one single bank account was used for making the payments, the expectation was that Dynamics AX creates only one single posting on the bank account. Dynamics AX did, however, create numerous bank postings – one for each journal line – as the invoices paid were recorded with different financial dimension combinations. This fact made the bank reconciliation process more difficult because the bank deduced all vendor payments made in one single amount, which had to be matched with the numerous transactions recorded on the Dynamics AX bank account.


The next screenshots exemplify how the payment proposal was created and the vouchers and bank transactions resulting from posting the payment journal.

Example – creation payment proposal

Example – voucher created for the first journal line

Example – bank transactions posted


A) Change journal setup
In order to get the transactions posted on the bank account summarized, a new vendor payment journal was setup with the following (modified) settings:
Note: Previously the parameter ‘new voucher’ was set to ‘in connection with balance’ and the ‘detail’ level was previously set to ‘details’.

The result of this first change in the setup was that Dynamics AX created one single voucher for all lines included in the vendor payment journal. However, there were still a number of postings created on the company’s bank account, as the next screen-print illustrates. EN_133_25


B) Change bank account setup
The underlying reason why Dynamics AX did not summarize the transactions made on the bank account were the different financial dimensions used at the invoice level that got inherited to the bank account. This can be identified from the previous screen-print, which shows that the bank account transactions were posted with the financial dimension ‘cost center’ no. 022, 023 and 024.

In order to avoid this problem, default financial dimension values were setup at the bank account level. For details, please see the following screen-print.
With this setup in place, the expectation was that only one single posting on the bank account is created when posting the vendor payment journal. However, the setup changes made had no influence on the outcome, as the next screenshot proves.
Once again the financial dimension inheritance from the vendor invoice level that was overwriting the default financial dimension setup at the bank account level was the underlying reason that prevented a summary of the bank postings.


C) Change main account setup
To get the posting summary issue resolved, the main account associated to the bank account was finally setup with fixed financial dimension values, as illustrated next.
After creating another vendor payment journal, the following summarized voucher resulted, which shows only one single transaction on the bank account used.


D) Modification 1 – different payment dates
To test  the stability and reliability of the setup made, another vendor payment journal was created. This time, different payment dates were used for the lines included in the journal.

The outcome of this modified payment run was that Dynamics AX created several summarized bank postings – one for each day. The next screen-print shows the journal lines and the resulting vouchers.
Note: The major problem with the vouchers generated in the example is that Dynamics AX uses the same voucher number for postings made on different dates. This outcome is likely to result in problems with the company’s auditors, as all accounting standards the author is familiar with, do not allow such kind of postings.


E) Modification 2 – different methods of payments
The next modification made to test the stability of the setup was posting a payment journal with different methods of payments. The result of this second test run was that Dynamics AX still summarized all payments made in one single bank posting. For details, please see the next screen-print.


Within this post the possible summary of payments made into one single bank posting was illustrated. Please note that what has been shown above does also apply to bridge-payment scenarios where all vendor payments are initially made against a bridging ledger account that is in a second step posted against a bank / cash account.

An important prerequisite of the posting summary illustrated is that the payment account used in the vendor payment journal is setup with fixed financial dimension combinations. Otherwise, the financial dimensions used at the invoice level get inherited to the bank / cash account and result in a large number of bank postings.

In addition, it has been shown that the summary does only work as intended, if one single payment date is used in the payment journal. If this cannot be ensured, Dynamics AX will create vouchers that might be questioned by tax and corporate auditors.

Automatic posting of journals



The previous post dealt primarily with the question how the selection and posting of journals can be restricted. Within this post I would like to change the perspective and take a look at a function that allows a periodic posting of a number of journals that have been created.

The “post journals” functionality I refer to here can be found in the General Ledger module in the journal entries section. (In prior Dynamics AX versions it can be found in the periodic General Ledger module section).

As the information that has been provided e.g. on TechNet for the “post journals” functionality is a bit sparse and as several questions in regards to this function have been brought forward recently, I decided summarizing the different setup and processing options in this post.

Note: Please note that the following illustrations and explanations will only refer to posting General Ledger journals. The post journals function is, however, not limited to those kind of journals but can be applied to other journals as well. Please see the following summary.


In order to explain the different setup options of the post journals feature, I started setting up some daily General Ledger journals that included either no error (“OK”), some journal lines with errors (“Partly ok”) or only erroneous lines (“Error”). The next screenshot exemplifies the setup of some of those journals used.


Option 1: Select the journals, and post them
Once all demo journals have been prepared, I opened the post journals window and selected them through the identic button.
EN_127_0010 EN_127_0015
After all journals have been selected, the posting process was initiated by hitting OK button in the post journal form.
The result of this first posting test was that all journals except the ones that contained errors were posted.
Newly created journals that did not contain any error remained, however, unposted.


Option 2: Select the journals and post them by using a batch job
To get also those journals automatically posted that have been created later on, I deleted all unposted previously generated journals, setup some new ones and selected them as before in the post journals form.
This time I changed the posting process by making use of a batch process that runs every some minutes and that does the posting for me.
As before, all journals have been posted except the ones that contained errors.
My next step was setting up a new journal (No. 188) that did not contain any error.
Because of my posting setup I expected that the batch process will pick up the newly generated journal and post it. Yet, as nothing happened, I finally checked the batch job history window and noticed that the batch job stopped because it could not process the first two journals that contained erroneous lines. Please see the next screen-print.


Option 3: As option 2 & select the transfer errors checkbox
As processing newly created journals did not work with the previous approach, I repeated the earlier setup steps and created a number of new journals. This time I tried processing them by selecting the ‘transfer errors’ checkboxes (please see below).
As expected, all journals except the ones that contained errors were posted. After setting up a new journal that contained no error I expected that this time the newly created journal will be posted.
Yet, unfortunately nothing happened to the newly created journal as the batch job stopped as before after detecting errors.
Note: The difference between the 2nd and 3rd setup option is related to the journal that was partly ok. That is, this time all journal lines that did not include an error in the original (partly correct) journal No. 189 were posted and the journal lines that contained errors were transferred to a new journal No. 191 that contains only the erroneous lines.


Option 4: As option 3 but with the late selection and transfer errors checkbox activated
Since none of the prior setup options successfully posted the journals that I created subsequently, I changed the setup in the post journals form once again. This time – after selecting the journals that I want to post – the “late selection” and “transfer error” parameters were activated as shown in the next screen-print.
This time all erroneous journals/journal lines remained unposted as before but the journal that I created later on – in my case journal No. 196 – was finally picked up by the batch process and posted automatically as the following screen-prints prove.
EN_127_0080 EN_127_0085
Note: Despite the fact that the newly generated journal was successfully posted, the batch job still continued running (and ending) with errors because of the two journals that contained lines with errors.
Even though this issue in not directly related to the journal posting process itself, it can become quite cumbersome, as it might flood your mailbox with error messages / Emails if alerts and/or Email notifications have been setup that control the processing of batch jobs.

Journal restrictions


, ,

Over the last couple of months I noticed that people often get confused about the setup of journals and posting restrictions. Within this post I aim to shed some light on the following questions that I often came across:

Question 1:
How to ensure that only specific users can select their journals? Example: Only the chief accountant shall be able to create a new General Ledger journal?
Question 2:
How can you prevent others from posting your journal?

In order to answer the first question I setup the following new General Ledger Journal. Please note that this journal is linked to the user group “DOC” that only has a single user assigned to it.
After setting up the new journal, I logged into Dynamics AX with the respective user account (“DOC”) and created a new journal.EN_AX7_122_0010
After logging into Dynamics AX with a different user account I tried to identify the journal that has been created by the chief accountant “DOC”. Yet, after opening the General Ledger journal form I could not identify (and post) the journal because it was setup for the users included in the user group “DOC” only.
Please note that I also could not create a new “DOC” journal, as the “PROF” user account was not included in the respective user group linked to the journal.

For answering the second question, I setup a new journal that I did not link to a user group. Rather than that, I specified that all of my users can only post the journal they created.
After setting up this second journal, I logged into Dynamics AX as chief accountant “DOC” and created a second journal.

After logging off and logging on again with a different user (“PROF”) I could identify the journal that was created by my chief accountant (“DOC”). Yet, once I tried posting the journal I noticed that I could not post it because of the posting restrictions setup.

To sum up, by linking a specific user group in the blocking section of the journal names setup form you can allow only specific people creating and posting specific journals.
The posting restriction feature allows identifying journals that have been created by other users but can prevent other people from posting journals that you created. However, this requires that you specify and select those users that face this restriction as Dynamics AX does by default not restrict any user from posting other people’s journals.


Hope that this post shed some light on the setup of journals and posting restrictions and look forward to seeing you in the next posts again.

Parallel accounting according to the “Cost of Sales” and “Nature of Expense” accounting method (5)


, , ,

C.6. Sale of goods
Within the last part of this series on the COS & NOE accounting method, the item that has been produced before will be sold for 1000 EUR / pcs through a standard customer sales order shown in the next screen-print.

The first sales order related voucher is created when the sales order packing slip is posted. In the example used, Dynamics AX created the following voucher:
As only Balance Sheet accounts are addressed, no influence on the company’s Income Statements can be identified and as a result, no difference between the COS and NOE method arises.

The next and final posting step in my example is related to the sales order invoice. The voucher created when posting the invoice is shown in the next screen-print.

For reasons of clarity and traceability, the vouchers created when posting the sales order packing slip and sales order invoice, have been summarized in the next illustration.

  • Similar to the previous chapters, all transactions that offset each other have been highlighted in grey color. In the example used, the packing slip voucher is reversed with the posting of the sales order invoice.
  • All accounts highlighted in green color represent Balance Sheet accounts that debit a receivable account and credit the inventory account that traces the stock reduction due to the sale of the finished item.
  • The first yellow highlighted Income Statement account no. 40500 records the sales revenue of 1000 EUR. This transaction is self-explanatory. The posting on the second Income Statement account no. 50500 on the other hand requires some explanation, as it is used and interpreted differently from a COS and NOE accounting perspective. That is, from a COS perspective the amount recorded on ledger account no. 50500 is included in the cost of sales section and directly influences (reduces) a company’s profit. The reduction in a company’s profit does also occur when the NOE method is applied. Yet, for the NOE method this account represents a stock variation account and consequently needs to be included in the stock variation section of the company’s income statement.

The following financial statements summarize the sales order related transactions resulting from the sales order invoice posting.


D. Summary
Within this series on the COS and NOE accounting method I demonstrated that Dynamics AX can be setup in a way to generate financial statements that follow both accounting methods in parallel. This also holds for situations where other inventory valuation principles, such as standard costs, moving average costs, etc. are used.

Irrespective of those valuation principles and differences thereof, the key to a successful parallel implementation of both principles is a “correct” setup of your chart of accounts and related account structures.


Parallel accounting according to the “Cost of Sales” and “Nature of Expense” accounting method (4)


, , ,

C.5. Production of goods
Probably the most complex part when it comes to setting up the COS and NOE method in parallel is related to the production of goods. That is mainly because the production posting setup does not only require a setup of the inventory posting matrix but – depending on the parameter setup – also makes use of other accounts that are setup e.g. at the resource level, production category level and in the costing sheet.


  • It is not feasible showing you all possible ways for setting up production related postings. Rather than trying to do that I will exemplify the setup based on a simple production item. You can use this basic setup then and apply it to more complex production scenarios.
  • To keep things as simple as possible, I do not create transactions that result in production related variances e.g. due to additional raw material consumption, changed execution times and so on.
  • All production postings illustrated in the following are based on the ledger principle “item and resource” that can be found in the production control parameters form.

Irrespective of the specific ledger setup for production related postings, the basic production process in Dynamics AX follows a three step procedure that begins with the start of a production order, continues with reporting the production order as finished and finally ends with the closing or “costing” of the production order. Those basic production steps and the related postings executed are illustrated in the next diagram, which will be used as a guideline for the subsequent illustration of the production related postings for a production item.
The structure of the production item I referred to above can be identified in the next screen-print.
The cost price calculation screen shown above illustrates that the production item (FG2000) consists of two raw materials (RM300 and RM400) that have a cost price of 10 EUR / pcs each. For the production of this good one piece of the first raw material (RM300) and two pieces of the second raw material (RM400) are required. In addition, for the assembly of the product a worker has to work one hour on a machine that has a total cost price of 270 EUR / hour. Based on those data a total production cost price for the production item of 300 EUR / pcs arises.


C.5.1. Production step 1: Start
For reasons of simplicity, the production parameters used in this example have been setup in a way that the material consumption (BOM) and route consumption are immediately posted when the production is started. The next screen-print shows the vouchers that have been created through the posting of the BOM and route journals.
The effect that these vouchers have on the financial statements of the company can be identified in the next illustration.
From a Balance Sheet perspective, the production start related postings are reflected in changes that can be observed on the WIP accounts no. 13430 and 13440. For the raw material consumption another Balance Sheet account (no. 13150) has been used as the offset account and the offset account for the route consumption has been posted on an Income Statement account (no. 60110).


Given that the NOE accounting method typically uses stock variation accounts for each and every change recorded in the company’s stock level, the question arises how the raw material related postings that were executed with the start of the production order can be explained / justified?
I will try answering this question based on the following illustration that shows the recorded accounting transactions in the upper part and the missing “in between” stock variation accounts in pink color in the lower part.
What becomes obvious from this illustration is that the approach followed here is not fully correct in the sense that the pink transactions highlighted above are missing.
An important question at this point is whether those missing transactions result in a critically wrong illustration of a company’s financial position or not.
From the author’s perspective the “missing” pink transactions are not critically important as they do not distort the financial position of a company that follows the NOE accounting method. That is because the NOE Income Statement does on the one hand side summarize all stock variation transactions into a single line. On the other hand side, one has to remember that the pink highlighted lines add up to zero and do thus have no impact on the company’s financial position.


The second transaction I would like to discuss in more detail here is the route related voucher that credits an Income Statement account (no. 60110 “production wages clearing”) and thus affects the profit of the company.
From a NOE accounting perspective this account / transaction can be explained by stating that the clearing account used represents a part of the stock variation of the company. In other words, the increase in semi-finished products for the route consumption part on account no. 13440 is offset by the “stock variation” recorded on account no. 60110. For that reason, the production wage clearing account has been assigned to the stock variation section in the Income Statement that follows the NOE accounting method.
If you take a look at the Income Statement that follows the COS method, you can identify that the very same account no. 60110 has been included in the section that incorporates the production wages recorded before. Irrespective of the whether the name and the section where those accounts have been assigned to is correct, the question that arises how one can justify the assignment of the production wages clearing account there?
From the authors perspective this assignment can be justified by interpreting the transaction recorded on the production wages clearing account as a kind of allocation that shifts a part of the total production wages from the company’s Income Statement into its Balance Sheet.
Stated differently, the production salary / wages posting recorded before immediately reduces a company’s profit. The start of the production on the other hand side creates a tangible value for the company in form of a (semi-) finished product and thus increases its overall wealth. This wealth increase is reflected on account no. 60110 in the company’s Income Statement.


C.5.2. Production step 2: Report as Finished (RAF)
The next production step consists of reporting the production as finished. Executing this production step results in the following voucher that debits and credits a Balance Sheet account with the total production cost amount of the item.
As only Balance Sheet Accounts are used for recording the RAF transaction, no difference between the COS and NOE method arises.


C.5.3. Production step 3: End the production order
The last production step ends the production order and ensures that the realized production costs get posted. Dynamics AX realizes this by reversing and replacing all prior production postings that have been recorded based on planned cost values with postings that are based on realized ones, that is, actual cost values. In the example used, the following costing voucher results.
Note: The lines that have been selected in the prior screen-print reverse the prior postings that have been created during the first two production steps.
The outcome of the production postings generated can be identified in the financial statements illustrated next.

Interpretation of the production costing posting created

Lines highlighted in light green color
* The amount of 300 EUR recorded on ledger account 13470 represents the stock increase resulting from the production of the finished good.
* The negative amount of 30 EUR that Dynamics AX credits on ledger account no. 13160 represents the reduction in raw materials that have been used for producing the finished good.

Lines highlighted in yellow color
* The three ledger accounts no. 53420, 53410 and 53170 are Income Statement accounts that – from an overall perspective – offset each other. That is, the total amount posted on those accounts adds up to 0 EUR.
* A first reason why these accounts were setup this way is to get the production costs – of 270 EUR for the production worker and 30 EUR for the raw materials consumed – transferred into the cost accounting module for subsequent cost analysis.
* A second reason for using this specific production posting setup is related to the NOE method as the accounts highlighted in yellow color represent stock variation accounts. The next illustration exemplifies this in detail by showing that those accounts are used “in between” each and every stock transaction.

Lines highlighted in white resp. orange color
* The lines highlighted in white color in the first screen-print of this section – resp. the orange line in the illustration above – shows the production costing voucher which posts 270 EUR on ledger account 60120 that arose for the assembly of the production item.
* As explained further above, from a NOE perspective, this account represents a stock variation and is consequently included in the cost variation section of the company’s Income Statement following the NOE accounting method.
* For the COS method reference can also be made to the interpretations from production step 1. That is, the amount recorded on ledger account 60120 represents an amount that allocates costs from the company’s Income Statement into its Balance Sheet and offsets the value increase caused by the production of the finished good.


To be continued in part (5)

Parallel accounting according to the “Cost of Sales” and “Nature of Expense” accounting method (3)


, , ,

After analyzing purchase related transactions in the previous chapter we will now move on and take a look at the other business areas where differences between the COS and NOE accounting method can be identified.

C.2. Inventory adjustments
The next area where such differences can be recognized is related to adjustments of a company’s inventory. Whether or not the COS and NOE accounting method can also be applied in parallel for inventory related adjustment transactions will be investigated next based on the following sample transactions.
Note: Transfer orders within and between sites/warehouses and other item related transactions that do not generate ledger vouchers will not be analyzed in the following.

For reasons of brevity, no Dynamics AX screen-prints of the created inventory adjustment postings will be provided but rather a summarized overview of the ledger postings created when recording those transactions (please see the next illustration).

Note: The main accounts required to be setup for the inventory adjustment transactions recorded can be found in the inventory section of the inventory posting matrix shown in the next screenshot.

Once all four inventory adjustments are posted, the following result can be observed in the company’s financial statements:
In the prior illustration one can see that the Income Statement that follows the COS method incorporates the inventory profit and inventory loss accounts (no. 53150 & 53160) in the cost of sales section. Whether or not those accounts are better assigned to another Income Statement section – such as the other operating expense section – is not important for the general question whether or not the COS and NOE accounting method can be applied in parallel for inventory adjustment transactions.
What is important though is the question where to incorporate the inventory profit and inventory loss accounts according to the NOE method. Against the background of the explanations provided before, this question can be answered by stating that those accounts need to be incorporated into the stock variation section of the company’s Income Statement. That is because those inventory adjustments represent nothing else than “small” stock adjustment transactions that replace the “large” month-end stock variation transaction required for the NOE method.


C.3. Salary/wages & other operating expenses
Within this subchapter I will deal with the question how to record and disclose salary/wage & other operating expense related transactions in the financial statements that follow the COS and NOE accounting method.
The major difference to what has been shown previously is that the separation of the transactions according to their function of expense is now made through referencing the financial cost center dimension as exemplified in the next illustrations.
EN_91neu_0300 EN_91neu_0305
The financial statements resulting from the transactions recorded can be identified in the next screen-print.
An investigation of the Balance Sheet related transactions does not bring a specific notable outcome to light that deserves special attention. That is because the amounts shown on the other liabilities & accounts payable accounts (no. 22600 and 22500) increase due to the salary/wage & electricity expense transactions recorded.
What is notable though are the account balances shown in the Income Statements for the COS and NOE accounting method. In this respect it can be observed that the COS Income Statement shows the different amounts split up by functions (cost centers) whereas the NOE Income Statement shows those amounts on a summarized basis. Another disadvantage of the NOE method is thus that this method does not provide users with the same level of detailed information as the COS method.


C.4. Fixed asset acquisitions & depreciations
Recording and disclosing fixed asset related transactions does – in principle – not differ from the salary/wage & other operating expense transactions shown in the previous chapter. That is because also for fixed asset related transactions a separation of the different transactions through the use of a financial dimension is necessary in order to generate the Income Statement for the COS method.
Within the example used in this subchapter, several fixed assets have been setup and acquired first (please see the next screen-print) …
… before the related depreciation expense transactions were recorded.
The outcome of those transactions can be identified in the next Management Reporter report that shows the fixed asset acquisition and fixed asset accumulated depreciation accounts in the company’s Balance Sheet on the left-hand side.
In the middle part of the report one can identify the Income Statement that follows the COS method. From there it can be observed that the depreciation expense is split up by corporate functions by making use of the recorded financial (cost center) dimensions.
The Income Statement following the NOE method illustrated on the right-side does – on the other hand – summarize those transactions in a single line and does thus not allow an immediate analysis of the expenses recorded.


Intermediate result
In addition to the purchase related item transactions shown in the previous part, it can be summarized that also transactions related to inventory adjustments, salary/wages and other operating expeses as well as fixed asset related transactions can be posted in a way that allows the parallel generation of Income Statements that follow the COS and NOE method.
Please not that you can of course also use separate “function-related” ledger accounts – rather than financial dimensions – for separating the different corporate functions in the COS Income Statement report.
Yet, irrespective of what approach you chose for separating the different corporate functions (financial dimensions or separate ledger accounts), the most important thing that you have to take care of is that a consistent and integrated approach is followed in your company which ensures that the financial reports according to both accounting methods can be generated out of the box.


To be continued in part (4)

Parallel accounting according to the “Cost of Sales” and “Nature of Expense” accounting method (2)


, , ,

Posting 01 January: Packing slip raw material 1
The packing slip transaction for the purchase of the first raw material results in the following voucher.
This voucher debits a product receipt account for the purchased material (account no. 13110) and credits the purchase accrual account (no. 22550). As both accounts are Balance Sheet accounts, no effect on the company’s Income Statement can be identified.
The following illustration summarizes the company’s Balance Sheet and its Income Statements according to the COS and NOE method and demonstrates that the packing slip transaction does not affect the company’s profit.

Outcome – after packing slip posting


Posting 02 January: Vendor invoice raw material 1
The next step in the purchase process is related to recording the vendor invoice. The invoice voucher created does first reverse the previous packing slip transactions. At the same time a stock increase (on account no. 13120) and an increase in vendor liabilities (on account no. 22500) is recorded.
Because of the automatic charge code that has been setup, an additional transaction equivalent to the item purchase amount is recorded on the raw material expense and stock variation accounts no. 53130 and 53140. The next two screen-prints summarize the voucher created and show its influence on the company’s financial statements according to the different accounting methods.

Outcome – after invoice posting
Note: As the raw material expense and stock variation account are both assigned to the cost of sales section of the company’s Income Statement that follows the COS method, no effect on the company’s profitability, KPI’s, etc. results.


Posting 03 January: Packing slip raw material 2
The voucher generated with the packing slip posting for the second raw materials purchase is identical to the one created for the first raw material. For that reason, everything that has been mentioned before for the first raw material purchase also applies here. The next screen-prints detail the resulting packing slip voucher and financial statements.

Outcome – after packing slip posting


Posting 04 January: Vendor invoice raw material 2
As also the invoice voucher for the second raw material debits and credits the same ledger accounts that have been used when the posting the vendor invoice for the first raw material, reference can be made to what has been mentioned above.
The only major difference between the first and second raw material purchase is reflected in the invoice voucher. That is, for the purchase of the second raw material the slightly higher purchase price of 12 EUR / pcs. results in a stock increase of 12000 EUR that is recorded on the respective ledger account no. 13120.
In line with this stock increase, an equivalent transaction on the raw material expense and stock variation accounts can be identified. For details, please see the postings on accounts no. 53130 and 53140 and the resulting financial statements shown next.

Outcome – after invoice posting


Posting 05 January: Packing slip vendor return raw material 1
The return of the first raw materials that did not pass our quality tests results in vouchers that are – except for the sign – identical to the one’s recorded before. For that reason, reference is made to the previous explanations.

Outcome – after packing slip posting


Posting 06 January: Vendor invoice vendor return raw material 1
What has been mentioned for the packing slip voucher generated also applies for the credit note “invoice” voucher. In this respect I would especially like to draw your attention on the parallel raw material and stock variation posting created for the vendor credit note shown in the following screen-print.
The overall result from all of the transactions recorded within this subsection can be identified in the next screen-print that summarizes the effects of the postings on the company’s financial statements according to the COS and NOE accounting method.

Outcome – after invoice posting


Dynamics AX uses the so-called running average cost price when issuing goods. With the recording of the vendor return transaction such an issuance occurs. As the running average cost price cannot directly be influenced by users and regularly differs from the price that our vendor credits for the item return, a temporary difference between the stock and stock variation accounts might result.
In the long-term this (temporary) variance will be offset through the transactions recorded when closing the company’s inventory. However, in the short-term an additional transaction on the “purchase expenditure, un-invoiced” resp. “purchase expenditure for product” accounts might occur.
The next screen-prints exemplify such a situation, where the amount credited by the vendor (10 EUR) differs from the running average cost price (11,83 EUR).
To ensure an always consistent and correct illustration of the company’s Income Statement according to the COS and NOE method it is thus recommendable to setup…

  • the same ledger accounts in the “cost of purchased materials received” and “purchase expenditure, un-invoiced” section and to setup…
  • the same ledger accounts in the “cost of purchased materials invoiced” and “purchase expenditure for product” section.

Please note that this setup is not obligatory but can make the analysis and interpretation of transactions recorded in Dynamics AX easier. The following screen-print shows the setup just described for the first two account sections mentioned.


Intermediate result
The following illustration summarizes all ledger postings created within this subsection.

  • Transactions that offset each other are highlighted in grey color. Transactions that do only affect the company’s Balance Sheet are highlighted in green color and the Income Statement related transactions required for the NOE accounting method are highlighted in yellow color.
  • In order to follow up the different transactions, the posting types used have been entered in square brackets just below the ledger accounts used.
  • Tax related transactions are disregarded in order to keep things as simple as possible.


Based on the transaction summary shown in the previous illustration it can be concluded that the COS and NOE accounting methods can be applied in parallel in standard Dynamics AX. In this respect is has been shown that the shortcoming of the standard AP parameter “post to charge account in ledger” can be overcome by using an automatic charge code.


To be continued in part (3)