How to Track Submittal Revisions Without Losing Procurement Dates

Key takeaways
- A reliable submittal revision log uses five required fields: submittal number, revision number, review status, ball-in-court, and need-on-site date.
- Review status and ball-in-court should be tracked separately because the review result is not the same as the next responsible action.
- Need-on-site dates should set submittal priority so revision delays show up before procurement dates slip.
- One current live line per submittal item keeps the log usable and preserves revision control.
- Submittal problems often start at estimating handoff when long-lead assumptions and vendor dependencies are not carried into operations.
Track submittal revisions in one live log using five required fields: submittal number, revision number, review status, ball-in-court, and need-on-site date. Keep one current line per submittal item, update it when comments return, and use the need-on-site date to catch procurement risk before release dates slip.
That setup works in a spreadsheet or in a project-management platform because the control point is the workflow, not the software.
Use five required fields on every active submittal
The simplest reliable setup is one live line per submittal item with five required fields.
- Submittal number: the consistent identifier across transmittals, emails, meeting notes, and document folders.
- Revision number: the current review round, so the team does not act on an outdated package.
- Review status: the formal disposition of the current submission.
- Ball-in-court: the party responsible for the next action.
- Need-on-site date: the date that ties the submittal to installation sequence and material release timing.
You can add fields such as spec section, trade, package name, long-lead flag, or lead time. Do that only after the five core fields stay current.
Separate review status from ball-in-court
Review status records the formal result, and ball-in-court shows who acts next.
Those fields answer different questions:
- Review status answers: what happened in review?
- Ball-in-court answers: who must move it forward now?
Keep them separate or the log becomes hard to sort. Mixed status entries such as "waiting on vendor," "approved as noted," and "resubmit" in one column make it harder to see which items are blocked, which are complete, and which are simply waiting for the next step.
A few common examples:
- A submittal can be approved as noted, while ball-in-court moves to procurement for release.
- A submittal can be revise and resubmit, while ball-in-court moves to the vendor or trade partner to correct the package.
- A submittal can be approved, while ball-in-court moves to the field team for layout, release, or installation prep.
Update both fields on the same day the review comes back.
Let need-on-site dates set the submittal priority
Need-on-site dates should drive the submittal sequence because review delays matter only in relation to procurement and installation timing.
Start with the field requirement, then work backward:
- Set the need-on-site date from the schedule and installation sequence.
- Check the lead time needed before that date.
- Allow time for internal review, design review, comments, and resubmittal if the package is coordination-heavy.
- Set the target first-submit date from that sequence.
- Recheck the timeline every time the revision number changes.
This is where teams lose procurement dates. They update the revision, save the new PDF, and move on without asking whether the added review round consumed the float that protected fabrication or delivery.
For long-lead items, a resubmittal should trigger an immediate date check. If comments affect model selection, finish, dimensions, or supporting documentation, compare the revised timeline to the need-on-site date before the item falls behind release.
Keep one live line and archive prior rounds
One current line per submittal item is cleaner than a new active line for every review round.
When every revision becomes a live line, the log fills with duplicates, outdated comments stay visible beside current ones, and open-item reports become unreliable.
Use this rule instead:
- Create one active log line for each submittal item.
- When the first package is sent, assign the current revision number and set ball-in-court to the reviewer.
- When comments return, update the same line that day.
- If the item must be revised, increment the revision number and change ball-in-court to the next responsible party.
- If comments affect release timing, alert the procurement side immediately.
- Once the item clears review, move ball-in-court to the next owner, often procurement, fabrication coordination, or the field team.
Archive prior rounds in the document history or file structure using the same submittal number and clear revision labels. The live log should show the current answer. The archive should preserve the history.
Start the log at the estimating-to-operations handoff
Many submittal date problems begin before the first submittal is sent, during handoff from estimating to operations.
Tribuild Consultancy is a multi-trade estimating, preconstruction, and project-administration company.
If the estimate already identified a long-lead item, a vendor-dependent package, an allowance, or a pending selection, that information should reach the submittal log at turnover.
A useful handoff highlights:
- long-lead items that need early submittal priority
- quoted vendors and any assumptions tied to those quotes
- alternates, allowances, or pending selections that may change the final package
- scope clarifications that may affect what gets ordered
- items that require shop drawing coordination before release
- vendor-furnished, owner-furnished, and contractor-furnished scope splits that affect routing and timing
This is where pre-bid discipline carries into post-award control. Documents are prepared within the contractor's established review and approval workflow.
Pull one active project, sort open submittals by need-on-site date, and check whether every line shows a current revision number, review status, ball-in-court, and next procurement risk. If you want to review submittal or procurement workflows on an upcoming project, Tribuild can help structure that handoff and tracking process.
Frequently asked questions
Use five required fields: submittal number, revision number, review status, ball-in-court, and need-on-site date. Those fields show the current package, the formal review result, the next owner, and the schedule impact.
Usually no. Keep one current line for each submittal item, update the revision number as the item moves through review, and archive prior rounds in the document history or file structure.
Tie every submittal to a need-on-site date, work backward through review and lead time, and recheck the timeline every time a revision is added. If comments affect product selection or release timing, escalate that risk the same day.
It can work in either. A spreadsheet is usable if the fields are standardized and updated consistently. Software can improve routing and document control, but it does not replace a clear ownership and date-tracking process.
Written by
Ready to strengthen your next bid?
Tribuild handles your pre-construction workload (estimating, shop drawings, and submittals) so you can win more work.
Start a Free Trial Run