Return order cost prices & devaluations

Tags

, ,

Recently, I was asked by a colleague how to devalue items that have been returned from a customer. As I believe that the one or other reader came across similar issues, I summarized some of the pitfalls one should be aware of when recording item returns from a customer.

 

Scenario:
Some time ago 1000 pcs of an item have been purchased for a cost price of $100/pcs. Later on, 100 pcs were sold to a customer for a sales price of $200/pcs. After the customer noticed that he ordered too many of the items, he returned 20 pcs, which shall be devalued as they have been polluted.

The return of the items from the customer was recorded through the standard return order form. As the originally sales order through which the items have been sold was not known, the ‘find sales order’ button was used. The next screen print illustrates this.

204_0005

Once the sales order was identified, the return quantity was entered in the return quantity field and confirmed with OK.

204_0010

Confirming the return quantity this way resulted in the automatic creation of a return order line that was linked to the original sales order. For that reason, the return cost price – which can be identified in the return order line details section below – could not be edited.

204_0015

Once the returned items were registered and packing slip updated, I tried to outsmart the system by changing the return cost price in the sales order form right before posting the credit note for the customer.

204_0020

Unfortunately, this trick did not help and had no effect on the cost price that was posted with the item return. The next screen print demonstrates this by showing a posted return cost price of $2000 for the 20 pcs recorded.

204_0025

warningsignklein Please note the highlighted lot id fields, which illustrate that the original sales order (no. 000800) is linked to the return order (no. 000801).

 

Because the return order was posted with the original cost price, I tried recording a cost adjustment through the inventory closing and adjustment form illustrated in the next screen print.

204_0030

Unfortunately, also this did not help because the only transaction available for adjustment was the original purchase order through which the items were originally purchased.

204_0035

warningsignklein After posting an inventory close, the on-hand adjustment form/option became available. Yet, as I was interested in adjusting only a subset of the total on-hand amount, I gave up on this way of making the value adjustment.

 

Rather than trying to correct the return order transactions with hindsight, I created a second ‘test’ return order for 10 pcs in order to differentiate it from the first one. This time the return order was recorded without making use of the search functionality but by entering the return order line directly. As the return order line was not linked to the original sales order, I could adjust the return cost price that was finally used when posting the return order credit note. The next screen prints illustrate this.

204_0045

204_0050

warningsignklein As the return order was not marked against the original sales order, I was even able to make an adjustment to the return cost price through the inventory closing and adjustment form. For details, please see the next screen print.

204_0055

warningsignklein An alternative to manually entering the return order lines without referencing (marking) the original sales order is making use of charge codes that can be linked either to the return order directly or to the disposition codes as exemplified in the next figure.

204_0060

The major disadvantage of those charge codes is that they cannot be setup for item transactions and can thus only be used for creating general ledger accrual transactions that do not have a direct influence on the inventory value in the inventory module.

 

Summary:
This post summarized some of the pitfalls one should be aware of when it comes to the devaluation of item returns from customer. The main issue one needs to be aware of is that the search functionality in the return order form marks the original sales order and the return order, which does not allow users modifying the return order cost price.

2 YEARS DYNAMICS AX FICO BLOG

Tags

It is now over two years that I started this blog.
I would like to take this opportunity to thank all of you for reading, sharing and commenting on the various posts that have been published here.

To makes things even better in the future and write about topics that are of interest to you, I prepared some short questions and would be happy if you could provide me some feedback.

Feel free to leave additional comments. Many thanks for your help!
P.S. For those of you who answered the questions and who are interested in purchasing the project accounting and controlling book that has been released recently, here is a $15 discount voucher that is valid for 2 weeks time (SXAD3AFC) for purchases through the CreateSpace e-shop.

Link multiple Management Reporter reports

Tags

,

Linking different Management Reporter (MR) reports is a common finance scenario when for example the profit/loss from the Income Statement (IS) is linked to the equity section of the Balance Sheet (BS).

