Projects – indirect costs

20 Saturday Feb 2016

Tags

financial statements, indirect costs, Project management

In the previous post I showed you what effect the use of the effective labor rate might have on a company’s financial statements and its financial ratios, such as e.g. the gross profit margin. Within this post I want to take a look at a related project management feature that can have similar financial implications, namely the indirect cost functionality.

As the setup of the indirect project cost functionality is already described on several blog-/websites, such as e.g. the following one (Blog-Link), I do not want to duplicate what has already been written there but rather focus more on the accounting side of this functionality. This will be realized by recording several demo transactions based on the following simplified indirect cost rates setup.

This setup is valid for all my projects and specifies that each hour transaction shall get an additional 5 EUR indirect cost on top of the ordinary costs that is setup per hour (50 EUR in my example). In addition, an indirect cost rate of 6 EUR / hour will be recorded when accruing revenues and customers will be charged an additional 7 EUR on top of the ordinary sales price for the hours recorded.

In order to show you the different indirect cost rates and the related ledger postings, a T&M project with revenue accruals is used for the following illustrations.

Against the background of this setup, I initially recorded 20 hours of project work for an employee and got the following result:

What you can identify from this screen-print is that an additional 100 EUR ( 20 hours * 5 EUR/hour) of indirect costs have been recorded together with the ordinary hourly costs of the employee (20 hours * 50 EUR/hour).
In addition, based on the set up indirect revenue rate of 6 EUR/hour, a separate indirect revenue accrual of 120 EUR (20 hours * 6 EUR/hour) has been posted.
The third and last thing that can be identified is the added indirect cost amount (140 EUR, highlighted in red color) that will be charged to our customer once the project invoice is recorded.

After recording the hour transactions, I created the project invoice for the customer and got the following ledger transactions:

The first four lines of these screen-print represent the reversal of the revenue accrual generated previously and the lines highlighted in red color represent the amount invoiced to the customer. As mentioned before, the customer is charged an additional 140 EUR (20 hours * 7 EUR/hour) due to the indirect invoice rate of 7 EUR.

The next screen-print summarizes all transactions recorded and includes a separate line for the salary payment of the employee that is required to show you the effects of using respectively not using the indirect costs rates for projects in a company’s profit and loss statement.

Based on the sample data recorded, the company’s profit and loss statement shows a total of 2140 EUR revenues (2000 EUR + 140 EUR indirect cost charge) and a total of 1100 cost of sales (1000 EUR + 100 EUR indirect cost charge), resulting in a gross profit of 1040 EUR or approximately 48,6% of the company’s revenues. Those data are illustrated in the first column of the next screen-print.

The second column (“P&L statement with indirect costs (cost rate only)”) shows you the effect that can be achieved if you only setup an indirect cost rate but no indirect revenue or invoice rate for example because your customer is not willing to pay for those indirect cost charges.

What becomes quite obvious from this column is the lower gross profit margin (45%) compared to the one in the first column.

The last column (“P&L statement without indirect cost”) shows you the P&L statement for the company if no indirect cost elements are setup. Also here you can easily identify the comparatively higher gross profit margin of 50%.

Based on the P&L statement comparison it can thus be summarized that the use of the indirect project cost feature can have an influence on your P&L statement and your KPIs (Key Performance Indicators) and provides you with some “window dressing” latitude.

A second aspect that I would like to consider in this post is what kind of costs are actually allowed to be allocate to projects via the indirect cost feature.
To find out, I had a look at IAS 11 which determines that only costs that are directly related or attributable to a project are allowed to be shifted to a project. On the other hand, general administration costs, selling costs, R&D costs and alike are not allowed to be shifted (allocated) to projects. As most governments have similar accounting regulations in place, it can be summarized that costs for office rent, office supplies, phone charges and alike are not allowed to be shifted to projects via the indirect cost functionality unless those costs specifically arise for a project.

This requirement causes a problem for the general usability of the indirect cost functionality in Dynamics AX as most indirect costs that IAS 11 allows to be shifted to projects are not directly related to hour transactions but rather to other cost elements such as expense and item transactions. Yet, the indirect cost feature does not apply to project transactions other than hours.

If you do not care much about these causal cost relationships, you can certainly establish a relation between your indirect costs – such as depreciation of PPE used on projects – and hours recorded on a project to come up with an indirect costs rate. Yet, I considerably doubt whether your auditors will accept indirect cost rates calculated this way.

To sum up, the indirect project cost functionality has the potential influencing your P&L statements and your KPIs. Unfortunately, significant doubts exist on the general usability of this feature in practice as indirect costs can only be setup and linked to project hour transactions.

Effective labor rate

12 Friday Feb 2016

Posted by Ludwig Reinhard in Project

≈ Leave a comment

Tags

cost price, Project management

Some time ago I came across the following blog post that illustrates the effect of using the effective labor rate for project hour transactions.

While the post nicely describes the effect of activating the parameter I was still not sure whether – from a finance & controlling perspective – the use of the effective labor rate makes sense or not.

To analyze this in more detail, I setup two test workers; one with the effective labor rate activated and one without the effective labor rate activated.

