Data Engineering for Construction: Pipelines From ERP, Field, and Schedule Into One Truth

A GC starts building a data platform and discovers that construction data doesn't behave like typical enterprise data. Jobs are created, have costs accumulated against them for months or years, and then close — but they don't close cleanly because retainage holds, warranty reserves, and final change orders can extend for years after substantial completion. Cost codes are hierarchical but the hierarchy varies by division and sometimes by project. Subcontractor data exists in the ERP as vendor records, in Procore as company records, in the safety platform as contractor entries, and in the prequalification system as applicants — all with different IDs. The scheduling system tracks activities that map loosely but not exactly to cost codes. And the controller adjusts the ERP data every month for accruals that don't appear in the raw transaction data. Generic ETL that ignores these realities produces a data platform that doesn't tie to the controller's numbers.

Construction data engineering done right uses the medallion pattern with construction-specific discipline. Bronze ingests each source with deduplication. Silver applies the master data alignment — mapping job IDs, sub IDs, cost codes, and employee IDs across systems. Gold provides the business-ready models that include the controller's accruals, retainage positions, and cost-to-complete estimates. Reconciliation jobs compare gold-layer job cost totals against the ERP's WIP schedule after every load and surface variances. Monitoring catches the failed Procore sync before the PM's morning review. This is the discipline that separates construction data platforms that get trusted from ones that produce numbers nobody believes.