The submittal register is built from the specifications at the start of a job. Someone (often a project engineer) reads each spec section and lists every shop drawing, product data sheet, sample, mockup, test report and closeout item it calls for. Each line gets a spec section number (usually by CSI MasterFormat), a description, the responsible subcontractor, and the dates that matter.
The key dates work backward from the schedule: when the material must be on site, minus lead time for fabrication and delivery, minus the architect’s review period (often 10 to 14 days per round under the contract), minus time for a likely resubmittal. That gives a “submit by” date for each item. As submittals move through review, the register tracks status: approved, approved as noted, revise and resubmit, or rejected.
Why it matters
Long-lead items like switchgear, elevators, curtain wall and air handlers can take months to fabricate. A late submittal on one of them can delay the whole job, even when the field work is on time. The register is how a PM sees that coming months ahead instead of weeks.
Common mistakes
- Building the register late, after subs are already behind.
- No required-by dates tied to the schedule, so everything looks equally urgent.
- Not tracking architect review time, so reviewer delay is invisible when it’s time to claim it.
- Releasing material orders before the submittal is approved.
How os.construction handles it
We’re building a submittal register that links each item to the spec section, the sub’s commitment and the schedule activity it feeds, so late items flag against the dates that actually matter. It’s in development.