Microsoft provided a detailed description, which exemplifies how this linkage between the IS and BS reports can be established. For details, please see the following website.

Some time ago I was confronted with the requirement of linking multiple MR reports to a newly created one. As Microsoft already provided a detailed description of the necessary setup steps, I initially thought that linking multiple MR reports just follows the same principle, which is required for linking a single report.

For that reason (and based on the Microsoft guideline), I simply added two instead of a single row link in my MR row definition to get the data from the BS and IS report loaded into my newly created report. The next screen-print exemplifies this setup, where the first row link (‘BS’) links to the Balance Sheet report and the second one (‘IS’) links to the Income Statement report.
en_202_0005

The row definition of my newly created report consequently includes two rather than a single column that reference the cells in the already existing MR reports through the ‘@WKS(…)’ fields.
en_202_0010

The column definition used was identical to the one used in the Microsoft guideline and included only a single FD (financial dimension) column. The next screen-print illustrates the setup of this so-called column definition.
en_202_0015

After having done all the setups that I considered important, I was very much disappointed once I noticed that the report did not include the IS data.
en_202_0020

Some additional investigation of the report creation process lead me to the report queue status form where I noticed the following message:
en_202_0025

Based on this warning message, the report setup with the two row links obviously seemed to be the wrong approach to incorporate data from multiple other MR reports into my newly created one. To get this corrected, I first changed the link type for the Income Statement data to ‘Management Reporter Worksheet’.
en_202_0030

In line with this change, the cell reference was changed from ‘@WKS(B=C35)’ to ‘C35’ and a column restriction was incorporated into the row definition setup, which is exemplified in the next screen-print.
en_202_0035

In addition, a reporting tree was setup, which linked to the different financial dimensions/worksheets specified in the row definition setup form. Example:
en_202_0040

warningsign1 It is important that all financial dimensions/worksheet references, which are specified in the row definition form are included in the reporting tree. Otherwise, the report generation will interrupt with an error message.

The last setup required relates to linking the different reporting tree elements to the report columns. How this linkage can be established is illustrated in the next screen-print.
en_202_0045

With those report modifications in place, the report could finally be created and showed all the data retrieved from the other MR reports. The report could of course be further refined by including the values shown in the FD and WKS column into a single one. For reasons of brevity this exercise is, however, skipped here and left as an exercise for the reader.
en_202_0050

warningsign1In order to allow you a direct comparison with the Microsoft guideline referenced in the beginning, all setups and reports exemplified in this post have been created with the MR version CU12. In more recent MR versions, the link type ‘Financial dimension + Worksheet’ has been removed. As a result, linkages to multiple MR reports can only be realized through the ‘Management Reporter Worksheet’ link that has been used for incorporating the IS data above.

A note on committed project costs

Tags

, , ,

Project related expense invoices can be recorded in a number of different forms and journals, such as the Accounts Payable (AP) invoice journal, the project expense journal or the AP invoice workbench, to mention only some. When it comes to expense invoice recording for projects, an important consideration is the time at which those expenses can be identified at the project level. The timing aspect is important especially in companies that face long invoice throughput times due to detailed invoice control and approval procedures.

To identify process related differences in expense invoice recording, an expense invoice for $150 will be recorded next through a standard AP invoice journal. This process will then be compared with entering a similar invoice through the so-called invoice workbench.

Let’s get started with the process of recording an expense invoice for a project through a vendor invoice journal, which is shown in the next figure. Please note that the vendor invoice line and the project to which the expenses are posted to, are shown in the upper part of the next screen-print whereas all project specific information is included in the project tab shown in the lower part of the same screen-print.

en_200_0005

As one might expect, after recording the invoice but before posting it, no costs can be identified at the project level. Please see the next figure.

en_200_0010

Once the invoice is posted, the respective project expenses are recorded as actual project costs. This can be identified from the actual cost column of the cost control window shown in in the next screen-print.

en_200_0015

 

 

Let’s now have a look at what difference recording a similar invoice through the vendor invoice workbench – exemplified in the following screen-print – makes.

