ERP for construction accounting: Key features CFOs should require

A subcontractor invoice sits in an inbox for a week. The PM updates the forecast without it. Margin looks fine, until the invoice posts and it isn’t. That gap, between what the field already committed and what finance can see, is what you are buying an ERP to close.

Construction ERP fits contractors who need field activity, job cost, WIP, billing, retainage, and the reports their bank and bonding company read to live in one system. It is too much system for a contractor whose current accounting already produces current job cost, a repeatable WIP schedule, and reporting the team trusts. Before you shortlist anything, make a vendor trace one of your real jobs from estimate to financial report, with your cost codes, approvals, and WIP schedule.

Most contractors have plenty of data and still wait too long for the truth about a job. CFOs evaluating construction ERP should ask which system can trace what the field actually does into the reports you close, explain, and hand to your bank and bonding company. A better general ledger alone will not do that.

We spend our days implementing these systems for construction firms, and the demos that go wrong all fail the same way: the software performs on generic data and falls apart on yours. So make every vendor prove the path from field activity to the financial report, using your own job and your own approval mess.

Why your monthly statements lie to you between closes

Monthly financial statements still matter. They close the books and carry your lender, bonding, and executive conversations. They just do not move at project speed, and the gap between closes is where margin disappears.

A cost coded to the wrong phase makes one job look healthy and buries an overrun on another. A pending change order left out of WIP makes revenue risk vanish until the next review. Retainage tracked in a side workbook turns cash timing into a monthly scavenger hunt. Every one of these is a workflow and ownership problem. An ERP earns its price only when it surfaces cost exposure and shaky assumptions early enough for the right person to act.

We sat down with Troy Guevara, our Construction Technologist focused on construction ERP, to test what CFOs should require. Troy ran his own contracting business for over 15 years before coming into ERP and helping build our construction-first Sage practice after Digitech Solutions merged into the company. His first warning was about adaptation: the thing contractors are best at, and the thing that hides accounting pain for years. A crew that can work around anything will work around a broken accounting process too, for years.

That instinct to adapt changes how you should select. If your team has normalized late job cost updates, manual WIP workbooks, AP approvals stuck in limbo, and PMs running their own spreadsheets, a feature checklist tells you nothing useful. Only a demo that follows your real work exposes whether the software can carry that mess. Start the evaluation with the work your team keeps reconciling and defending.

Job costing is the spine: get the structure wrong and every report becomes debatable

Job costing is where construction ERP earns trust or loses it. CFOs should require a clean line from the original estimate through the budget, cost codes, commitments, actuals, and forecast to the project P&L. Detailed enough to show risk; simple enough that PMs will actually use it. Too little detail hides margin problems. Too much creates noise that PMs route around.

The requirement that gets skipped is ownership. Someone has to govern the cost code list: approve additions, kill duplicates, decide how new work types get represented. Skip that, and here is what breaks: six months after go-live you have three versions of “sitework,” duplicate cost codes, PM reports that will not roll cleanly into the WIP schedule, and a controller rebuilding categories by hand every close. An ERP takes whatever loose structure you give it and publishes it faster.

This is also where construction ERP parts ways with a standard accounting upgrade. A general contractor, a specialty trade, and a heavy civil firm each manage cost differently. Fit starts with how your work is structured. The logo on the box tells you almost nothing.

Labor is the cost you can’t claw back, so you have to see it early

Labor is the hardest cost to recover after the fact. Once the hours are spent, the system can only explain them, unless managers see the trend early enough to change staffing, sequencing, or the forecast. Troy was blunt about the stakes:

“The other major area is labor visibility. Everything else on a job can be estimated and change-ordered. Labor is the one variable you can’t control, and if you can’t see your labor costs in real time, you’re going to lose money.”

An ERP earns its keep here by showing when labor lands in job cost, how it gets reviewed, and who is accountable when the data arrives late. Ask the vendor to name the schedule for labor posting and the person who reviews it. The same goes for committed costs: purchase orders, subcontracts, and invoices awaiting approval should stay visible well before they post to the general ledger. Make vendors show pending exposure before it surfaces as a surprise in the margin report. A contractor who can only see committed costs after they hit the GL is always managing last month.

