A reliable material submittal register is more than a list of products. It is a tracking record that helps construction engineers, document controllers, and consultants see what must be submitted, what is under review, what decision was made, and what evidence remains to close the item. This workflow focuses on reconciling the register with the submitted documents and project records.
Use it as general workflow guidance, not as a project approval or universal technical procedure. The contract, approved project specifications and drawings, submittal procedures, schedules, manufacturer information, and applicable authority requirements govern the actual requirements. Where they differ from this article, follow the governing project documents and the authorised project process.
1. Establish the register’s scope and source
Before reviewing entries, confirm which project, work packages, locations, and reporting date the register covers. Identify the register owner, current revision, document-control location, and the process used to update and issue it. Check that the register is the controlled working version rather than an exported or superseded copy.
Identify the source documents that establish what must be submitted. Depending on the project, these may include specifications, schedules, drawings, contract requirements, the project submittal procedure, or approved procurement information. Record the relevant document title, revision, and location so a reviewer can trace why an item appears in the register. Do not infer a requirement from a product name or from an old register entry when the governing source is unavailable or unclear; flag the gap for confirmation.
Keep general guidance separate from project-specific acceptance criteria. The exact content required for a particular material, the approving party, review period, and permitted disposition must be confirmed from the applicable project documents and procedures.
2. Check each entry’s identity and traceability
Review entries one by one and confirm that each has a stable identifier. Check the material or product description, specification or drawing reference where applicable, supplier or manufacturer if known, work package, location or system, and the responsible organisation. Use the project’s naming and numbering conventions; do not create a new coding rule in the register review.
Look for duplicates, inconsistent descriptions, and entries that combine distinct products or locations in a way that obscures their review status. Conversely, check whether a broad entry hides separate submissions that have different technical documents, reviewers, decisions, or procurement dependencies. If the project’s process requires separate submittals, split or cross-reference the records using that process.
Each register entry should be traceable to the actual submission and its revisions. Confirm that the document reference in the register matches the file or transmittal record, and that revisions are not silently overwritten. If the submitted package is revised, retain the project-required history or link to the controlled record so earlier comments and decisions remain intelligible.
3. Reconcile required documents with the submission
For each item, compare the submitted package with the requirements stated in the applicable specification, submittal schedule, or project procedure. Record what is required and what was received, rather than relying on a generic completeness label. Depending on the item and project requirements, the package may call for technical data, drawings, certificates, samples, mock-ups, or other supporting information. These are examples, not a universal list.
Check that the documents are legible, identifiable, current for the review, and associated with the correct product and register entry. Note missing pages, absent attachments, inconsistent product descriptions, or references to documents that were not provided. Where samples or mock-ups are required, track their status and evidence separately if the project process treats them as distinct review items.
Do not decide that a technical document is acceptable merely because it is present. The authorised technical reviewer must assess it against the applicable project requirements. The register review records whether required evidence was received and what the recorded review outcome is; it does not replace the technical evaluation.
4. Make status and responsibility unambiguous
Check that every active entry has a clear review status consistent with the project’s defined status vocabulary. Confirm what each status means in the governing procedure; labels such as “submitted,” “under review,” “revise,” or “approved” should not be assumed to have universal contractual meaning. Avoid using a blank cell, colour alone, or informal note as the only indication of status.
Record the responsible reviewer or reviewing organisation and, where the process requires it, the party that must act next. Verify that the named reviewer matches the project’s assigned review route. If responsibility is unknown, disputed, or awaiting assignment, show that as an open action rather than implying that review is underway.
Check the submission date, review due date, response date, and next action where these fields are part of the project register. Confirm dates against the transmittal or document-control record. Do not invent a review duration: use the period defined by the contract or project procedure, and flag any missing or conflicting basis for a due date.
5. Record the disposition and comments accurately
For a completed review, verify that the register disposition matches the formal response or approved review record. Capture or link the response reference, date, revision, and relevant comments as the project process requires. If comments require resubmission or further action, identify the responsible party and track the next submission or response without presenting the item as closed.
Distinguish a review response from later actions such as sample acceptance, procurement release, installation inspection, or final handover. These may be related but are not automatically the same decision. A register should not imply that a material is cleared for a later activity unless the applicable project process and documented decision support that conclusion.
When a response is unclear, inconsistent with the current submission, or not traceable to an authorised record, leave the status unresolved and seek clarification through the project’s document-control or technical review process. Preserve the source response rather than paraphrasing away qualifications.
6. Connect the register to procurement and programme dependencies
Review whether the register identifies procurement or programme links that the project team actually tracks. These may include a required-on-site date, purchase or fabrication dependency, sample decision, or another milestone recorded in approved project information. Confirm the basis and owner for each dependency with the responsible project team; a register date alone is not proof of a procurement commitment.
Flag items with outstanding technical information or review decisions when the project team identifies a procurement or sequencing dependency. Record the known impact and the person responsible for confirming it. Do not state that a delay will occur, or assign a quantified effect, unless supported by current project evidence. Where the register and programme disagree, identify the discrepancy and refer it to the responsible controls or procurement team.
Related programme information can help teams discuss timing, but a programme record does not itself establish a material’s technical approval. Keep the approval record and procurement or schedule status distinct, while linking them where the project’s controls require it.
7. Track actions, exceptions, and closure evidence
Use an action or exception record for missing documents, conflicting references, overdue responses, unclear ownership, incomplete samples, or other unresolved conditions. Give each issue a traceable reference, concise description, responsible owner, target date where established by the project, and current status. Link the closure evidence when the issue is resolved. If no target date has been agreed, show that rather than making one up.
Define what “closed” means for the register item under the project procedure. Check that the required submission, response, revised documents, comments, and any applicable sample or supporting record are linked or referenced. A status change without a supporting decision or closure record is not a reliable closeout trail.
Before issuing a register update, reconcile changes against the previous controlled revision. Check that new items, revised descriptions, status changes, response dates, and closures are visible and traceable under the project’s document-control process. Retain the appropriate issue record and supporting evidence as required by the project.
Practical register review checklist
- The project scope, reporting date, register revision, and controlled source are clear.
- Each entry has a traceable identifier, description, package or location, and applicable source reference.
- The submitted package and its revision can be matched to a controlled transmittal or document record.
- Required technical documents, samples, or other evidence are checked against project-specific requirements.
- Review status, responsible reviewer, submission date, due date, and next action are clear where required.
- The recorded disposition agrees with the formal response and does not imply an unsupported approval.
- Procurement or programme dependencies are linked to verified project information and have an owner.
- Exceptions and unresolved actions have traceable status and closure evidence.
- Register changes and closeout records remain auditable under the project’s document-control process.
Related EngineersBlog reading
- Primavera P6 Programme Update: Controlled Workflow and Review Checks
- Material Submittal for Approval
- Material Submittal and Pod Mock up
- Tender Drawings vs IFC Drawings: Differences, Uses and Approval Checks
Research and source context
The FHWA construction resource provides construction context; it does not establish requirements for a particular project’s material submittals. The related EngineersBlog pages are reading context, not proof of project-specific acceptance criteria. Apply the contract and approved project records for those decisions.
- FHWA Construction Team – Construction – Federal Highway Administration
- Creating Helpful, Reliable, People-First Content | Google Search Central
Conclusion
A useful material submittal register review checks identity, required evidence, technical review status, ownership, dates, disposition, procurement dependencies, and closeout records as connected but distinct parts of the workflow. Make gaps visible, preserve the link to controlled source documents, and use the project’s authorised review process for technical decisions. That keeps tracking practical without turning a general checklist into an unsupported project approval.