en_200_0020

Except for the way how the expense invoice data are entered, the same information is recorded in the vendor invoice workbench shown below.

en_200_0025

Yet, different from before, the project expense can already be identified at the project level, once the invoice has been recorded. For details, please see the project expense amount shown in the committed cost column of the cost control form that is illustrated in the next figure.

en_200_0030

It is this ability of showing recorded project expenses early that differentiates the process of entering project related expense invoices through the vendor invoice workbench from recording them through vendor invoice journals. A knowledge of this difference is important especially in companies that see long invoice throughput times because an early identification of (forthcoming) project expenses can avoid wrong interpretations and subsequent actions.

Note: A prerequisite for becoming able to identify project expenses early through the committed cost functionality is the activation of the corresponding project cost control parameters shown in the next screen-print.

en_200_0035

In addition, a periodic batch job needs to be setup that identifies and illustrates the committed costs at the project level. Example:

en_200_0040

Summary:
Using the committed cost functionality can be of vital importance for companies that face comparatively long invoice throughput times. Companies with short invoice throughput times do, on the other hand side, not considerably benefit from using the committed cost invoice feature that is only available for invoices recorded through the vendor invoice workbench. Expressed differently, companies, with short invoice throughput times have a greater flexibility when it comes to entering expense related project invoices.

Timesheets & missing working time

Tags

, ,

Before invoicing project customers and/or preparing the month-end close, it is a common practice to verify that all employees have recorded their working time. Dynamics AX supports this verification process through the missing timesheet report shown in the next screen-print.

en_140_0005

Note: The manager that can be identified in the last column of the missing timesheet report is the one that is specified in the ‘reports to’ field of the employee’s position assignment and can be found in the Human Resource (HR) module.

An alternative to generating the missing timesheet report is using the periodic missing timesheet email notification functionality. This periodic process sends automatic email reminders to those employees – not their superiors/managers (!) – that have not recorded their working time through timesheets. The content of the email is thereby defined in an email template, which needs to be linked to the Email Id field in the project parameters form shown in the next figure.

en_140_0010

A major problem with the missing timesheet report (and the email notification process) is that it only verifies that some working time has been recorded. It does, however, not check whether and how much time is missing. The following screen-prints demonstrate the aforementioned by showing the content of the missing timesheet report for an employee (‘Julia’) that creates and saves her timesheet in a first step, submits it later on and finally gets it posted.

Step 1: Create & save timesheet

en_140_0015

Step 2: Submit timesheet

en_140_0020

Step 3: Post timesheet

en_140_0025

As one can identify from the previous screen-prints, the missing timesheet report does not include the employee (‘Julia’) anymore once the timesheet has been posted. This outcome is quite astonishing because only a single hour of working time has been recorded, which is by far less than what has been contractually agreed upon with the employee (40 hours/week).

Against the background of this result, it can be summarized that the missing timesheet functionality and the periodic email notification process are per se not sufficient to ensure that employees recorded all of their working time.

If the missing timesheet functionalities are not sufficient to verify whether or not employees recorded all of their working time, the question arises what other additional instruments are available that can help ensuring that employees record at least their contractually determined working time.

The main instrument available for that purpose is the timesheet policy feature. Provided that the contractual working time of employees is setup in a calendar and given that the timesheet policy prevents employees from submitting their timesheets if less than the contractually determined working time has been recorded, one can ensure that employees record their complete working time. The following example demonstrates how this can be achieved based on the timesheet policy configuration shown in the next screen-print.

en_140_0030

The timesheet policy illustrated in the screen-print above prevents users from submitting and posting timesheets with less than 40 hours working time recorded. Timesheets that include less hours – such as the one shown below – cannot be submitted and will consequently be picked up in the missing timesheet report. The following screen-prints exemplify this system behavior.

en_140_0035 en_140_0040

