Generic descriptions
Rows such as “Product Data” or “Shop Drawings” force the next user to reopen the specification to learn what is actually needed.
Construction submittal register
A useful submittal register starts with the actual requirements.
A register is more than a list of specification sections. It should tell the project team what must be submitted, where the requirement came from, and what needs human review.
In this guideWhat a register isWhy it mattersWhere requirements come fromFields that matterSubmittal typesHow it is builtQuality test
What is a construction submittal register?
A construction submittal register is the project team’s working list of required product data, shop drawings, samples, certificates, test reports, closeout documents, and other deliverables identified in the contract documents. It is also called a submittal log, although some teams use “log” for the live tracking record and “register” for the initial list of requirements.
The register is usually assembled early because its value is planning. It helps the team identify what must be prepared and reviewed before procurement, fabrication, installation, testing, or closeout. Once dates and responsibility are added, the register becomes a bridge between the contract requirements and the project schedule.
Why the register matters before the first package is submitted
A submittal is not simply an administrative document. It can stand between the project and a material release, a fabrication slot, a design decision, or work in the field. If the register is created late or contains vague entries, the team has less time to obtain information, coordinate trades, perform contractor review, respond to design comments, and resubmit when necessary.
The register also creates a shared understanding of scope. It gives the general contractor a basis for assigning preparation responsibility and gives subcontractors a way to confirm that their expected deliverables match the specifications. It cannot settle every contractual question, but it exposes those questions earlier.
Where register requirements come from
The project manual is the primary source for many register items, but it is not the only contract document that matters. Division 01 typically defines procedures, timing, formats, and contractor responsibilities. Technical sections identify specific product, fabrication, quality, testing, and closeout deliverables. Drawings, schedules, addenda, bid clarifications, delegated-design notes, owner requirements, and contract provisions may add or modify obligations.
For that reason, a register generated from specifications should be described accurately: it is a strong specification-derived starting point that the project team completes through broader contract-document review.
The fields that make the register useful
At minimum, record the CSI section, section title, a specific action title, submittal type, responsible party, and status. A defensible register also records the source page and paragraph. Schedule dates become useful once they are tied to procurement and installation needs.
Keep the action title separate from the type. “Shop Drawings” tells the team how information will be presented; “Power, signal, and control wiring diagrams” tells the team what must be produced. Combining both into a vague cell makes filtering and responsibility assignment harder.
Register fieldPractical use
Register numberProvides a stable internal identifier independent of a later package number.
CSI section and titleIdentifies the technical scope and supports sorting by trade.
Action titleStates the actual deliverable in clear project language.
TypeClassifies product data, shop drawings, samples, reports, certificates, and other records.
Source referenceRecords the page, paragraph, and evidence needed to verify the item.
Responsible partyShows who is expected to prepare or obtain the information, subject to team confirmation.
Review statusDistinguishes unreviewed findings, open questions, verified items, and exclusions.
Schedule datesConnects preparation and approval to procurement, fabrication, and installation milestones.
Common types of construction submittals
Product data usually consists of manufacturer literature, technical characteristics, installation instructions, and options for a proposed product. The useful register title identifies the product or system—not merely “Product Data.”
Shop drawings communicate project-specific fabrication, layout, assembly, coordination, or installation information. Examples include reinforcing placement drawings, curtain-wall details, door hardware schedules, and control wiring diagrams.
Samples communicate physical characteristics such as color, texture, finish, range, or workmanship. A specification may distinguish initial selection samples, verification samples, and field mockups; those distinctions affect timing and purpose.
Certificates and qualification data document compliance, experience, authorization, testing, installer qualifications, or other required credentials. They can be easy to overlook when located in quality-assurance articles.
Design data and calculations may support delegated-design work or demonstrate performance. These requirements deserve careful responsibility review because they can involve a licensed design professional.
Test reports and field records may be submitted before work, during installation, or after testing. The register should distinguish planned approval items from records generated in the field.
Closeout submittals include warranties, operation and maintenance data, record documents, training records, spare materials, and similar turnover requirements. Some teams keep them in the main register; others maintain a coordinated closeout log.
Build it from the requirements
Do not make one line for every section and call it complete. Read Division 01 for process requirements, then review technical sections for the actual deliverables. Requirements can appear outside a neatly labeled “Submittals” article.
Work systematically. Confirm the document issue and applicable scope. Review the hierarchy of every relevant section. Capture the specific action and source. Classify it. Then examine related findings for duplicates, child requirements, and packaging. Only after the content is reviewed should the project team assign responsibility and schedule dates.
A register row should represent a usable unit of work. If a paragraph requires product data for several independently procured products, separate rows may be useful. If several bullets describe the required contents of one coordinated shop drawing, they may belong together. There is no universal grouping rule; preparation responsibility, timing, and review path are practical tests.
A quick quality test
Pick ten register entries at random. Can another person understand the required deliverable without reopening the entire section? Can they reach the supporting language immediately? Can the responsible trade tell whether the item will be prepared separately or as part of a package? If any answer is no, the register still needs work.
Then test completeness. Review several technical sections manually, including at least one with complex quality-assurance or closeout language. Compare what is present in the register with what the section actually requires. This sample does not prove perfection, but it reveals whether the review method is producing useful results.
Submittal register versus submittal schedule
The register identifies the required deliverables and tracks their disposition. A submittal schedule adds the timing needed to support the work. On many projects the two are maintained together, but dates should be based on real logic: required-on-site date, procurement or fabrication duration, approved-submittal lead time, expected review duration, and time for contractor preparation.
Simply assigning sequential dates to every row creates the appearance of planning without connecting the register to the construction schedule.
Submittal register versus submittal package
A register entry records a requirement. A package is the actual coordinated transmission sent for review. Several entries may be assembled into one package, and one broad requirement may ultimately be split into several packages.
Keeping those concepts distinct allows the initial register to remain traceable even when the project team later adjusts packaging for procurement or coordination.
What weakens a construction submittal log
Keyword noise
Procedures, definitions, and references containing “submit” are treated as deliverables, making the log longer but not more complete.
No evidence
Without a page and paragraph, omissions and interpretation disputes become time-consuming to investigate.
Flat grouping
Every bullet becomes a row even when several bullets describe the contents of one submittal—or one sentence contains distinct actions.
Premature responsibility
A trade is assigned before cross-references, delegated design, supplier involvement, or contractual scope have been reviewed.
Dates without logic
Submit dates are entered without working backward from approval, procurement, fabrication, and required-on-site milestones.
Submittal register FAQs
Who creates the construction submittal register?
The general contractor commonly prepares the project-wide register, often through preconstruction, project management, or project engineering staff. Subcontractors may also prepare scope-specific registers and should review the contractor’s list against their contract documents.
When should the register be created?
As early as practical after the governing contract documents are available. Early creation leaves time to resolve scope questions and plan long-lead, delegated-design, sample, mockup, and early-release requirements.
Is a submittal register required on every project?
Requirements vary by contract. Even when a formal register is not expressly required, a working list is a practical control for identifying and planning required deliverables.
Should every specification section have a row?
No. Some sections contain many distinct submittals; others contain none. The unit of the register is the actionable requirement, not the section itself.
Can Excel be used for a submittal register?
Yes. Excel is flexible and familiar, particularly for smaller projects or teams with a disciplined manual-review process. Our free template includes source and review fields. Software becomes more valuable as document volume and review complexity grow.
Does a specification-derived register include drawing requirements?
Not automatically. Drawings, schedules, general notes, addenda, and other contract documents may contain additional obligations. They should be reviewed as part of completing the project register.