Chapter 11: Project Accounting and Operations
In this final chapter of our book, we are going to turn time into money! The preceding chapters have built everything up to the ability to perform billing and accounting for our work products. In this chapter, you will understand the implications of the billing methods we have chosen and you will see how they drive invoicing.
Furthermore, once billed, the conversation will turn to how we can make use of the data that has been generated. So, let's get this chapter started!
In this chapter, you will learn about the following topics:
- Recap of our learning
- Getting an overview of the billing process
- Invoicing
- Finance and Operations integration
- Costing and profit
- Learning about reporting and analysis
By the end of this chapter, you will know how the project operations system generates project accounting transactions.
Technical requirements
To perform the tasks in this chapter, you will need the following:
- An Microsoft 365 account and an Azure AD login
- A Microsoft Dynamics 365 Project Operations (C) license
- Potentially a Dynamics 365 Finance and Operations license
- A Microsoft Project Plan license
- The Project Billing Administrator security role
- A Finance and Operations accounting role and integration role suitable for running the integration
Please visit the following link to check the CiA videos:
Recap of our learning
We have journeyed together through 10 chapters and are now entering this final chapter together. In the past 10 chapters, we looked at the foundation of what a project-based business is and what the needs of that business model are. We then learned that project-based businesses are focused on delivering the project commitments that have been made to their clients.
When we looked at the Microsoft Project Operations solution, we outlined how we can build upon the Microsoft 365 and Dynamics 365 frameworks to provide users with an experience that is integrated with everything Microsoft. The benefit of this is that while leveraging the Microsoft framework, we can also gain some significant improvements for our people, processes, technology, and data.
When we looked at the Microsoft 365 framework closely, we outlined some of its key benefits by identifying how it gives you an overall platform for success, including Outlook, Teams, SharePoint, and OneDrive. With this framework, we can remove the context switching that happens when a user has to specifically log into an app, versus having their work integrated into their daily life.
In the next chapter, we walked through the deployment options for your project operations system, which ranged from Dynamics 365 CE-centric deployments to heavy Finance and Operations deployments. We outlined a number of key questions you should ask yourself and your firm before advancing too far into the deployment.
We also took the liberty to set up a few customizations that make sense for a project-based business. Using the Power Platform, PowerApps, and Power BI solutions, we built on top of the project operations foundation to make the solution work best for you and your firm's needs.
Then, we got into selling contracts and winning business. Project-based businesses are not transactional but relational. Therefore, the need to build out contract lines that reflect special client- or project-specific rates is key to meeting client demands. We also learned that we have many contract types that will directly feed into the project's billing and invoicing, as well as have a tremendous effect on revenue recognition.
During this time frame, we learned the importance of roles in terms of the pricing and costing models. We built out roles per Org Unit and also specified generic roles that drive our ability to staff and plan for resources.
For the practice manager, we outlined how they would manage backlog and how that backlog works to drive utilization throughout the business. When focusing on demand, we also needed to support the talent that makes the business a success. Due to this, we worked through skills and certification management routines and incorporated these into the staffing model.
For businesses that take a more centralized approach to their staffing and resourcing requirements, we walked through how to generate resource requirements and how they become resource requests, which fulfill the demand in the system. Skills, certifications, location, and other factors come together to provide sophisticated decision-making capabilities for scheduling.
When we continued down the road to project success, we worked squarely with the project manager to provide expert management for all the facets of the project. The project manager is presented with a sophisticated interface for developing plans, which includes task, board, and timeline views of the same data so as to support more traditional waterfall planning, as well as agile methodologies. The project manager is empowered to make course corrections to the project to keep it on track while incorporating change orders and other elements of correction.
The team member activities we covered included the most popular activity we all do every week: time entry! This also included expense entry, submitting our time and expenses, and learning how to handle exceptions and things that cause us to have to correct entries.
This led us to the point where we are able to handle and make entries that drive project cost, sales, time, and expense corrections that affect the project's financial health.
Now, we are ready to look at project accounting and operations. In this chapter, we are going to learn how to turn time into dollars and provide benefits for the business with the revenue we generate! So, let's get into it!
Getting an overview of the billing process
The billing processes in project operations will be different, depending on the type of deployment you have. Reflecting back, we have three different deployment types that we can use in project operations:
- Lite deployment – deal with proforma invoicing: This is a Dynamics CE-only deployment of project operations and is integrating with external ERP systems.
- Project operations for resource/non-stocked-based scenarios: This is the integrated version of Dynamics CE Project Operations to Finance and Operations.
- Project operations for stocked/production-based scenarios: This is the Finance and Operations-only deployment.
In this chapter, we are going to focus on the Lite deployment – dealing with proforma invoicing processes – because this particular deployment, with the out-of-the-box integration Microsoft provides into Finance and Operations for the billing functions, is the project operations for resource/non-stocked-based scenarios. Let's put this a different way:
Lite deployment + Microsoft Dual Write Integration + Finance and Operations = Project Operations for resource/non-stocked-based scenarios.
Therefore, by covering the project operations Lite deployment, we will cover the majority of the work before any project operations data is integrated into any accounting system, whether it's a Finance and Operations one or any other system.
The project operations for stocked/production-based scenarios is primarily conducted within the Finance & Operations – Project Management and Accounting functionality, so the majority of that conversation is beyond the scope of this book.
As you may recall, in Figure 3.1 – Project Operations Unified Environment, we covered each of the functional areas. To build upon this, the following diagram outlines the billing processes we will cover:
Figure 11.1 – Billing Processes in Dynamics 365 CE Project Operations integrated with accounting
The left-hand side of the diagram contains everything in Dynamics 365 CE – Project Operations in terms of producing the invoicing details in project operations and then integrating them into Finance and Operations. The right-hand side of the diagram contains the accounting system, which shows Finance and Operations as a primary scenario here.
With this information as a backdrop, let's view the impact of the billing methods, contract types, and invoicing options we have performed previously.
Billing methods, contract types, and invoicing
Within project operations, the Project Contract and its related Contract Lines drive the overall billing methods, which results in invoices. In project operations, there are two main types of billing methods: time and material and fixed price. Let's take a look at time and material contracts first as this is the most direct translation of time into money!
Time and material
With the time and material billing method, you are billing a specific selling rate for every increment of an hour that's been billed for each resource. Your costing is proportional to the hours that are charged by the team member performing that specific role.
A not-to-exceed contract is a time and material contract with a limit on the maximum that you can bill. Remember, in our contract, we have two project-based lines and one of them is time and material, not-to-exceed with a limit of $25,000 for out of scope work.
The components that drive your sales and cost amounts in a time and material contract are the organizational unit and the roles that are part of it. The roles and the associated cost price list drives the costing. The role and the associated sales price list (multi-dimensional as it is, this could be the rate card, either customer-specific or project-specific) that drives the selling price.
These come to a conjunction when time is entered against a project and task and because that has a project contract line associated with it, we get a sales price. Since the resource has a role assigned and that role has a cost price list for the organizational unit, there is a cost that associated with it.
The time that's entered into the system becomes an actual transaction when it's approved by the project manager and is then ready to bill.
Fixed price
Then, you have your fixed-price contracts, which have variations, including invoice schedules, milestones, retainers, and fees, as well as the ability to bill out an amount as needed throughout the contract.
Invoices in project operations are billed out on a defined schedule or as part of monthly or other billing cycles.
Time that's entered against a fixed-price contract is only going to cost the contract and not generate any sales transactions, since they are conducted at the milestone invoice level.
Invoicing
Invoicing is the mechanism that transforms our time into money. Invoices are physical representations of the price lists we set up previously and should accurately reflect the agreed upon rates.
The first thing we are going to do is bill out our first fixed-price milestone as per the project contract and line items. To do so, we must begin in the Project Operations | Sales area. We must then go to the Billing section and select Fixed Price Milestones.
This first milestone is to be billed up-front before the work begins, so let's get to it!
Milestone invoice
Let's get our milestone billing ready and generate an invoice. Our first invoice is due 03/07/2021, as shown in the following screenshot:
Figure 11.2 – Project Contract Milestones
To begin milestone billing, navigate to the project invoice in the sales area and perform the following steps:
- With the first milestone selected, click Ready to invoice.
- Next, in the Project Contract, we are going to select Create Invoice in the top-right of the contract This will create an invoice automatically for us, as shown here:
Figure 11.3 – Project Contract Invoice
- It is important to note that in many integrated environments, either the Ready to Invoice step or clicking Confirm is the key integration point (project invoice status) that triggers the integration into the accounting system's invoicing system. It is important to ensure that all the elements of our project-based lines are correct. Once we have ascertained this correctness, we can proceed. The result is that we have a contract line of $50,000 that is ready to invoice. We can see this in the preceding screenshot.
- From the vertical ellipsis to the right of Flow, we can now choose to create a proforma invoice by selecting Word Templates and choosing Invoice. This Word Template can be modified to reflect the type of invoice format you wish to use. Furthermore, it is common to have a different fixed-price format and a distinctly different time and material invoice format. The following screenshot shows the invoice templates (Word Templates) that have been uploaded to project operations:
Figure 11.4 – Project Proforma Invoice
Like all Word Templates, this project invoice is customizable and you can make it look as professional as you want using the Microsoft Word template in project operations.
Next, we need to bill out our subscription for project operations.
Product-based billing
As an overall solution, Dynamics 365 CE produces product-based and project-based billings. The product-based billings could be for physical products or they can be for subscription services, as we have in our example. It is important to note that we have a unified billing environment that is driving this functionality.
The product to bill out is visible in the Project Operations | Sales | Billing section and on the Product Billing Backlog screen. Here, select the product and then select Ready for Invoicing.
Since we are using a unified billing environment, we will begin our product billings from the project contract, just like all our other project billing functions. From the project contract, click on Create Invoice; the system will create a product-based invoice as well.
In the section highlighted in the following screenshot, we are billing out one line item of 20 units at $125 per unit for the extended amount of $2,500:
Figure 11.5 – Product Proforma Invoice
The same integration and invoice printing processes apply. Clicking Confirm sets the billing status to Confirmed. Next, we need to bill out some Out of Scope time that was entered and approved.
Time and material billing
To bill out the time that's been entered and approved, we will begin with the Project Operations | Sales | Billing section and on the Time and Material Billing Backlog screen. Here, select the lines/time we want to bill and then select Ready for Invoicing.
From the project contract, click on Create Invoice; the system will create a time and material-based invoice as well. Similar to the steps previous to this, we are now creating invoices for the highlighted Out of Scope item shown in the following screenshot:
Figure 11.6 – Project Out of Scope Time and Material Proforma Invoice
The same integration and invoice printing processes that were covered in the previous sections apply. Clicking Confirm sets the billing status to Confirmed.
Combined billing
Combined billing is really how a biller or administrator will function within project operations. Combined billing simply means that when all the backlog transactions are set to Ready to Invoice, we are putting all the transactions together into one invoice. This is a billing process that would require a specially formatted invoice to show the details behind each of the billing scenarios. This process also works at the contract level to provide a more convenient grouping.
For this chapter, we have printed out (and/or integrated) each of these three scenarios individually.
In reality, the process you will follow will include confirming billing backlogs for everything (milestones, products and time, and materials) at one time and then putting them all onto one draft invoice for preview, presentation, and confirmation.
Let's take a look at what happens when you integrate into Finance and Operations.
Finance and Operations integration
Historically, Finance and Operations has been its own Project Accounting solution with time and expense entry, invoicing, revenue recognition, and significantly more.
Microsoft has combined the best of project operations in the Dynamics 365 CE world with the Project Accounting capabilities in Finance and Operations. They have done this by creating an integrated environment where the project operations CE components are augmented with an integration technology solution called Dual Write Core and Dual Write Orchestration.
Once enabled on the CE side and the Finance and Operations side of the system, the user experience is to process transactions in CE where they originate while integrating them into Finance and Operations, which is where accounting takes place.
To look into this further, let's look at how we can create and integrate an accounting transaction.
The project operations system produces actuals, as shown here:
Figure 11.7 – Project actuals
These actuals represent the operational view of the work that's been completed against projects in project operations. When integrating with Finance and Operations, we are integrating with the Project Management and Accounting system. This means that we are populating journals in Finance and Operations, which are populating the project ledger and then subsequently the general ledger.
Therefore, to get into the general ledger, Microsoft has employed the concept of an integration journal to manage these accounting transactions.
Integration journal
Integration is performed via Project Management and Accounting (PMA) | Journals | Project Operations Integration journal. Bringing these records into the system involves running the periodic process >> Import from staging table. The integration can bring in actuals based on a comparison to find actuals that have not been integrated since the last execution, and then integrates them into one of the following user-specified groups:
- Days: Actuals are grouped and journaled by days.
- Months: Actuals are grouped and journaled by months.
- Years: Actuals are grouped and journaled by years.
- All: All actuals are grouped and journaled, regardless of any date-driven factors.
The results of this are that each project actual transaction has a corresponding line in the Project Operations Integration Journal. This means that there will be a similar breakout to the actuals shown in the preceding screenshot.
The system is accounting date-driven and will post to the accounting date that's brought across in the integration. If the period is closed and locked out, then the result will be a posting to the first date in the next open ledger period.
Resource specifications in the integration are meaningful to the Project Operations – CE side of things, but are only informational for Finance and Operations Project Management and Accounting. This is to provide the detailed information needed for customer invoicing.
Financial dimensions
Financial dimensions are notably a Finance and Operations feature that is worth explaining in the context of Project Management and Accounting. You can set a default financial dimension for customers to create a customer dimensional view.
Dimensions can also be set for project contracts through the PMA module in Finance. For fixed-price/milestone contract lines, financial dimensions can be set up to help report on contract types and performance.
Project funding sources can be set in PMA Project Contracts via the Related Information | Funding Sources tab. This can be helpful for grant management.
For the project itself, the dimensions are pulled through from the customer, contract line, or project, depending on which dimension is more complete. For example, if the customer has a financial dimension but is not on the contract line or project, the customer dimension will be used. If the contract line has a dimension, then this dimension will be used. If the project has a dimension, it will be used to dimension the transactions.
Revenue recognition
The processing of revenue recognition in project operations is primarily conducted through the Finance and Operations – Project Management and Accounting functionality. The setup and complexity of revenue recognition in PMA is beyond the scope or context of this book. However, it is important to factor in that there will be a revenue recognition process regardless.
Whether you're using Finance and Operations PMA revenue recognition or some other accounting system, Generally Accepted Accounting Principles (GAAP) will require some formulaic calculation of revenue recognition. So, let's talk about what plays into this for a project accountant.
The project itself, along with its tasks, budgeted hours, and dollars, is a large factor in the revenue recognition process. Combined with the contract type and the percentage of the project that's complete, we can calculate the revenue to be recognized. This is typical for a fixed-price contract.
In our project's example, we have a total project contract value of $125,000 being billed out three times. We are currently at 15.61% Cost Consumption for the project, which represents about $19,512.50 in revenue. We can recognize this based on a cost model. The result of this calculation is that deferred revenue will be reversed by $19,512.50 and that the revenue will be recognized or credited for $19,512.50 for this period.
In Finance and Operations PMA revenue recognition, this is a similar approach to the Total cost-actual cost to complete method. There are many others that are beyond the scope of the context of this book.
Note
With all accounting statements made in this book, the statements are for example purposes only and may not represent your needs or intended results. Please seek professional accounting assistance where necessary.
Taxes and proforma invoices
For all the invoicing we performed in the Invoicing section, the invoices that were produced are good for presenting to the client but are potentially missing some critical data.
Taxes are one element of data that may be missing from the invoice. Typically, tax calculations are provided in Finance and Operations through an Avatax web service integration or some other tax integration. The same can be done on the proforma invoice, but it would be highly duplicative.
Furthermore, a proforma invoice is an invoice that the accounting department will generally need to duplicate in their accounting system. This is due to the nature of the invoice needing to be paid by the client and that payment being tracked and recorded. Again, this would be duplicative if we did this in project operations and in Finance and Operations or any other accounting system.
Costing and profit
The project operations system will track costing and profit within the system, as well as make this available through other tools such as Power BI. Within project operations, some key areas where we see actual cost impacts appear as the project's progress is on the front page of the project itself.
In the following screenshot, we can see that we have already charged a number of costs for the project through our time entries and approvals and that these expenses have been entered and approved. To see this, open the Project screen from the Project Operations menu:
Figure 11.8 – Estimates versus Actuals
Here, we can see that we have an estimated labor cost of $47,237 and an actual labor cost of $8,138.75. The estimated expenses of $1,875 versus $375 have been entered and approved.
The goal of the project operations system is to provide accurate accounting for the actuals transactions on the same screen so that we can compare them with the estimates.
Now, let's get into some of the reporting and analysis the system provides.
Learning about reporting and analysis
The purpose of reporting and analysis is to provide performance metrics to the users of the system who are responsible for project performance. To provide this, we have a few options that will provide value to the system.
With project Operations, dashboards are provided out of the box. As you may recall, Dashboards are available from Home | My Work | Dashboards. This section will provide you with dashboarding information that can be leveraged by your users.
Project Operations Dashboards
Project operations Dashboards are specifically designed visual graphics that are built upon views of the data in project operations. Specifically designed for the personas in use in a project business, these dashboards can have security assigned to them, expanded to include more data, and are generally made into what the users want and need to manage for the project business.
When viewing dashboards, you get to choose your dashboard and set it as a default:
Figure 11.9 – Dashboard selector
As shown in the preceding screenshot, many dashboards are visible to the users of a Dynamics 365 CE system that go beyond project dashboards. For example, there are dashboards for sales, service, activities, and much more.
The most common dashboard for the leadership team is called Practice Management Dashboard. This dashboard provides the following critical dashparts:
- Current month versus prior month – Cost
- Current month versus prior month – Gross margin
- Current month versus prior month – Sales
- Current month versus prior month – Total hours
- Active Role Utilization
- Current Month Cost
The goal of these particular dashparts is to give you a starting point for what real information the practice manager may need.
Similarly, the Resource Manager Dashboard provides unique views around active resource requests, active role utilization, and resource demand distribution.
These dashboards can be modified in terms of both visual appearance and information. They are security enabled, which means you can only present the relevant information to your audiences while leveraging the security within Dynamics 365.
The power of the Microsoft Power Platform includes the ability to utilize Power BI Reporting to build even more sophisticated dashboards. To build on these further, these Power BI dashboards can be directly integrated into a project operations dashboard to enhance the system.
Power BI Reporting
Throughout this book, we have seen a few examples of how Power BI is used in forecasting or in other facets of the project operations world. While there are numerous examples we can build from, my experience has been to fully identify and vet the requirements of each individual client before prescribing the right reporting solution.
For example, a quick web search turns up a number of very beautifully formatted, graphics-intensive reports that, when looked at in their own context, represent some really great work! Furthermore, some are of a quality that you would want to mimic in terms of their structure, data elegance, and presentation layering.
However, things change when we look at the reality of each client's user base, report consumption habits, and the decisions that are based on each of these. Therefore, you must consider how best to structure the overall project operations data and your most valuable information first; then, the rest of your reporting will fall in line.
For example, in the Finance and Operations integration section, we discussed the use of dimensions in a Project Operations world connected to a Finance and Operations world. Dimensions allow for some sophisticated reporting functionality for the users of project operations.
When using Power BI, you can pull from both Project Operations Dataverse information as well as Finance and Operations information. This information combines into one view to provide a sophisticated join of information, from the front end of the solution to the accounting end.
Since we're talking about Microsoft Technology, it is important to know that some clients will have a hybrid solution approach, which provides Microsoft Technology with a data warehouse and potentially Power BI on the frontend to generate and render the reporting needed for the user base. With this approach, there is unlimited potential for results.
Summary
In this chapter, we concluded our project operations conversation by reviewing some of the key elements of the project operations system, including contract types, finance and operations, and reporting and analysis. This hopefully has helped pull together the key concepts and learnings throughout the book.
In terms of contract types, we reviewed time and materials contracts and compared them to fixed-price contracts. We learned how the project that we built out with its various contract lines all came together in the invoicing processes. We then billed out our milestone invoice and printed a proforma copy. After that, we billed out our product and time and materials billings. In all of these, we learned about the integration points of our invoices and the other actuals transactions in the system.
Next, we reviewed some of the key elements in the Finance and Operations integration, including the Integration Journal, Financial Dimensions, and Revenue Recognition. When working in an integrated environment, these are important concepts as they will drive some enhanced functionality further down the line in the implementation.
Finally, we covered Power BI's capabilities and why you will want to use Power BI as a tool to pull together data across systems, and then combine it into a unified reporting structure for your users.
It is at this point that I thank you, the reader, for following along this journey with me. As we close out this chapter, remember that the journey begins by taking some first steps in the right direction. Not every facet of the material that's been covered in this book will apply to your implementation, but every implementation will contain some facets that were covered in this book. It is with this that I look forward to our next book journey and hope that our paths cross again soon!
Questions
- Which deployment models were used to exemplify project accounting in this chapter?
- In a time and materials project, each hour of time is transformed into what?
- In a fixed-price contract, does the sales price per hour get calculated?
- In a fixed-price contract, does the cost per hour get applied to the contract?
- When invoicing a milestone, what initiates the fact that the milestone is to be placed on an invoice?
- What is a common integration point for an invoice to be integrated into accounting?
- True or false: Project Operations has robust tax engine capabilities and will therefore render a complete invoice in the CE system.
- Can a single project invoice include time and material, product, milestone, and retainer billings?
- The Finance and Operations Integration Journal is date-sensitive to what degree?
- What is the benefit of financial dimensions?