WIP is only useful if your team can explain it

WIP reporting connects project execution to financial position. It carries your bank and bonding conversations and your executive margin reviews. A WIP report earns trust when the team can defend the assumptions behind it in front of a banker. So in the demo, push hard on the definitions:

• Percent complete: how the system calculates progress and where human judgment enters.
• Cost-to-complete: who enters the forecast, how often it is reviewed, and what approval it requires.
• Over- and underbilling: how the system surfaces billing position against earned revenue.
• Audit trail: whether accounting can see what changed, when, and by whom.

An ERP gives you one governed place to capture assumptions and explain variance. Accuracy still depends on your team. That place disappears when WIP lives in a workbook only the controller understands. When that person is out at close, the schedule stops being defensible.

Judge AP automation as job cost control

AP automation matters when it makes pending liabilities visible before they distort the project view. Scanning the invoice and routing the approval are the easy part. Troy described the shift on the ground:

“Instead of an invoice sitting on someone’s desk for days before it gets entered, it comes in, gets read automatically, and routes directly to the approver.” The accountability matters as much as the routing: “If my job cost report isn’t current, and I’ve got 30 invoices sitting in the queue waiting for my approval, that’s on me. I can see it. It puts accountability where it belongs.”

So in the demo, ask for the unposted invoice report by job, approver, aging, and cost code. If accounting cannot see what is sitting outside job cost before close, the system is routing documents without giving you cost control. Test the exceptions too: OCR misreads, approvers stall, coding comes in wrong. The system should make status and accountability obvious precisely when the process is imperfect, because it always will be.

Change orders, retainage, billing, and compliance are one risk workflow

Revenue and risk cannot live scattered across spreadsheets, email, and standalone project tools. Pending change exposure moves forecast margin. Approved changes move contract value and billing. Retainage moves cash timing. Compliance holds move payment decisions. They are the same workflow, and the failure pattern is familiar: the PM books a pending change as real margin, accounting leaves it out of WIP, billing can’t touch it yet, and cash planning assumes retainage releases sooner than the contract allows. Four people, four versions of the same job.

Ask vendors to show how those pieces move together. A pending change should be visible before approval; an approved change should update the financial view; retainage should track through billing and release; missing subcontractor documentation should hold payment without dropping out of sight. And ask who maintains each piece: some of this is built into the ERP, some is configured at implementation, some lives in connected tools. The contractor who never asks finds out at the worst time which report not to trust.

Test it on your own work

Feature names are easy to say yes to. A useful demo follows the work from estimate to financial report using your own sample job and your own approval problems. The table below is the version of that demo we run with clients. Bring a sanitized active job, your cost code structure, a WIP example, AP rules, change order definitions, and the reporting packages your executives, bank, or bonding company already ask for. Sanitized data is fine. Generic data tells you nothing.

The right category varies by contractor. Some need a purpose-built construction ERP, some a finance-centered platform with strong construction depth, some a broader operational system with the right implementation partner. Most modern options are cloud systems, which give the field, approvers, and accounting browser access to the same data and take server upkeep off your IT team.

The shortlist test stays the same for all of them. Before a vendor earns a spot, make it prove three things on your scenarios: that project activity traces into financial reporting, that the system supports the governance your leadership will actually enforce, and that the reports hold up without a month-end spreadsheet rescue.

Reporting works only when accounting, PMs, and executives agree on the definitions behind it. If they disagree, the ERP just publishes the disagreement faster. Finance can own the standard, but operations has to own the behaviors that feed it.

If your current system already gives you current job cost, a repeatable WIP schedule, visible approvals, and reporting your team trusts, a full ERP change can wait. If finance keeps exporting, reconciling, chasing approvals, and explaining conflicting numbers, you have a trust problem, and software is only part of it. Put a construction ERP on the shortlist once a vendor proves it can carry your job, your cost code structure, your WIP definitions, and your approval workflow into reports your team trusts while there is still time to act. If the demo cannot show how your work becomes your numbers, the vendor has not earned the shortlist.