Project Accounting - Miscellaneous Logs

Miscellaneous Logs is one of the defined transaction types in Dynamics GP -Project Accounting. When I discuss or demonstrate Misc. Logs with prospects and clients, they usually look at me in a way that indicates there is no way they would ever use that functionality. However we have clients who have used this transaction type extensively and effectively.

An example is a client that performs engineering inspections for large residential home builders. They perform inspections for roofs, foundations, windows, etc, for every home in new large housing developments. They charge their clients for each type of inspection on each new home, so there is a lot of data.

Before GP, they were collecting data in Timeslips, and manually entering into QuickBooks.

This is how they used Project Accounting:

• New projects were set up in Project Accounting so that each inspection type, on each new house was represented by a unique Cost Category. This process was automated using eConnect.
• Each Cost Category had a Miscellaneous Log budget that represented the inspection type, the quantity of inspections (usually 1), and the price, e.g. $115. The advantage of this was that they had significant detail to indicate to their clients exactly what the clients were being billed for.
• On a daily basis newly performed inspections were being imported from a field time gathering system using eConnect, and individual Miscellaneous Log transactions were being created for the specific Cost Categories.
• On a periodic basis the client would run the Cycle Billing routine to create invoices for all the inspections that had been performed.

Because the Cost Category budgets were set up for each inspection type and house, the home builders were not being billed twice for the same work, and our client now knew exactly what was not being billed. As it turned out; after using GP for several months, our client realized that they had previously been under-billing their clients by a lot. And because the whole process was automated, the effort involved in billing, decreased.

This is an example of how one client used Miscellaneous Logs to solve their business issues, and we have others who have used the Project Accounting transaction types in amazing ways.

In the case cited, eConnect was crucial to automate the project set up and transaction creation process. Otherwise the sheer volume of work would have killed the project. Because of the automation, the GP users at this client hardly interact with Project Accounting at all, for transactions and setup.

Project Accounting - Deferred Revenue

The Project Accouting module in Dynamics GP can be used to accurately manage deferred revenue. Many of our clients use this function when their business involves a mix of project related activity and subscription based or contract based revenue.


To use Project Accounting for manageing deferred revenue there are a couple of rules:

• Use a "Service" Fee Type


• Use a "Time and Materials" Project Type

Project Accounting will allocate the fee amount evenly over the duration represented by the start date and end date of the project, or as identified in the Fee Entry screen.


This is an example of a Fee for which the revenue will be deferred over 12 months:




These three accounts will handle all accounting for the invoicing and revenue recognition of the fee:

Here's an example of the fee in a project:

To invoice the fee, you just use the standard invoicing process in Project Accounting. To recognize revenue you use the standard revenue recognition process. You can use Cycle Revenue Recognition or create the transaction manually by navigating to: Transactions >> Project >> Billing >> Revenue Recognition.

But what happens with a service fee that spans a period of time, is that revenue will be recognized for the fee amount, from the start date, up to the Cutoff date specified. This will then effectively defer the revenue associated with the fee, from the last time the revenue recognition process was run for the fee, and the current Cutoff date.

Here's an example of the Revenue Recognition Entry screen:

This is the detail of the results of the revenue recognition calculation:

In my example, the revenue was recognized from 4/12/2017, to 5/31/2017: (50-1) days / (365-1) days = 13.46% x $10,000 = $1,346.00.

Why one day is taken off the numerator and denominator is something known only to the developer.

Here are the examples from KB# 885070:

A service fee can be set up for any time period that you specify. The percent complete is based on the total number of days for the service fee. The Begin Date field and the End Date field are used to calculate the number of days for the service fee.

Then, the percent complete is multiplied by the fee amount to obtain the revenue recognition amount. Billing has no affect on the amount that is recognized. The following examples show how the revenue recognition amount is calculated:

Service fee example 1

Fee Amount: $10,000

Begin Date: 1/1/2007

End Date: 4/30/2007

Total Number of Days = 121 days (31 + 29 + 31 + 30)

If revenue recognition is run with a cutoff date of 2/15/2007, the percent complete is calculated as follows:

Percent Complete = ((31 + 15) - 1) / (121 - 1) = 0.375 = 37.50%

Amount Recognized = 37.50% * $10,000 = $3750

Service fee example 2

Fee Amount: $1000

Begin Date: 1/1/2006

End Date: 2/29/2007

Total Number of Days = 425 days (365 + 31 + 29)

If revenue recognition is run with a cutoff date of 2/15/2007, the percent complete is calculated as follows:

Percent Complete = ((365 + 31 + 15) - 1) / (425 - 1) = 0.9669811 = 96.70%

Amount Recognized = 96.70% * $1000 = $967


If you have a deferred revenue tracking issue related to project-type business activities, consider using Project Accounting to manage the whole process.