Please note that what has been said for timesheets that include less time than the one specified in the timesheet policy also applies for employees that have not even created a timesheet. It is thus the combined application of the timesheet policy and the missing timesheet report which help ensuring that employees recorded all of their working time.

Note: The illustrated timesheet policy and application of the missing timesheet report assume (a) that employees submit their working times only once a week in a single timesheet and (b) that employees record their full working time including absence times for holiday, illness, etc. Through a slightly different setup, the same result can also be achieved if employees are supposed to record their working time on a daily basis.

Project related intercompany cost allocations (3)

Tags

, , ,

Example 3: Revenues realized at the subsidiary level are allocated back to the corporate headquarters level

Part A: Scenario
The underlying scenario for the subsequent illustrations and explanations is the development of a software product by the corporate headquarter company that requires regular updates and maintenance e.g. in order to comply with changes in legal regulations.
The initial development of the software product was completed by a team of developers from the corporate headquarters company (USSI) several years ago. All costs related to this product development were recorded on an internal development project U1 that was closed after the initial product development ended. Thereafter, all costs related to product updates and changes are tracked in a separate project U2.
In order to run & treat the internal product development team as a profit center and not a cost center, the corporate management decided that the subsidiaries that make use of and sell the software product need to pay a fraction of their sales revenue to the corporate headquarters as a license fee. All respective intercompany contracts have been signed and need to be applied in the ERP system. How this application can be realized in standard Dynamics AX will be subject of this post.

Before digging into details, let’s have a quick look at the following illustration that shows the different companies and projects involved in this scenario.
EN_132_0005

 

Part B: System setup

Setup B.1: Intercompany dummy vendor account company FRSI & GBSI
Similar what has been shown in the prior post on intercompany costs allocations, the first thing that needs to be setup are intercompany dummy vendor accounts. The only difference to what has been described in the previous post is that two rather than a single dummy vendor account need to be setup.

Setup B.2: IC customer & vendor accounts
The second setup step is also identical to the one shown in the prior post. However, slightly different from before, intercompany customer accounts need to be setup in the subsidiaries FRSI & GBSI and two separate intercompany vendor accounts in the corporate headquarters company USSI.

Setup B.3: Project category setup
The third setup step relates to the project category setup, which is required for the intercompany invoicing and transaction recording. Different from before, this time, two separate project categories – one for each subsidiary – need to be established because the project ledger posting setup in the project module does not allow a separation based on the company account.
ENx_132_0010
Please note both categories are linked to the transaction type “expense”.

Setup B.4: Procurement category setup company FRSI/GBSI
Also the setup of the procurement categories is mainly identical to the setup that has been shown in the previous post except that two rather than a single procurement category need to be setup – one for each subsidiary.
ENx_132_0015

Setup B.5: Project setup companies
The project setup in the different companies involved in the intercompany scenario follows the structure shown in the graphic of the initial scenario section above. The next screen-prints exemplify how the corresponding projects are setup in the headquarters (USSI) and subsidiaries companies (FRSI & GBSI).
ENx_132_0020
ENx_132_0025
As mentioned in the prior post on intercompany cost allocations, there is nothing that requires special attention when setting up the different projects except that each of those projects should be linked to a default intercompany financial dimension value – at a minimum.

Setup B.6: Project posting setup
In regards to the project posting setup, reference can be made to what has been mentioned in the prior post except that the direction of the setup is flipped. That is, while intercompany revenue accounts need to be setup in the subsidiary companies (FRSI & GBSI), intercompany cost accounts need to be setup in the headquarters company. The same holds for the setup of the ledger posting integration for the procurement categories.

 

Part C: Process steps

