dynamicsax-fico: Project cost allocations

[Blog bot]

Источник: https://dynamicsax-fico.com/2016/10/...t-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.



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.


Filed under: Project Tagged: cost allocations projects, indirect costs, overhead

Источник: https://dynamicsax-fico.com/2016/10/...t-allocations/