Project related intercompany cost allocations (1)

23 Sunday Oct 2016

Tags

cost allocations projects, indirect costs, intercompany, overhead

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

02 Sunday Oct 2016

Posted by Ludwig Reinhard in Project

≈ 2 Comments

Tags

cost allocations projects, indirect costs, overhead

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.

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.