Step C.1: Record transactions & invoice the external customer in FRSI/GBSI
Against the background of those setups, the first process step consists of recording costs and revenues on the external customer projects that are run in the subsidiary companies. For reasons of simplicity and brevity only hour transactions are recorded and subsequently invoiced for a single project in each of the subsidiary companies. The next screen-print shows the vouchers created in company FRSI for the time recorded and invoiced.
ENx_132_0030
As the vouchers created in company GBSI are basically identical to the one created in company FRSI, they are not explicitly illustrated here to conserve space. They are, however, included in the next accounting overview.
ENx_132_0035
(IC = Intercompany financial dimension, PRO = Project financial dimension)
The prior accounting overview shows ordinary project accounting transactions that debit a project cost account for the hours recorded and credit the payroll allocation account for the cost of those hours recorded. The second vouchers record the receivable against the external customer and credit a project revenue account (highlighted in yellow color).

Step C.2.: Record internal vendor invoice in FRSI/GBSI
Whereas most of you have seen and are familiar with the first process step, you might not have seen the following second one that posts an internal transaction on a dummy vendor account.
Slightly different from the prior post where only a single line was used to create a transaction on the internal dummy vendor account, this time two lines are recorded and posted. The first line is used to record an expense on the external customer project – in the screen-print below – in company FRSI. This expense transaction represents the license costs charged by the corporate headquarters to the subsidiary for using the developed software product.
ENx_132_0040
The second line is used for the subsequent creation of the intercompany credit note and consequently entered with a negative quantity & amount. Please note that this second line links to the support & maintenance project in company USSI.
ENx_132_0045
Note: Whereas recoding such internal transactions is feasible in situations where a limited number of external customer projects exist, it becomes infeasible in companies that run many external customer projects. What might help in those cases is the standard Excel-Addin for Dynamics AX that allows importing transactions into the invoice workbench form shown above.

The voucher resulting from posting the internal transaction can be identified in the next screen-print and is summarized in the next accounting overview.
ENx_132_0050
ENx_132_0055
The first notable outcome that can be identified from above is that no open vendor position is created on the internal dummy vendor account, as the two lines recorded offset each other.
In addition, the debit account transaction on the ledger accounts 707451 (FRSI) and 402451 (GBSI) – that represent the license costs for the use of the software product developed by the corporate headquarters (USSI) – lower the profit for those projects and allow project managers taking a look at the full costs of their projects. The next screen-print, which shows the project statement for the external customer project in company FRSI shows this in more detail.
ENx_132_0060

Step C.3.: Create intercompany credit note in FRSI/GBSI
The third process steps consists of creating the intercompany project invoices (credit notes) in company FRSI and GBSI. As this step mirrors the one shown in the previous post, reference can be made to what has been said there.
ENx_132_0065
ENx_132_0070
The voucher that results from posting the intercompany project invoice (credit note) can be identified in the next screen-print.
ENx_132_0075
As before, the next accounting overview summaries the postings recorded thus far.
ENx_132_0080
Please note that the accounts highlighted in light-grey color offset each other and do thus not exert an influence on the project and corporate profitability in the subsidiary companies.

Step C.4.: Post pending credit notes in USSI
The last process step described in this post consists of posting the pending vendor invoices (credit notes) in the corporate headquarters company USSI shown in the next screen-print.
ENx_132_0085
Posting those credit notes results in vouchers that debit – and therefore reduce – an intercompany liability account and credit an intercompany P&L account. For that reason, the profit in the corporate headquarters company increases correspondingly.
ENx_132_0090
The next accounting overview summarizes all transactions recorded within the four process steps shown above.
ENx_132_00100
The yellow-highlighted arrows and fields illustrate that a part of the revenue from the external customer projects in the subsidiaries (FRSI & GBSI) is shifted to the corporate headquarters company that developed the overall software product sold to the customer.
With this revenue shifted to the support & maintenance project in the headquarters company, a comparison of the initial development cost and the ongoing maintenance costs of the developed software product with the resulting license revenues can be made. This is a major prerequisite for treating the internal development team / project as a profit center.

 

Summary
Within this and the previous posts I illustrated how indirect costs can be allocated to projects – either within a single company or between companies – by using standard Dynamics AX functionalities. The major outcome of those posts is that the standard Dynamics AX tools do in general support all kinds of those project allocation scenarios require, however, the one or the other system modification in order to get the allocations fully automated.

