When a project-based firm outgrows its accounting software
Antoine Proulx-Landry, Solutions Architect at Metam
No firm outgrows its accounting system on a single day. Nothing visibly breaks and nobody makes a bad call. What happens instead is that the workarounds accumulate until they quietly become the system.
Each one solved a real problem at the time. The spreadsheet answered a question the software could not, the manual journal got revenue into the right period, and the purchase order folder stopped a project manager committing the same budget twice. The trouble is that none of them was built to work with anything else, so after a few years they carry more weight than the ledger does.
I do requirements work with project-based firms, which means I meet them at a specific moment: the controller opens a spreadsheet to explain how margin is really tracked. That spreadsheet tells me more than any system walkthrough.
The system behind it was usually chosen years ago, when the firm was small and running a handful of projects at a time. It was the right call then. It now runs alongside four or five workbooks that do what it cannot.
Five signals come up again and again. Most are fixable on their own without changing systems, but when they arrive together, they usually mean something structural.
The signals to watch for
Signal one: margin is calculated where the system cannot see it
Most of what gets labeled ROI on an ERP project is noise. Adoption metrics that do not tie to outcomes. Cost comparisons that ignore the operational baseline they are supposed to be measured against. Here is what is actually worth tracking, and why each one has a direct line to the business.
Measuring digital adoption speed. Not whether people are logging in, but how quickly teams drop the workarounds they built to survive the old system. In AEC, that shows up in how fast project managers stop keeping a shadow spreadsheet next to the ERP for budget tracking. The equivalent in manufacturing is how fast planners drop their spreadsheet next to the ERP for production and purchasing planning. Once that shadow spreadsheet disappears, adoption is real, not just reported.
Process time saved. Most firms measure this too narrowly, usually against one big milestone like project close. The real gain sits in the tasks that repeat every week: generating a WIP report, reconciling subcontractor billing, pulling numbers together for a leadership meeting. Time saved on frequent tasks compounds faster than time saved on any single big process.
Data accuracy improvement. Harder to quantify, easiest to underrate. If finance is still reconciling numbers across two systems six months after go-live, the accuracy gain promised at the outset has not shown up, whatever the adoption dashboard says.
These three, together, are the closest thing to a real digital transformation ROI signal on a Dynamics 365 project. Everything else is a proxy for one of them.
Signal two: revenue on long work is recognized by hand
Percentage of completion, milestone billing and retainage are all schedules, and calculating them by hand each period creates three problems.
The treatment drifts, so two similar contracts get handled differently depending on who prepared the entry and how tight the deadline was that month.
The workings sit outside the record. The journal is in the ledger, but the basis for it is in a workbook, and reproducing that a year later for an audit takes real work.
And the numbers inherit every lag in your cost data. Late timesheets understate cost to date, which overstates recognized revenue, and nobody catches it until the project closes out.
Signal three: committed cost is invisible until the subcontractor invoices arrive
Your system books cost when it is billed, but the commitment happened weeks earlier, when the purchase order went out or the subcontract was signed.
That gap is where margin goes. A project manager checks remaining budget, sees invoiced cost rather than promised cost, and makes the call anyway. By the time the invoices land the money is gone, and the variance meeting turns into a post-mortem.
Most firms patch this with a commitments log kept beside the accounting system. It works while one person can hold every open commitment in view, and it stops working the moment that is no longer true.
Signal four: month-end is a rebuild, not a close
A close reviews numbers the system already holds. A rebuild assembles those numbers from four places first, then reviews what you assembled.
The test I use is simple: what happens to month-end if the person who runs it takes two weeks off? If the close slips, the procedure is not written down because it cannot be. It lives as judgment about which file is current, which accruals need manual treatment, and which project codes got used loosely.
This is the signal I weight most heavily, because it compounds. A three-week close means the numbers arrive too late to act on, so decisions get made on the workbook instead, which makes the workbook more load-bearing every month.
Signal five: time and expenses get keyed in twice
Hours go into a project tool and then into the accounting system for payroll and billing. An expense is entered once by the person who incurred it, then again by accounts payable so that person can be reimbursed.
Double entry is not just a waste of effort. It produces two sets of transactions that do not agree, and it delays the moment work becomes visible as cost. That delay lands directly in WIP and in anything else calculated from cost to date.
It also leaves billable capture depending on a manual step, and hours keyed in late are hours invoiced late. Some are never invoiced at all.
The workarounds have a ceiling
Every one of these gaps has an automation answer, and firms build them. A macro that rebuilds the margin workbook, a flow that emails a project manager when a purchase order is raised, a script that pushes hours from the time tool into the ledger. Each one of them works.
The problem is what you own afterward. Automation needs something to act on, and on these systems there is no project to attach anything to, so every integration is an add-on that reads from one place, writes to another, and depends on the field names staying where they are. You are not automating a process. You are automating the workaround, and now the workaround has a maintainer too.
This is the ceiling most firms hit well before they hit any functional limit. It is not that older systems cannot be automated. It is that automating them adds infrastructure rather than removing it, and the same holds for anything you want to point at the data later.
What better process fixes, and where it stops
Not every firm with these symptoms has outgrown its system. Plenty have a discipline problem that looks like a software problem, and a migration would only carry it across at a higher price.
One question separates the two, and it is the first thing I try to establish in a scoping call. Could a competent person, following the correct procedure inside your current software, produce the number you need?
If the answer is yes, this is process, and it is worth fixing on its own terms. That means timesheets filed on time, purchase orders raised before the commitment rather than after, a project coding structure someone has reviewed in the last five years, dimensions configured properly rather than half configured, and a close checklist that exists in writing. All of it costs less than a platform change, and most of the value lands inside a quarter.
If the answer is no, process has nothing to work with. There is no project object, no commitment stage ahead of the invoice, and no revenue schedule the system can run itself, and no amount of training closes a gap like that. You can make the workarounds tidier but you cannot remove them.
So fix the process problems first. The system limits then show up on their own, with nothing left to hide behind.
What changes on the other side
Project accounting, not project reporting. Cost, revenue, time and commitments post against the project directly, at whatever level you measure margin, so margin stops being something a person calculates and the workbook has nothing left to do.
WIP and unbilled sit in the system. Work in progress, unbilled revenue and retainage exist as balances rather than period-end derivations, so you can see what has been earned and not yet invoiced without waiting for the close. For most firms that is the first current view they get of cash tied up in delivery.
Committed cost hits the budget when it is committed. A purchase order reduces available budget the day it is raised, project managers work from a live number, and variance becomes a warning rather than a finding.
The close gets shorter and much duller. Duller is the point, because the work shifts from assembling numbers to reviewing them, and more than one person is then able to do it.
What to have answered before a platform decision
The questions that derail implementations are rarely technical. They are the ones only you can answer, and they tend to surface halfway through configuration rather than before it. These are the five I ask first.
What is a project, and at what level do you measure margin? Contract, project, phase and task are all defensible answers, and the one you choose decides the shape of everything downstream.
Which revenue recognition method applies to which contract types, and who signs off? Implementation will force the question, and settling it under configuration pressure produces a policy that reflects whoever happened to be in the room that week.
Who owns a budget, and who can commit against it? Committed cost control is a permissions question before it is a software question.
What belongs in project cost, and what stays in overhead? That includes how labor is burdened and how indirect cost gets allocated, if it gets allocated at all.
Which number becomes the number of record, and what happens to the workbooks on go-live day? If they survive in parallel, you have rehoused the workarounds rather than removed them.
The firms that come out of this well are not the ones that moved fastest. They separated the process problems from the system limits, then made the policy calls deliberately, before configuration rather than during it.
What we do about this at Metam
We implement Microsoft Dynamics 365 Business Central and Dynamics 365 Finance and Operations for project-based firms, and Metam 365 is our accelerator for those deployments. Business Central suits firms moving off small-business accounting, while Finance and Operations answers scale and multi-entity structure. It carries the project structures, revenue recognition methods and commitment tracking as configured starting points rather than leaving them to be assembled from a blank system, which is where most of the five signals above get addressed: jobs that hold cost and revenue against a recognition method, purchase commitments visible against the job budget before the invoice arrives, and time posted once instead of keyed in twice.
The mechanism matters less than the principle. Any platform that holds a project as a real object can do this, and the ones that do not cannot be configured into it.
Where the work runs past finance and into delivery, Operate covers project operations for AEC and other project-based industries, and Engy is our AI platform for engineering firms.
The engagements that go well are the ones where the firm arrives having answered the questions above. That conversation is shorter, and the implementation is better for it.
Bring your five answers, or bring the questions
If the signals in this article sound familiar, a scoping call is the fastest way to find out whether you’re dealing with a process problem or a system limit. We’ll work through how you measure margin, recognize revenue and control committed cost, and tell you plainly which fixes belong in your current setup and which need a different platform.
