New book on Microsoft Dynamics 365 FinOps – “Microsoft Dynamics 365 FinOps – Fixed Price Projects Revenue Recognition In-depth”

I have released a new paperback book called “Microsoft Dynamics 365 FinOps – Fixed Price Projects Revenue Recognition In-depth” on Amazon about the fixed price projects revenue recognition last Thursday .i.e. 27th September 2018. In this blog post i am going to talk about the book and the motivation behind that.

I knew basic fixed price projects revenue recognition and how to perform it in the system. However, when it came to knowing all the possible fixed price projects revenue recognition scenarios, i always had to dig the internet and find out how this scenario works and how that scenario works. And while doing that i realized that apart from the basic information about the fixed price revenue recognition, there was not much available on the internet. This triggered me write this book. I thought lets put all the logical and allowed scenarios on paper in details, along with the screenshots, explanation, supporting T-accounts, other relevant details, exceptions, shortcomings, specific behavior  and have it all in one place, in one book. The aim was to stop looking the internet endlessly for this topic henceforth.

What i did initially was plotted all the permutations and combinations with all the elements of the project group like 4 values of ‘Revenue recognition accounting rule’, 3 values of ‘Calculation methods’ and 4 values of ‘Matching principle’ and put them on excel sheet. The number came somewhere around 36. Also added further scenarios when i brought the ‘Cost template’ and its values for ‘Completion based on’ in scope. This added few more permutations and combinations with ‘Straight line’ and ‘WBS’ type of revenue recognition further adding to the scope. However, after trying each one of them by setting them up individually in the system, i concluded that 11 unique scenarios are the ones which i should be writing about in this book.

I decided to name it as “Microsoft Dynamics 365 FinOps – Fixed Price Projects Revenue Recognition In-depth” as this book gives the in-depth explanation for all the 11 scenarios along with all the accounting and relevant supporting details in over 200 pages. The second important decision was to print this book in COLOR, as the screenshots had many markings in RED, which i wanted the readers to really look at and understand it at once. The aim was always to uncover this complex beast of revenue recognition engine for fixed price projects.

Being a functional consultant, i have always faced many situations when client used to ask questions about a specific revenue recognition scenario and whether that is possible in the system and can i explain it. My regular answer was, “Let me get back to you on this”, as i knew that this is a complex area and this needs thorough preparation before presenting it to the client. Now with this book in place, i am personally in a much better position than what i was earlier. Not that i would answer all the questions about this topic instantly but at-least the turnaround time on them and the confidence would be much higher. I seriously feel that consultants working in the area of ‘Project management and accounting module’ of Microsoft Dynamics 365 FinOps, should definitely have a read through of this book.

Amazon link for the book is as follows: http://amzn.eu/d/7cEcot9

If you happen to read the book and if you wish to provide any feedback, then don’t hesitate to email it to me on kusaresarang@gmail.com. And if you like the book, then please write a review on Amazon, so that it would benefit other buyers too.

Thanks again!!

Kind Regards

Sarang Kusare

Calculation Method and Balancing Fee Journal

There are three calculation methods when it comes to fixed price projects, they are:

1. None
2. Markup percent total
3. Markup percent estimate line

This post is not about describing what each of the calculation method does but this post is the super summary of when does the system create the balancing fee journal and when it does not. This post is for the advanced users of revenue recognition functionality. It is assumed that the readers of this post are aware of all the three methods and how they behave. This is a small post to just present the gist in a table format with respect to the creation of balancing fee journal for all three calculation methods.

Calculation method and Balancing fee journal

System behavior is different when the: 

• dimensions are NOT present on the project and hours transactions and  
• dimensions on the project and hours transactions are different

No dimensions on the project and hours transactions

Contract value - 100,000

On account transaction

Hours forecast - 146

Hours forecast

No dimensions on the project

No dimensions on project

Contract value distributed during the estimate

Contract value distribution among cost lines

Cost posted for all the three cost lines are 1,800, 1,200 and 3,600, which is equal to 6,600. Based on the contract value distribution, the revenue recognized should be 30,000. [((1,800 / 3,600) *20,000) + ((1,200 / 3,600) *30,000)) + ((3,600 / 18,000) *50,000))]

System suggested percent complete

System suggested percent complete

Actual hours v/s Hours forecast

But system suggested percent complete is 27.40 [((Total posted hours / Total hours forecast in Qty)*100), which is (40/146)*100 = 27.40] hence the accrued revenue value would be 27,400. Hence the balancing fee journal should be approximately 2,600. Completion is based on 'Quantity' in the cost template.

When the estimate is posted, following is the voucher posted:

One voucher for accrued revenue

And the posted transactions are as below, which shows the actual 30,000 accrued revenue and the balancing fee transaction of approximately 2,600. However strange enough there is no voucher for that balancing transaction.

Balancing fee transaction 

Dimensions on the project and hours transaction are different

I repeated the above example with the same values, but this time with the dimensions on the project and hours transaction. However the 'Department' dimension  on the project is 22, and on all the three hours transactions are 23, 24 and 25 respectively.

With all the steps same as above, when the estimate was created, the system showed a percent complete of 27.40. I manually changed to 25 to see the impact on the posting.

Percent complete changed from automatic to manual

The voucher that was posted was expected to have a balancing fee transaction of 5000, with the dimensions from the project.

Balancing fee transaction

Posted transaction was as below:

Posted transactions

However in this case the voucher was posted for the balancing fee transaction.

Hopefully this post has helped you get more insight into the revenue recognition and generation of balancing fee transaction.

Kind Regards

Sarang Kusare