Project Accounting Different Levels, Different Needs
Learn the advantages and disadvantages of different project accounting softwares and which one could work for your company.
Learn the advantages and disadvantages of different project accounting softwares and which one could work for your company.
Table of Content
Project accounting is an overly broad term. The most general definition would be tracking financial transactions by project including costs, billings, and revenue. In reality though, project accounting can be much more than that. What constitutes project accounting in a company is based on several factors including company type, the number of projects and company size.
For project centric companies such as Consulting Firms, Architect and Engineering Firms or Software Publishers, project accounting is one component of several operational processes used in controlling projects, maximizing project profitability, accurately billing customers and ensuring customer satisfaction.
The functionality necessary to complete these project management processes is not effective by using the GL only. Companies trying this approach (and many do) usually end up becoming frustrated by the number of spreadsheets required to capture the information necessary to generate accurate reporting, complete project analysis and generate project billings. They find out quickly that using spreadsheets which aren’t integrated with the GL, causes project information to be stored in multiple data silos, increasing the likelihood of invoice and reporting errors and mandating generating project reports outside of the GL report writer. Additionally, the time needed to reconcile the spreadsheets to both the GL and the project reporting negatively generated effects productivity which in turn pressures company profitability.
For project centric companies, a comprehensive complete project management solution is needed. If your company uses Dynamics 365 BC, you may want to take a look at Progressus Software.
Non-project centric companies may use project accounting practices to track internal projects such as a marketing campaign, or some type of capital improvement.
Some companies decide to use a single GL account to capture project related transactions, then maintain spreadsheets to organize and report project detail.
Others may choose to track project transactions directly in the general ledger (GL) and not use spreadsheets. For example, a company using Dynamics 365 BC may set up separate GL accounts and/or use dimensions to achieve their tracking goals.
If the company tracks a few projects a year, either of these methods is probably sufficient. In this post, we’ll be discussing the advantages and disadvantages of project accounting for non-project centric companies using both methods.
When using project accounting to track a small number of basic, non-invoiced projects using a GL account(s), then using spreadsheets to organize the data captured can be a viable choice.
Using this method can be a very cost-effective solution. Most likely, an accounting system is already in place and operational. Today’s accounting systems range from a basic solution such as Quickbooks to more robust ERP products such as Dynamics 365.
Using the existing accounting system reduces the project accounting learning curve as the users are already familiar with the application, and tasks can be completed using basic functionality. Additionally, using familiar tools to build the spreadsheets (e.g., Excel) makes spreadsheet data capture and organization a simple task.
Accounts Payable and the General Ledger are used together to complete these project accounting tasks. For example, accounting sets up a project accounting GL account. The account may represent a single project (e.g., accounting office renovation) or a project grouping (e.g., marketing event). Depending on the project, the GL account may be mapped to the Balance Sheet or Income Statement.
As the applicable project transactions are processed, accounting and accounts payable code the transactions to the applicable GL account. In the case of accounts payable vouchering, transactions can be identified in the transaction’s description or by the vendor selected. If GL journal entries are posted to the project account, the transaction description is used.
In some accounting applications, the user can set up a field in the GL journal entry, or AP entry screen which can be used to provide additional granularity. These fields are usually known as something like “user defined or optional fields”. If your accounting application supports this feature, use it, as it can be a highly effective tool. In more advanced ERP’s, such as Dynamics 365 BC, a functionality called dimensions is very effective.
At the end of the accounting period, download the project transactions to a spreadsheet. Use a spreadsheet column to build a list of values which are attached to each transaction. For example, in an office renovation, build list values such as painting, flooring or lighting. For a marketing event, values such as invitations, booth set up, and giveaways would be used. If you were able to set up a user field, or use dimensions, structure the download to include the field or dimension value in the column discussed above. Applying these values to transactions allows the accountant to filter the transaction data by type, improving the project reporting process.
While the process described above will work for simple project accounting tracking the user should be aware of some disadvantages associated with this approach.
When downloading transactions to, and generating reports from, spreadsheets additional reconciliation between the general ledger and the spreadsheet is required. Since the data is now stored in two separate silos accurate project reporting is dependent on data consistency.
Any spreadsheet and/or GL changes related to project accounts need to be coordinated. In an uncoordinated situation download process errors will occur causing reconciliation and reporting problems. This is a major dis-advantage of using non-integrated systems, as both systems need to be updated simultaneously. Again, if you’re using this method to track a small number of basic, non-invoiced projects, controlling this process should not create any major issues.
Many of today’s accountants are well-versed in Excel. However, that’s not the case for all accountants. This may be particularly true in smaller companies who use entry level accountants or bookkeepers. Remember, you’re using this process to track simple projects and as such, the associated spreadsheets should be simple and easy to use. Try to keep the spreadsheets simple.
In my mind’s eye, I’d stay away from pivot tables, macros and similarly complex features. If you need to use these advanced functions, be sure to document them allowing others to use the spreadsheet correctly and efficiently.
Don’t let an out of office or personnel change situation affect project accounting productivity by having to take time to understand how the spreadsheet works.
Using the General Ledger only to track project accounting transactions can be accomplished using a set of project GL accounts and sub-accounts. The accounts are used together to classify project accounting transactions. For example, accounting sets up a project accounting GL account representing a single project (e.g., warehouse equipment upgrade). Depending on the project, the GL account may be mapped to the Balance Sheet or Income Statement.
Using this method, sub-accounts are then built beneath the GL account to capture the details. In our example, the GL project account would be warehouse equipment upgrade. Sub-accounts underneath the project account would be classifications such as engineering fees, equipment, installation etc.
As the applicable project transactions are processed, accounting and accounts payable code the transactions to the applicable GL account or sub-account. Again, transactions can be identified in the transaction’s description or by the vendor selected, in the case of accounts payable vouchering. If GL journal entries are posted to the project account, the transaction description is used.
Dynamics 365 BC central supports a functionality known as dimensions. Dimensions can limit the number of sub-accounts needed and can replace the user fields described in the GL Accounts and Spreadsheets section above. Dimensions can be selected when processing journal entries or in the vouchering process to provide additional granularity.
The advent of ERP dimensions functionality is very promising. To assist you in learning more about how dimensions can be used, I found some information on the Microsoft learning website that you might want to review.
As the number of projects grows, the GL becomes encumbered with GL accounts and dimensions which are used only once. Over time, these accounts result in an overly large chart of accounts (COA) which becomes awkward to maintain and can also result in reporting difficulties. Additionally, once these accounts and dimensions are set-up in the GL, they are not easily deleted, making any effort at correcting the COA a challenging task.
But again, if you’re using this project accounting method to track a small number of basic, non-invoiced projects controlling this should not be a major issue.
Project accounting means different things to different companies. Project centric companies have transaction processing and reporting requirements which can’t be satisfied by using the General ledger only. Smaller non-project centric companies though can build an effective project transaction and reporting process using the General Ledger as we discussed in this post.
Remember, use the solutions which best suit your needs and keep things as simple as possible to get the most out of your project accounting methodology.