Construction Accounting and WIP Software Problems: The 6 That Cost Real Money, and How to Avoid Them

Why does the WIP get scoped as a report instead of a judgement layer?

Because the specification is written by looking at what the accounting system already holds. Job cost is there, billings are there, contract value is there as a single number, so a dashboard that computes percentage complete and over and under billings looks like the whole job. It gets built, it demonstrates well against last month's closed figures, and it is abandoned by the second live cycle.

It fails because work in progress depends on three things the ledger does not hold.

• Contract value at more than one recognition tier, since an original value, approved changes, changes awaiting owner approval, changes in negotiation, claims and directives performed under protest are not one number.
• Cost to complete, which is a forward looking judgement made by a person rather than a posted entry, and which needs a submission, an approval and a history.
• Your firm's revenue recognition treatment, agreed with your accountant, applied the same way every month rather than reasoned out again each quarter.

The most useful single screen we build in this category is the comparison of the schedule at signed changes only against the schedule including probable changes, side by side. It tells the chief financial officer exactly how much of the reported margin depends on paperwork that has not come back yet, and most contractors find the number larger than they assumed. A report cannot produce that view because it has nowhere to put the state of a change order. Settle the change order state model and the recognition policy in design, with your accountant in the room, or you will build a prettier version of the export you already have.

What goes wrong when you migrate open jobs and historical schedules?

Every contractor commissions this mid stream, with thirty or forty open jobs, and the migration is where schedules slip. The problem is that the history exists as monthly workbooks and the workbooks disagree with each other.

Three things surface reliably. Contract values in the last schedule do not tie to the accounting system, usually because approved changes reached the spreadsheet before the ledger, or the reverse. Cost to complete figures have no author and no date, so the first month of the new system looks like every project manager changed their forecast at once when in fact they stated one for the first time. And prior periods were restated informally, so the audited figures, the surety submission and the internal file for the same quarter are three different documents.

The approach that works is to migrate positions rather than history. Establish opening contract value, costs to date, billings to date and retainage per job at a chosen cut off, reconcile each to the accounting system to the dollar, and attach prior schedules as documents rather than importing them as data. Then run parallel for two full closes and reconcile the computed schedule against the controller's spreadsheet line by line. Every difference is either a defect or a policy question, and the policy questions are the valuable output. Do not let anyone quietly adjust the new system to match the old spreadsheet.

Why do accounting system integrations break after launch?

The judgement layer only works if job cost, commitments and billings arrive reliably, and this is where builds get into trouble a few months in rather than on day one.

The recurring failures are specific to construction platforms. Older on premise systems customised for a decade often have no supported interface, so a developer reads the database directly and a vendor patch changes a table, after which the extract silently returns partial data. Cost codes get added mid job, so a mapping complete at launch develops gaps. Job numbers get reused after a restructure. Commitments live in a purchasing module that closes on a different calendar from the ledger, so the same day gives two answers depending on when you asked.

What protects the build is treating every extract as untrusted. Reconcile total job cost per job per period against the accounting system's own trial balance and refuse to publish a schedule when they disagree. Alert on unmapped cost codes rather than defaulting them into an other bucket. Version the mapping so a prior period reproduces exactly as published. And agree with the vendor in writing whether direct database access is supported.

What happens when retainage and contractor specific accounting are not covered?

These are the items that get deferred to phase two and then quietly determine whether the system is useful.

Retainage held by owners is not collectible on ordinary terms and often steps down at a defined completion point, while retainage you hold from subcontractors releases on its own conditions. When both sit in a standard aging report they distort days sales outstanding, cash forecasting and the working capital picture your bank is testing against a covenant. Retainage release is also one of the largest single cash events on any job and most contractors forecast it from memory, so modelling it as a tracked balance with a release condition and an expected date changes borrowing decisions.

Committed cost has the same shape. An open subcontract of $2.1M with $400,000 invoiced is $1.7M of exposure the ledger does not show, so a job looks healthy until the invoices land. A projection has to be incurred plus committed remaining plus uncommitted forecast, and the report that matters is not the one the surety asks for. It is the list of cost codes where the uncommitted forecast is still large late in the job, which is where buyout exposure and unpriced scope hide.

Then the contractor specific work: union fringe allocation across locals with different rates and reciprocity, certified payroll on public work, sales and use tax that differs by state and by whether material was installed or resold, joint ventures needing one job presented in two parent charts of accounts, and equipment cost allocated from an internal rate. Each is a rule set that generic software handles by making somebody adjust journals monthly. Be selective. Payroll is a solved problem, so the build should compute and prepare and let the existing system post.

Should you build custom or configure what you already own?

If you are running QuickBooks at $40M in revenue, the honest first recommendation is not a custom build. It is to move onto a real construction accounting platform. 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 stack. Jonas Construction Software serves service and specialty contractors well. Configuring one of those correctly solves more problems than a bespoke system will, and costs less.

Equally, almost nobody should replace those platforms with custom software. What none of them removes, and every contractor who owns one will confirm this, is that the work in progress schedule is still assembled in Excel. That is the gap worth building into, and it is a layer on top rather than a replacement.

Under roughly $25M with straightforward lump sum work and few change orders, a good package plus a disciplined monthly spreadsheet is proportionate and you should not build. The case starts above roughly $40M, or earlier if you run joint ventures, carry heavy unapproved change order value, work across several states with different tax and prevailing wage treatment, or have been asked for an interim schedule and could not produce one inside a week.

How do hidden costs get into the quote?

The bands are $60,000 to $130,000 over 12 to 18 weeks for a first release covering contract value with change order states, the cost to complete workflow and the automated schedule with over and under billings, and $160,000 to $400,000 over 7 to 12 months for a full platform. Overruns come from a short list of places.

Joint ventures are the largest single driver, because dual chart of accounts reporting is genuinely difficult and it is usually mentioned late, after the estimate is fixed. The number of accounting systems you integrate with is the second, and it is more than one surprisingly often after an acquisition. The age of the existing platform is the third, and the discovery work to establish whether it has a supported interface is worth paying for before the estimate is signed. Certified payroll and prevailing wage is detail heavy. Multi state tax treatment multiplies rules rather than adding them.

Two costs are almost never quoted and should be. Your accountant's time reviewing the revenue recognition logic during development rather than at acceptance, which is worth its fee because the output feeds your audited statements. And parallel running, which needs the controller for two closes and gets cut when a schedule tightens, at exactly the moment it protects you most.

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

What separates a build that works from one that fails here?

The builds that work change behaviour rather than presentation. Cost to complete stops being an email and becomes a workflow: each project manager sees their jobs at cut off with committed and incurred cost by cost code, a proposed figure from the trend, and a requirement to accept or override with a reason. Anything moving projected margin beyond a threshold routes to the chief financial officer before it reaches the schedule. Within two quarters you have forecast accuracy history per manager, which changes how you staff jobs and is a bigger return than the time saved on the close.

The builds that fail were usually chosen by people who did not test the developer on the domain. Ask them to explain over and under billings before you discuss technology. If they cannot describe costs and estimated earnings in excess of billings without checking, they will build 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, and expect states, a probability assessment and a recognition policy set by your accountant rather than a checkbox marked approved. Ask which construction accounting systems they have integrated with by name and version, and whether they read the database directly or through a supported interface.

Then settle ownership in writing before kickoff. You should own the repository, the infrastructure accounts and the right to hire anyone else. For a system your surety relies on, that is not a negotiable term.