Project related intercompany cost allocations (2)

Tags

, , ,

Example 2: Allocating the costs of corporate directors working in corporate headquarters to the projects setup in other companies

Part A: Scenario
The prior post introduced the standard project intercompany functionality for time sheet transactions. Within this post I would like to modify and extend this scenario by analyzing how the costs of corporate directors can be allocated to projects in other legal entities that they – at least from time to time – supervise.

An underlying assumption of this scenario is that the directors do not record their time in Dynamics AX but rather that only their salary expense is recorded in the corporate headquarters company (USSI).

The next graph illustrates the corporate structure used for the following illustrations and shows that the director’s salary expense shall (partly) be allocated to the projects setup in subsidiary FRSI and subsidiary GBSI.
ENx_131_0005
Note: What is important when it comes to the allocation of indirect costs across different legal entities is that regulators / tax authorities regularly require tax invoices and the adherence to international transfer pricing regulations to prevent companies from shifting their profits to low tax countries. This is an aspect that will also be taken into consideration subsequently.

 

Part B: System setup
For the following illustrations I will use an approach similar to the one introduced in an earlier post. That is, the cost of the corporate directors will first be invoiced and recorded on company-specific summary projects (F0 and G0) from where they will be allocated to the different projects in a second process-step. The next graph illustrates this procedure from a high-level perspective.
ENx_131_0010
In order to implement this scenario, a couple of setups are necessary that I will illustrate next before having a look at the different process steps involved.

Setup B.1: Intercompany dummy vendor account company USSI
The first thing that needs to be setup for the illustration of this scenario is a dummy vendor account in the corporate headquarters company USSI that will be used as an intercompany invoice “vehicle”. Three things require special attention when setting up this dummy vendor account.
First, the use of a Profit & Loss (P&L) summary account No. 602101 that is used as the offset account for the cost allocations recorded.
Second, the (optional) setup of a separate method of payment for this dummy account to avoid an unlimited increase of the dummy vendor account balance and third the (optional) linkage of the summary account to fixed financial dimension values that offset those financial dimensions that will be used when recording the directors salary expenses in Dynamics AX.
ENx_131_0015

Setup B.2: IC customer & vendor accounts
Once the dummy vendor account is setup in the headquarters company, intercompany customer and vendor accounts need to be setup in all companies participating in the intercompany scenario.
When setting up those intercompany customer and vendor accounts it is important that an intercompany financial dimension value is setup as default value, as exemplified in the next screen-print. Otherwise, the financial consolidation process of the corporate ledger accounts might get difficult later on.
ENx_131_0020

Setup B.3: Project category setup
The third setup is related to the project category that will be used for the intercompany invoicing and allocation of the director’s costs. There is nothing special to look out for when setting up this category except that it is setup in all companies.
ENx_131_0025
Please note that I linked the IC Director category to the transaction type “expense”.

Setup B.4: Procurement category setup company USSI
After the project category setup is finished, procurement categories need to be defined that will be used for creating the intercompany postings later on. When I setup those procurement categories, I noticed that Dynamics AX summarized my transactions irrespective of the financial dimension values used. For that reason, two – rather than a single – procurement categories will be used in the following.
ENx_131_0030
Please note that both procurement categories are linked to the same project category that has been setup previously. To record project transactions later on based on those categories, corresponding ledger accounts need to be setup in the inventory posting matrix. In the example illustrated above, the ledger accounts 602310 and 602320 represent intercompany P&L salary allocation accounts. Details for their usage can be investigated further below.

Setup B.5: Project setup companies FRSI & GBSI
No specific setup is required for the internal (allocation) and external customer projects in the subsidiaries except that one should ensure that they are all linked to a default intercompany financial dimension value at a minimum.
ENx_131_0035

