Free Submittal Log Template With Real Examples

Quick answer: what should a submittal log include?

A useful submittal log template includes a unique ID, project and package name, specification section, item description, submitting party, responsible coordinator, planned and actual submission dates, reviewer, required response date, status, returned action, revision number, next step, and controlled-file link. Add dates as real calendar dates, update the log after each formal transmittal or response, and never mark an item approved unless the authorized reviewer’s written response says so.

What is a submittal log, and who uses it?

A submittal log is a register of the product data, shop drawings, samples, certificates, and other information that a project team expects to submit and review. It maps each requirement to an accountable sender and a review trail. Depending on the project, the general contractor, subcontractors, architect, engineer, owner, or a document controller may update or read it.

It is not the submittal itself, a substitute for a formal transmittal, or permission to buy, fabricate, or install. The project’s contract documents and authorized written review govern those decisions. Use the log to coordinate and identify gaps; refer users to the source documents for requirements and decisions.

A log is most useful when many packages have different lead times or reviewers. For example, a lighting fixture may need product data and a sample, while a structural steel package may include drawings, calculations, and certifications. Listing both as “materials” hides their different review paths. Give each package a clear scope and split it into linked line items when separate decisions or dates matter.

What fields belong in a submittal log template?

Start with fields that answer five questions: What is required? Who owns it? When is it needed? Where is it in review? What happens next? The table below provides a practical baseline; adapt names to the project’s document platform and agreed workflow.

Add fields only when they answer a real coordination need. Useful optional columns include procurement status, long-lead flag, related predecessor submittal, sample location, required approval level, and closeout document requirement. Avoid copying sensitive personal information into a broad register. If the team uses separate systems, designate one as the record of authority and link to it rather than maintaining competing versions.

Which dates should you track?

Separate forecast dates from actual dates. “Planned submission” is a commitment or current forecast; “actual transmittal” is the date recorded by the formal system. “Required-on-site” is a schedule need, not a review deadline. A “response target” is a coordination date agreed by the team; it is not necessarily a contractual deadline. Label each date clearly and use the project’s agreed calendar and time zone.

Record changed forecasts instead of silently overwriting history. At minimum, retain the latest forecast and note the date and reason it changed. Where schedule impact is material, link the related schedule item and raise the issue through the project’s normal process. Do not calculate an “approval due date” from an assumed review period unless the responsible parties have confirmed the rule.

How do you create and maintain the log?

A spreadsheet works for a small project with one editor and a manageable number of packages. A document-control or project-management platform is more appropriate when multiple teams need permissions, revision history, automated reminders, or audit trails. Either way, consistency is more important than a sophisticated tool.

1. Build the register from requirements. Review the project’s specification, drawings, submittal schedule, procurement plan, and applicable project procedures. Capture each required package and identify missing or unclear requirements for the responsible team to resolve. Do not invent a requirement based on a generic template.
2. Set identifiers and ownership. Use an agreed numbering convention, such as discipline-prefix plus sequence (M-042). Assign one coordinator for each line and one register administrator. A person may have multiple duties, but each package needs a clear accountable owner.
3. Plan backward from the work need. Enter the required-on-site date, then coordinate procurement, preparation, and review forecasts with the responsible parties. Flag long-lead or schedule-sensitive items. This is planning, not a guarantee that a reviewer will respond by a forecast date.
4. Check the package before sending. Confirm the scope, references, required documents, revision, and transmittal details against project requirements. The sender remains responsible for completeness. A log status should not imply that a package has been technically checked unless it has.
5. Record the formal transmission. Enter the actual date, transmittal number, revision, recipient, and controlled-file link. Keep the submitted file unchanged in the record system. If a package is withdrawn or superseded, preserve the history and clearly identify the current version.
6. Update from written responses. Capture the response date, exact disposition, reviewer comments location, and next action. Summarize only; do not paraphrase a conditional decision in a way that changes its meaning. Link to the signed or otherwise official response.
7. Manage resubmittals as new cycles. Keep the parent ID, increment the revision or cycle, record the revised submission date, and link the prior response. Confirm whether a full package or only identified corrections are expected through the project’s established process.
8. Review the log routinely. At a weekly coordination meeting, filter for overdue actions, items needed soon, packages awaiting review, and items blocking procurement or work. Record an owner and next check date for each exception.
9. Close and archive. Confirm that final accepted/current records are stored as required, obsolete versions are identifiable, and required closeout documents are accounted for. Follow the project’s document-retention procedures.

