Construction SOX Compliance Consulting

Under ASC 606, a construction contract typically qualifies for over-time revenue recognition when the customer controls the asset as it is created (common on unique, non-transferable structures) or when the contractor has no alternative use for the asset and has an enforceable right to payment for work performed to date. Once a contract qualifies, revenue is recognized using an input or output method — cost-to-cost is the dominant input method in the industry — where recognized revenue equals total contract price multiplied by percent complete, and percent complete equals costs incurred to date divided by total estimated cost at completion (EAC). The material misstatement risk here is structural: because EAC is a forward-looking estimate, not a historical fact, the same underlying project can support a range of legitimate revenue-recognition outcomes depending on assumptions about remaining costs, productivity, weather delays, and subcontractor performance. A biased or unreviewed EAC is the single most common source of restated construction-company financials.

This is why SOX programs at construction and engineering firms spend a disproportionate share of their control-design effort on estimate governance rather than on the mechanical journal entry that posts recognized revenue. The controls that matter are: who prepares the EAC (usually the project manager or project controls lead), who independently reviews it (a cost engineer or estimating manager not reporting to the project manager), what triggers a required re-forecast (a change order, a schedule slip beyond a materiality threshold, a subcontractor default), and how often the EAC is refreshed relative to the financial close calendar. A control environment where EACs are updated only when a project manager remembers to update them, rather than on a fixed cadence tied to close, is a common finding in first-year SOX gap assessments for contractors that recently crossed the accelerated-filer threshold.

Most mid-market and large contractors run job costing, scheduling, and change-order tracking in a project-management platform — separate from the financial ERP that produces the general ledger, the balance sheet, and the SEC filings. Labor hours, committed subcontract costs, material costs, and percent-complete calculations typically originate in the project system and then interface — via batch upload, API integration, or in weaker environments, manual re-entry — into the financial ERP where revenue is actually recognized. This interface is structurally identical to the billing-system-to-financial-ERP boundary that shows up in telecom SOX programs: a system of record for the operational transaction feeds a separate system of record for the financial statement, and the translation between them is where controls most often break down undetected.

The specific risks at this boundary are completeness (did every job-cost transaction from the project system actually land in the ERP, or did some get dropped in a failed batch job), accuracy (did cost codes map correctly to GL accounts, and did the percent-complete calculation transfer without truncation or rounding drift), and timing (does the interface run frequently enough that the ERP's WIP schedule reflects current job status at close, or is there a multi-day lag that creates a cutoff problem). A well-designed control set includes a reconciliation — performed by someone outside the project-accounting function — that ties total job-cost activity in the project system to what actually posted in the ERP for the period, with any variance investigated and cleared before close.

A change order is a contract modification, and under ASC 606 it can be accounted for as a separate contract, a modification of the existing contract (cumulative catch-up), or a termination-and-new-contract, depending on facts. Getting the accounting treatment wrong is common when change-order approval authority sits with project management and the accounting determination is made after the fact by someone unfamiliar with the specific contract language. The SOX control here is a formal approval workflow that routes change orders above a materiality threshold through both a commercial/legal review (does this change scope, price, and does the contract language support separate-contract treatment) and an accounting review (what is the correct ASC 606 treatment) before the change order affects the EAC or the billed amount.

The work-in-progress (WIP) schedule is where all of this converges — it is the project-by-project summary of contract price, costs incurred, billings to date, and over/under-billing position that ties percentage-of-completion accounting back to the balance sheet (costs and estimated earnings in excess of billings, or billings in excess of costs and estimated earnings). A monthly or quarterly WIP review, performed by a controller or CFO-level reviewer independent of individual project managers, that specifically investigates projects with unusual over/under-billing swings, margin fade, or EAC changes without a corresponding change order, is one of the highest-value application controls a contractor's SOX program can implement. Auditors testing ICFR at a construction company will almost always sample WIP schedule review evidence as a primary control.