Setup B.6: Project posting setup
The last setup required relates to the setup of the project ledger posting. In this respect you have to setup an intercompany revenue account in the corporate headquarters company that allocates the costs to the different subsidiaries. To get those allocated costs posted in the subsidiaries, the subsidiaries require the setup of intercompany cost accounts. The next screen-print exemplifies the ledger posting setup required in the different companies involved.
ENx_131_0040
(Please note that the corporate headquarters company USSI and the subsidiary GBSI share the same Chart of Accounts (COA). The FRSI subsidiary does, on the other hand, use its own local COA).
In addition, as the allocated intercompany costs will subsequently be distributed to the different external customer projects by making use of the project adjustment functionality, one has to ensure that the intercompany cost account setup is also made in the project costing section. That is because the latter posting type will be used for the distribution of the costs to the different projects.
ENx_131_0045
Note: The project ledger posting setup shown above is based on the use of time & material projects. If you use other project types, a slightly different ledger posting setup might be required.

 

Part C: Process steps

Step C.1.: Record the directors salary expense in USSI
With all those setups in place, the intercompany cost allocation process can start with the recording of the directors’ salary expense – for reasons of simplicity – in an ordinary General Ledger journal.
ENx_131_0050
Please note that I recorded the salary expense together with a business unit and department financial dimension value.
The voucher resulting from this transaction debits a P&L account and credits the Balance Sheet (BS) account that records the salaries payable.
ENx_131_0055

Step C.2.: Record internal invoice transaction on dummy vendor account in USSI
The next step involves a pure internal transaction that is required for the subsequent generation of the intercompany invoices. This internal process step involves recording an internal vendor invoice on the dummy vendor account setup and makes use of the previously setup procurement categories.
In the example used and illustrated in the next screen-print, a total of 200k USD is allocated to the other companies (125k USD to company FRSI and 75k USD to company GBSI) involved in the intercompany relationship.
ENx_131_0060
Please note that the internal invoice transaction is made in reference to the intercompany project category and summary project as shown in the next screen-print.
ENx_131_0065
Posting this internal invoice, results in the following voucher …
ENx_131_0070
… which is summarized in the next accounting overview.
ENx_131_0075c
(IC = Intercompany financial dimension, PRO = Project financial dimension)

What one can identify from the illustration above is that – due to the specific ledger accounting setup made – the internal invoice transaction does not influence the overall profitability of the corporate headquarters company USSI because the ledger accounts used for the debit and credit transaction are both P&L accounts.
From an overall accounting perspective, the only thing that has changed through this internal invoice transaction is that the total corporate directors’ salary expense is broken up into different parts.

  • Part 1: 100k USD – the sum of the ledger accounts 602100 and 602101 – which represents the directors salary expense to be covered by the corporate headquarters company USSI,
  • Part 2: 125k USD – recorded on ledger account 602310 – that will subsequently be invoiced to company FRSI and
  • Part 3: 75k USD – recorded on ledger account 602320 – that will subsequently be invoiced to company GBSI.

Step C.3: Create and post intercompany invoice
Once the internal invoice transaction is recorded, the intercompany project invoices can be generated. This is realized through the standard Dynamics AX intercompany project functionality illustrated in the next screen-print.
ENx_131_0080
A major advantage of using this standard functionality is that the intercompany invoice document is – as exemplified in the next screen-print – automatically created out of the box.
ENx_131_0085
The voucher resulting from this intercompany invoice transaction debits an intercompany receivable (BS) account and credits a P&L account that offsets the previously recorded expense allocation accounts.
ENx_131_0090
The next accounting overview illustrates the offsetting effect mentioned above in the yellow highlighted accounting sections.
ENx_131_0091b
Due to this offsetting effect the total directors’ salary expense remaining in the corporate headquarters company is reduced from 300k to 100k USD (sum of the ledger accounts 602100, 602310, 602320, 602101 and 603200).