Which statuses make the workflow clear?

Agree on a short, mutually understood set of statuses. Status labels describe workflow state; they do not create contractual meaning or replace the reviewer’s written disposition. A practical set is:

Teams sometimes use “approved,” “approved as noted,” or “revise and resubmit.” Only use a disposition label that matches the actual response terminology and the project’s established conventions. Avoid vague labels such as “done,” “OK,” or “pending” without a next action. An item with no response is still awaiting response; it is not approved by default.

How should reviewer comments, revisions, and approvals be recorded?

Store reviewer comments with the official response, not solely in a free-text log cell. In the register, record the response date, disposition exactly as stated, response document ID, and a concise action summary. Identify who must act, what deliverable changes, and when the team will check progress. If comments conflict or are unclear, ask the designated project contact for clarification through the official channel rather than guessing.

Use a revision scheme agreed by the project. For example, the first issue might be “Rev 0,” followed by “Rev 1” after corrections. The exact convention varies; the important controls are that every issue is identifiable, the current version is obvious, and previous records remain available. Never replace a file in place if doing so erases what was actually reviewed. File names can include project, ID, revision, and date, such as `PRJ-M-042-Rev1-20260624.pdf`, provided the naming rule is consistent.

A reviewer’s response can contain qualifications, limitations, or coordination notes. Preserve the complete response and make the log’s summary point back to it. Do not convert a conditional response into an unconditional “approved” entry. Likewise, do not treat a vendor’s statement, meeting comment, or unanswered email as formal acceptance unless the project’s authorized process says it is valid.

How do you handle overdue submittals and escalation?

Define escalation before the first overdue item: who follows up, when, through which channel, and who decides whether schedule impact needs leadership attention. Use a transparent rule tied to the project’s agreed response target and work need. For example, a team might flag a response target that has passed, have the coordinator verify receipt and status the next business day, and notify the project manager if the item threatens a dated procurement or installation milestone. This is an example workflow, not a universal deadline.

For an overdue submission, contact the responsible submitter, confirm what is missing, agree on a realistic recovery date, and update the forecast with a brief reason. For a pending review, confirm delivery and ask the reviewer or project contact for an updated response forecast; identify any schedule consequence factually. If an item is critical, raise it through the designated project escalation path rather than repeatedly changing the date or marking the status green.

An exception report can show: ID, description, status, days past the agreed target (if the project has defined how to calculate it), required-on-site date, schedule relationship, owner, last contact, next action, and escalation owner. Keep the report focused on decisions needed. Do not imply that a missed forecast automatically changes anyone’s contractual obligations.

What does a completed submittal log look like?

Here are illustrative sample rows. Names, dates, IDs, and responses are fictional examples to show the format, not actual project records or instructions for a specific contract.

In the first row, the team can see that the review response exists, the package needs another issue, and a specific party owns the next action. The entry does not attempt to interpret whether work may proceed; the official response and project requirements determine that. In the second row, the disposition is summarized but the response itself remains linked. The third row is explicitly a forecast and is not falsely represented as submitted.

Who owns each part of the process?

Role clarity prevents the register from becoming a shared responsibility that nobody maintains. A simple responsibility model might look like this:

• Subcontractor or supplier coordinator: prepares and transmits the package, checks it against stated requirements, responds to comments, and provides updated files.
• General contractor or project coordinator: maintains the consolidated log, checks completeness of tracking fields, coordinates dates, sends follow-ups, and reports exceptions.
• Design reviewer or consultant: reviews through the designated channel and issues a documented response within the process assigned to that role.
• Project manager: resolves coordination priorities, assigns escalation, and brings schedule risks to the appropriate parties.
• Document controller: manages naming, access, transmittal records, version history, and archiving where that role exists.

One person may fill more than one role on a small project. Name the owner at the line-item level anyway, and identify the person who can update the register when the primary owner is away. Keep access appropriate: broad read access can improve coordination, while edit access may be limited to trained register maintainers.

Spreadsheet, platform, or both: what should you choose?

A spreadsheet has a low setup cost and is easy to filter, but concurrent editing, reminders, permissions, and history can become difficult as the project grows. A document-control or project-management platform can connect files, transmittals, and tasks and preserve an audit trail, but it requires setup, training, and disciplined use. A hybrid can work if the team defines the authoritative record and avoids duplicate manual updates.

