Every month, finance teams in Australian construction businesses spend days assembling WIP schedules in Excel. The work gets done, the numbers get reported, and the process repeats. What rarely gets measured is what that process actually costs , in time, in risk, and in the margin decisions made on data that was already out of date when it was produced.

What the WIP process actually looks like

In a typical construction business at the $20M-$50M turnover mark, the WIP schedule involves pulling cost data from the accounting system, estimated cost-to-complete from project managers (usually in a separate spreadsheet), contract values from the contracts register, and approved variations from somewhere else entirely. Someone then assembles these inputs into the WIP table, calculates recognised revenue and the overbilling or underbilling position, and reconciles the result to the general ledger.

On a good month, this takes two to three days. On a bad month , a new project, a disputed variation, a subcontractor claim that landed after the cut-off , it takes longer. And the reconciliation never quite closes cleanly first time.

The time cost

A finance manager spending two and a half days per month on WIP is spending 30 days a year on a process that produces a number. Not insight. Not analysis. A number. At a total employment cost of $120,000 to $150,000 per year for an experienced construction finance manager, two and a half days per month represents roughly $15,000 to $18,000 in annual labour cost , just for the WIP schedule.

That does not include the project manager time spent completing cost-to-complete estimates, the CFO time spent reviewing and querying the output, or the rework when the reconciliation fails.

Related resource

Is your WIP process holding your business back?

Get your personalised Construction Finance Maturity Score in 15 minutes.

Get your maturity score → See related content

The error cost

Manual processes produce errors. A miskeyed cost figure. A variation included in revenue but not yet reflected in the contract value. A project marked as 80% complete based on an estimate that was last updated six weeks ago. These errors flow directly into reported profit.

In a business with 20 active projects and a $40M revenue base, a 2% error in the WIP calculation represents $800,000 in misstated revenue. For a business with bank covenants tied to profitability metrics, that is not an accounting problem. It is a financing problem.

The decision cost

The most significant cost is the one that is hardest to measure: decisions made on stale data. If your WIP schedule takes three days to produce after month-end, and month-end itself closes a week after the period ends, the CFO reviewing project margins is looking at information that is up to three weeks old. Projects that were profitable on paper may have blown out in that window. Subcontractors who looked manageable may have submitted claims that change the picture entirely.

Construction is a cash-intensive business with thin margins and rapid cost movements. Three-week-old data is not financial visibility. It is financial history.

What system-driven WIP looks like

In Sage Intacct, WIP is not a separate process. It is a product of the data already in the system. Project costs are captured against cost codes as they are incurred. Contract values and approved variations are maintained in the project record. Percentage of completion is calculated from actual costs against estimated total cost. The WIP schedule is produced on demand , not assembled from multiple sources.

The reconciliation closes automatically because the WIP balance is derived from the general ledger, not imported into it. There is no separate spreadsheet to maintain. There is no manual step between the field and the financial statement.

For a construction business at $20M to $100M in revenue, moving WIP from a spreadsheet process to a system-driven process typically saves two to three days per month in finance team time, reduces reporting lag by 10 to 15 days, and eliminates the category of errors that come from manual data assembly.