Step C.4: FRSI & GBSI: Post pending vendor invoices
At the time the intercompany project invoice is recorded in the corporate headquarters company, pending Accounts Payable vendor invoices are automatically created in the subsidiary companies FRSI and GBSI. Please see the next screen-print.
ENx_131_0095
Posting those invoices results in the following vouchers:
ENx_131_0100
Please note that the voucher recorded in the subsidiary companies record the transaction in USD – the currency that was specified when posting the intercompany invoice – and the accounting currency of the subsidiary (EUR resp. GBP in my case). What currencies are used for the intercompany invoicing process is not only an accounting issue but also a transfer pricing and organizational issue, as it determines which legal entity has to bear the risk of foreign exchange rate changes.

As before, the next accounting overview, summarizes the intercompany invoice transactions recorded in all companies involved in the intercompany trading relationship.
ENx_131_0105b

Step C.5: FRSI & GBSI: Allocate transactions to the different subprojects
One of the last steps in the intercompany allocation process is the distribution of the allocated costs to the different projects in the subsidiaries. This can be achieved by making use of the project adjustment functionality that has been introduced in a prior post and which is illustrated in the next two screen-prints.
ENx_131_0110 ENx_131_0115
The resulting vouchers are once again summarized in the next accounting overview.
ENx_131_0120b
As one can identify, the adjustment / allocation posting in the different companies ensured that all costs are finally distributed down from the corporate headquarters level to the project level in the subsidiaries.

The remaining two process steps related to the intercompany allocation are not explicitly illustrated here, as they are not directly related to the intercompany cost allocation process.

  • The first remaining process step is the payment of the previously used internal dummy vendor account to ensure that the balance on this dummy vendor account does not grow unlimited. Please note that this process step is optional and not necessarily required but recommended in order to alleviate the reconciliation of the Accounts Payable with the General Ledger module.
  • The second remaining process step is the payment of the intercompany project invoices. Also this process is not explicitly illustrated here as it can be realized by making use of the standard Dynamics AX payment functionalities.

 

Summary
Within this post I illustrated how indirect costs recorded in corporate headquarters can be allocated across legal entities down to the different projects processed in the different subsidiaries. An important aspect of this process is that the required intercompany tax invoices and all required accounting transactions can be created out of the box with the standard Dynamics AX intercompany project functionalities.

The next and final post in this series on project related cost allocations will focus on a scenario where costs / revenues recorded at the project level of the different subsidiaries will be allocated back to the corporate headquarter level for cost analysis purposes.

Project related intercompany cost allocations (1)

Tags

, , ,

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.
ENx_130_0005
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.
ENx_130_0010
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.
ENx_130_0015

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.
ENx_130_0020
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.
ENx_130_0025

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.
ENx_130_0030
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.
ENx_130_0035

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.
ENx_130_0040
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.
ENx_130_0041

 

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.
ENx_130_0045
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).
ENx_130_0050

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:
ENx_130_0055
Once all transactions to be invoiced are selected and posted…
ENx_130_0060
… the following intercompany invoice voucher results.
ENx_130_0065
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.
ENx_130_0070
Posting this invoice results in the following voucher.
ENx_130_0075
(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:
ENx_130_0080
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.
    ENx_130_0085

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.
ENx_130_0090
What happens if the financial intercompany dimension is missing at the project level can be identified in the next illustration.
ENx_130_0095
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

Tags

, ,

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.
ENx_129_0005
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.
ENx_129_0010
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.
ENx_129_0015
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.
ENx_129_0020
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.
ENx_129_0030
ENx_129_0035
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:
ENx_129_0045
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.
ENx_129_0050
The next financial statement report presents the data in a slightly different reporting format.
ENx_129_0055
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.
ENx_129_0060
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.
ENx_129_0065
As in the previous section, the next illustration summarizes the vouchers generated in this 2-step allocation procedure:
ENx_129_0075
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.
ENx_129_0080

 

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.
ENx_129_0085
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.
ENx_129_0090
The last process step consists of allocating the statistical depreciation costs to the different external projects.
ENx_129_0095
All transactions involved in this last example are summarized in the next illustration…
ENx_129_0100
… and (internal) financial statement.
ENx_129_0105
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.

 

Summary
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.