Choose based on the project’s procedures, number of contributors, traceability needs, and tool access—not on feature count alone. Pilot the fields with a few real packages, ask the people who submit and review them what is missing, then adjust before scaling up.

Common submittal log mistakes to avoid

1. Treating an empty response field as acceptance. A blank means the register has no recorded response. Follow up using the agreed process.
2. Combining unrelated items into one line. Separate packages when reviewers, due dates, or decisions differ; otherwise one item can conceal another’s delay.
3. Overwriting dates and revisions. Keep enough history to explain what was sent and when. Preserve superseded records according to the project’s controls.
4. Using an ambiguous status. Define labels and pair every open item with a named owner and next action.
5. Recording a paraphrase as the official decision. Link and preserve the reviewer’s actual response, including notes and conditions.
6. Tracking only review dates, not work need. A response date has little context without a required-on-site date and schedule relationship.
7. Creating too many fields. A sprawling register is hard to maintain. Add columns only when an owner will use them to make a decision or complete a required control.
8. Keeping the only copy on someone’s desktop. Store the working register in an access-controlled shared location and establish backup and version-history expectations.
9. Failing to update after a transmittal. A package may be sent while the log still says “in preparation.” Make the update part of the transmittal routine.
10. Using the register to interpret contract requirements. The log supports coordination; route questions about obligations, acceptance, or permission to proceed to the responsible project personnel and governing documents.

How can you implement the template in one working session?

Begin with a short kickoff among the people who will submit, review, and maintain packages. Confirm the source documents, naming scheme, approved status labels, authoritative file location, owners, date definitions, and escalation contact. Then populate only the known requirements and mark uncertain items “to confirm” with a named owner and follow-up date. This is safer than filling gaps with assumptions.

Next, test the template with three different packages: a straightforward product-data package, a package that needs multiple components such as a sample plus data, and a schedule-sensitive item. Walk through a first submission, a return with comments, a resubmission, and closure. Ask whether an unfamiliar team member can answer, in under a minute, what the current version is, what action is due, who owns it, and where the response lives.

Finally, publish a brief instruction note with definitions and a real project contact. Set a recurring review cadence, create filters for overdue and near-term items, and agree how the register will be exported or archived at closeout. Review the process after the first few weeks. If a field is consistently unused, determine whether it is unnecessary or whether the workflow has not assigned anyone to maintain it. Do not remove a field that is required by project procedures simply because it is inconvenient.

A useful weekly review is not a column-by-column recital. Focus on exceptions: packages that are late against an agreed forecast, responses needed before a procurement decision, incomplete packages likely to cycle back, and upcoming work with no current submittal. For each exception, capture a decision, owner, and next check. This makes the log a practical coordination instrument instead of a passive archive.

Conclusion

A dependable submittal log makes requirements, owners, dates, responses, and next actions visible in one place while preserving the formal record elsewhere. Start with a small set of clearly defined fields, keep forecast and actual dates separate, use exact status meanings, and link every decision to its controlled response. Review exceptions regularly and escalate through the project’s agreed channels. The template only works when the team agrees how to maintain it—and when nobody mistakes a tracking entry for a formal approval.

SEO (Final Output)

• SEO Title: Free Submittal Log Template: Fields, Workflow & Examples
• Meta Description: Use this submittal log template to track package owners, dates, reviewer responses, revisions, overdue items, and real sample entries.
• URL Slug: submittal
• Primary Keyword: submittal log template
• Secondary Keywords: submittal register, construction submittal log, submittal tracking spreadsheet, submittal workflow
• Featured Snippet Suggestion: The “Quick answer” definition and required-fields list.
• Internal Linking Suggestion: Link to relevant project planning, document management, and project schedule resources where verified pages exist.
• Schema Suggestion: Article; FAQPage only if the site’s structured-data policy supports the visible FAQ.

Admin Actions (Manual Completion)

• Confirm the existing page’s featured image and add a descriptive alt text if needed.
• Verify internal links against live Doitify pages before adding them.
• Confirm article schema and visible FAQ markup follow current site policy.
• Validate the controlled submittal-log example against the project’s own process before applying it.

If this post on submittal log template was helpful, you might also enjoy How to Improve Project Visibility and Best Project Management Software for Client Work in 2026.