Similar to the example illustrated in the aforementioned blog post of Sandeep, I used a cost price of 100 for each of the workers and setup a “norm” working time of 40 hours / week.

In order to identify the difference in the project costs of my workers, I recorded the following hour transactions on a time and material project (“T&M”), an internal project (“Internal”) and a time project (“Time”):

After all hours have been posted, I was able to identify the following cost Transaction amounts for my workers.

Worker with effective labor rate activated
Worker without the effective labor rate activated

The next screen-print summarizes the results of my hour postings:

What you can identify from the previous screen-print is that the worker with the effective labor rate activated always causes project costs of 4000 irrespective of the actual time worked on the different projects.
On the other hand, the total project costs of the worker without the effective labor rate activated fluctuate and depend on the actual hours worked on the different projects.

Based on this outcome one can summarize that the usage of the effective labor rate functionality probably works best in companies where employees record all their working time on projects and where projects establish the fundamental core element of the company’s finance & controlling system.
Companies that scarcely use projects or only use them to track and analyze special costs are probably better off not using the effective labor rate functionality as too much costs might be allocated to projects.

A second aspect of using or not using the effective labor rate functionality is related to a company’s profit and loss statement (P&L).
Provided that a company’s salary / wage expenses and the project payroll allocation account are included in the administrative expense section of the P&L but the project related costs in the cost of sales section of the P&L, activating the effective labor rate feature can have an influence on a company’s KPIs (key performance indicators) such as the gross profit rate. The next screen-print summarizes this effect for the transactions recorded above.

(Note: In the illustration shown above I assume that all hour transactions are recorded on ledger accounts. This is not the case for time projects but does not change anything on the general outcome and interpretation).

In other words, the effective labor rate functionality provides finance managers with a “window dressing” instrument that allows them influencing KPIs. For that reason, using the effective labor rate feature needs to be analyzed and discussed thoroughly with the operative management team as KPIs are often linked to bonus and other payment elements of managers.

How to avoid small (penny) differences on customer accounts?

02 Tuesday Feb 2016

Posted by Ludwig Reinhard in Accounts Receivable

≈ Leave a comment

Tags

customer, Dynamics AX, payments, settlement

This post deals with the question how small (penny) differences on customer accounts can be avoided that arise when customers pay short.

Please note that the following descriptions and illustrations do only apply in Dynamics AX environments that do not make use of the automatic Accounts Receivable settlement functionality. That is, in systems that do not have the Accounts Receivable parameter “automatic settlement” activated.

Let’s have a look at the issue of small (penny) differences on customer accounts and how they can arise. The next screenshot shows you a customer transaction that was generated when a free-text invoice for a total amount of 5000 $ was posted.

Once the invoice becomes due, the customer pays 4995 $; that is, the customer pays 5$ short. The customer payment is recorded in a customer payment journal by entering the payment amount of 4995$ and marking the invoice that is paid. Please see the next two screenshots for details.

Note that you can reduce the settlement amount highlighted in the previous screenshot from 5000 $ to 4995 $. If you don’t, you will get the following message once you close the settlement form:

After posting the customer payment, the customer transaction form shows the following result:

What you can identify from the previous screenshot is that a small value balance of 5$ remains open. If you do not want to chase your customers for those small (“penny”) differences, the question arises what you can do with those small open customer balances and how they can be avoided altogether?

Cleansing small value customer balances
In order to “clean” small value customer balances you can setup a customer pool and write off the small balance amounts. The next screenshots illustrate you how this can be achieved in a standard Dynamics AX environment.

Step 1: Setup a customer pool that filters for small balance amounts

Step 2: Run the periodic Accounts Receivable “customer aging snapshot“ job

Step 3: Open the collections list page, select the small balance customer pool setup, select all records and click “write off”.

Avoiding small value customer balances altogether
To avoid small value customer balances altogether you can make use of the full settlement functionality that is available for Dynamics AX companies operating in Germany, Austria and Switzerland. To make this feature available in your country environment, simply open the CustOpenTrans form and either delete all country codes in the CountryRegionCodes field or add your country code there.

The next example illustrates the outcome of this system modification.

Example: For the same customer account used previously, a second free-text invoice for a total amount of 6000 $ is recorded. This time, the customer pays 10$ short. As previously, the customer payment is recorded in a customer payment journal as follows:

Once the settlement window is opened you can identify a new check box “full settlement”, which I selected. The result of this selection is that Dynamics AX considers the 10$ underpayment as cash discount and posts the underpayment correspondingly by referring to the automatic posting accounts setup in General Ledger.

If you double check the customer transactions form you can identify the 10$ cash discount posted. What you can also identify from this form is that no balance remains on the customer account from this transaction.

Final remark: Please note that the full settlement functionality can also be made available for vendor transactions simply by modifying the VendOpenTrans form as illustrated above for the CustOpenTrans form.

Dynamics AX Finance & Controlling

Monthly Archives: February 2016

Projects – indirect costs

Effective labor rate

How to avoid small (penny) differences on customer accounts?