Construction IT Audit Software Consulting

A common ITGC scoping mistake at contractors is treating the project-management platform as an operational tool outside the SOX boundary, on the reasoning that it doesn't post directly to the general ledger. That reasoning doesn't hold once you trace the data flow: job costs, percent-complete calculations, and change-order status all originate in the project system and flow into the ERP, where they directly determine recognized revenue and the WIP schedule. Under a risk-based ITGC scoping approach, any system that originates data material to the financial statements is in scope, regardless of whether it posts to the GL directly — which means access controls, change management, and job scheduling/interface monitoring for the project-management platform need the same ITGC rigor as the ERP itself.

IT audit software needs to support this dual-application scope cleanly: separate control matrices for the ERP and the project-management system, with a third set of controls specifically for the interface between them (job scheduling, error handling, completeness monitoring). Access review testing, in particular, has to cover who can modify cost-code mappings, who can override or bypass the interface, and whether project-system access provisioning follows the same joiner-mover-leaver discipline as ERP access — gaps here are a frequent finding because IT teams historically treated the project system as a lower-criticality application and applied lighter access governance to it.

Change management ITGC testing at a contractor needs to cover two things most companies don't have: changes to the batch/API interface logic that moves job-cost data into the ERP, and changes to any configured calculation logic that computes percent-complete or EAC roll-ups, whether that logic lives in the project system, a middleware layer, or the ERP itself. A configuration change to how percent-complete is calculated — for example, switching a cost-code weighting or altering how committed-but-not-incurred subcontract costs factor into the EAC — is functionally a change to how revenue gets recognized, and it needs to go through the same testing, approval, and segregation-of-duties discipline as a change to the GL posting logic.

IT audit software should track these changes with enough granularity to distinguish 'infrastructure change' (a server patch, an interface schedule adjustment) from 'financially relevant logic change' (a percent-complete calculation modification), because the two carry very different testing requirements. A change log that doesn't make this distinction makes it hard for the IT auditor — or the external auditor relying on IT audit's work — to demonstrate that financially relevant changes specifically received the elevated review (typically including finance/accounting sign-off, not just IT approval) that this class of change requires.

Beyond the general controls (access, change management, operations), the interface between the project system and the ERP also has an application-control dimension: does the interface run completely and accurately every cycle, and is a failure detected before it affects reported numbers. IT audit software should test for an automated completeness check — record counts or control totals compared between source and target systems after each interface run — and confirm that a failed or partial run generates an alert routed to someone who will act on it, rather than failing silently into the next scheduled run. A silent partial failure is exactly the kind of gap that produces an understated WIP position without anyone noticing until a much larger variance surfaces at close.

IT audit testing of this control should include actually observing or re-performing an interface run reconciliation for a sample period — comparing job-cost transaction counts and dollar totals in the source project system against what posted in the ERP — rather than relying solely on a management assertion that the interface 'runs fine.' This is one of the highest-value ITGC tests a construction company's IT audit function can perform, because a finding here has a direct line to a revenue-recognition risk, which is unusual for a general control and is exactly why it draws close attention from external auditors.