Construction Accounting and WIP Software: Why Your Work in Progress Schedule Is Always Two Weeks Late

The surety asks for the WIP, and everyone stops what they are doing

The agent wants an interim work in progress schedule for 34 open jobs, and wants it this week. The controller opens the accounting system and pulls job cost to date. Then the committed cost report, because open subcontract balances are not in the ledger. Then the change order log, which lives in the project management system and contains 90 approved changes, 41 pending owner approval and 12 in dispute. Then he emails the project managers asking for cost to complete on each job, and waits.

Eleven of them reply within three days. Four give a number identical to last month, which either means nothing changed or means nobody looked. One replies with a figure that implies the job just moved from a 9 per cent margin to a 2 per cent margin, and nobody escalated it, because the number arrived in a spreadsheet attachment rather than a system that flags a change of that size.

The finished schedule shows costs and estimated earnings in excess of billings on some jobs and billings in excess on others. The surety underwrites your bonding capacity from it, the bank tests covenants against it, and the audited statements are built on it. It was compiled by one person from five sources, and if he leaves, the company's ability to describe its own financial position leaves with him.

What contractors already own, and where it stops

The serious construction accounting products are real and we recommend them regularly. Foundation Software is well built for contractors who need payroll and job cost done properly without excessive complexity. Sage 300 CRE has decades of contractor accounting behind it. Trimble Viewpoint Vista and CMiC go further into an integrated enterprise stack. Jonas Construction Software serves service and specialty contractors well. If you are running QuickBooks at $40M in revenue, the first recommendation is not a custom build, it is to move to one of these.

Here is what none of them removes, and every contractor who owns one will confirm it: the WIP schedule is still assembled in Excel. The reason is consistent across products. WIP depends on contract value including changes at varying levels of approval, on cost to complete that is a judgement rather than a ledger entry, and on the specific revenue recognition treatment your CPA has agreed for your business. Packaged systems hold the ledger side well and treat the judgement side as a data entry screen that nobody uses, so the controller exports and rebuilds.

Which points at the right build. Very few contractors should replace their construction accounting system. What they should build is the layer above it that captures judgement, enforces discipline and produces the schedule.

Problem one: contract value is not one number

A contract has an original value, approved change orders, changes submitted and awaiting owner approval, changes being negotiated, claims, and owner directives performed under protest. Revenue recognition treatment differs across those states, and under current revenue standards the question is whether the consideration is probable of not reversing rather than whether the paperwork is signed. That determination is a judgement your CPA has views about, and it should be applied consistently rather than reinvented each quarter.

A build models each change as an object with a state, a value, a cost impact, a probability assessment and a documented basis, and computes contract value at each recognition tier. Then your WIP shows the position at signed changes only, and at probable changes, side by side. That comparison is the single most useful screen we build in this category, because it tells the CFO precisely how much of the reported margin depends on paperwork that has not come back yet. Most contractors discover the number is larger than they assumed.

Problem two: cost to complete arrives as an email, if at all

Every contractor knows that the WIP is only as good as the cost to complete, and almost every contractor collects it by asking. The result is a monthly ritual of chasing project managers, receiving four numbers that did not change, and no record of who said what.

The fix is workflow rather than accounting. The system presents each project manager with their jobs at cut off, shows committed and incurred cost by cost code, proposes a cost to complete from the trend, and requires acceptance or an override with a reason. Anything that moves projected margin by more than a threshold you set routes to the CFO before it lands in the schedule. A project manager who has not submitted by the cut off is visible rather than chased. Within two quarters you have a history of forecast accuracy per project manager, which changes how you staff jobs and how you weight their numbers.

Problem three: committed cost is invisible in the general ledger

An open subcontract for $2.1M with $400,000 invoiced represents $1.7M of exposure that the ledger does not show. Purchase orders for material with volatile pricing are the same story. When committed cost is not in the projection, a job looks healthy right up to the month the invoices land.

A build carries subcontract and purchase order commitments alongside incurred cost, so the projected cost at completion is incurred plus committed remaining plus uncommitted forecast. It also surfaces the gap that matters most: cost codes where the uncommitted forecast is large this late in the job, which is where buyout exposure and unpriced scope hide. That is a report a surety never asks for and an operations director should read every month.

Problem four: retainage is not a receivable and pretending otherwise distorts everything

Retainage held by owners is not collectible on normal terms and often steps down at a defined completion point. Retainage you hold from subcontractors releases on their own conditions. Both sit in aging reports as if they behave like ordinary balances, which distorts days sales outstanding, cash forecasting and the working capital picture a bank is testing.

A build treats retainage as its own tracked balance per contract with a release condition and expected date, and builds the cash forecast from it. Retainage release is one of the largest cash events on any job and most contractors forecast it from memory. Modelling it properly changes borrowing decisions, which is a direct financial return on the software rather than an efficiency argument.

Problem five: the contractor specific accounting nobody else has to do

Union fringe allocation across multiple locals with different rates and reciprocity agreements. Certified payroll for public work. Sales and use tax that differs by state and by whether material was installed or resold. Joint ventures where two parent companies each need the job presented in their own chart of accounts. Equipment cost allocation from an internal rate to job cost. Each of these is a rule set that generic enterprise software handles by making somebody adjust journal entries every month.

These are also the areas where you should be most careful about scope. Payroll in particular is a solved problem and rebuilding it is a bad use of money. The build should compute and prepare, and let the existing system post, unless you have a genuinely unusual structure that no product handles.

What it costs and how long it takes

A focused first release covering contract value with change order states, cost to complete workflow with override history, and the automated WIP schedule with over and under billings and margin trend runs $60,000 to $130,000 and ships in 12 to 18 weeks. A full platform adding committed cost integration, retainage tracking and cash forecasting, joint venture reporting, fringe and equipment allocation and a surety reporting pack runs $160,000 to $400,000 phased over 7 to 12 months.

What drives cost up for contractors specifically: joint ventures, because dual chart of accounts reporting is genuinely hard. The number of accounting systems you integrate with, which is more than one surprisingly often after an acquisition. Certified payroll and prevailing wage, which is detail heavy and unforgiving. Multi state tax treatment. And the age of your existing system, because integration with an on premise platform that has been customised for fifteen years is a different exercise from calling a modern API.

What keeps cost down: leaving the general ledger alone. Read job cost, commitments and billings from the system you already run, own the judgement layer and the reporting, and resist every suggestion to replace the accounting platform at the same time.

How to choose a developer for construction accounting work

Ask them to explain over and under billings before you discuss anything else. If they cannot describe costs and estimated earnings in excess of billings without checking, they will build you a dashboard on top of numbers they do not understand, and you will find out when your auditor does.

Ask how they will treat a pending change order. The right answer involves states, a probability assessment and a recognition policy set by your CPA, not a checkbox marked approved.

Ask which construction accounting systems they have actually integrated with, by name and version, and whether they read directly from the database or through a supported interface. Some of these platforms are unforgiving about direct access and an inexperienced team will find that out in production.

Insist that your CPA firm reviews the revenue recognition logic before it goes live. This is the one build where an outside accounting opinion during development is worth its fee, because the output feeds your audited statements.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts and the right to hire anyone else. At Digital Heroes the client owns the code from the first commit, and for a system your surety relies on, that ownership is not negotiable.