Skip to main content

What Thirteen Submittal Logs Taught Me About Resubmittal Rates

What 387 issuance rows from thirteen project logs say about resubmittals, review time and the danger of planning from one tidy average.

I keep submittal logs, and my logs disagree with my own gut estimates every time I check. So here is the other kind of number: not what we remembered, but what the rows say.

The integrator where I run projects has handled roughly 700 of them. For this pass I pulled thirteen logs available for review, spanning 2022 through 2026, and counted what was sent and what came back. The logs are a convenience sample, not a random sample of our work or the industry. Project and customer names are omitted. One large, multi-site job contributes 263 of the 387 issuance rows, so it has a heavy hand in the totals.

I counted an issuance each time a revision was sent and received its own log row. A subject package can therefore appear more than once when it is revised and reissued. The counts below describe those issuance rows, not 387 distinct equipment packages or 387 projects.

The headline numbers

Across the thirteen logs there are 387 issuance rows. Of the 358 with a decided review result, 91 have a resubmittal disposition. That's 25.4 percent, or about one in four. The other 29 had no decided result in the data reviewed.

Review turnaround is available for 322 rows with both a sent date and a returned date: 21 days median and 32.5 days mean. Within those 322 dated pairs, one quarter took longer than 41 days. The mean sits above the median because the sample has a long tail.

That pairing is the schedule story in this sample. A resubmittal meant rework plus another pass through a review process whose median was three weeks. Where purchasing waited for an accepted selection, that second trip sat in front of the order date too. Your next project will have its own review clock, but pretending the second trip takes no calendar time is not a plan.

The spread matters more than the average

The one-in-four figure hides how lumpy the thirteen logs are, and the lumpiness is the useful part.

  • The cleanest log in the set: seven packages issued, seven approved, zero resubmittals. Small scope, one reviewer, familiar equipment.
  • The roughest: more than half of its decided issuance rows came back for another pass.
  • The biggest: a multi-site job running since 2022, with 263 issuance rows in this extract and 58 resubmittal dispositions. It supplies about 68 percent of every row counted here.

Same integrator, very different rates. The logs do not isolate why. Project scope, document quality, reviewer practice, package complexity and counting choices may all contribute. The total describes these thirteen logs; it is not an industry benchmark or a forecast for your next job.

Two more honesty notes. A resubmittal disposition does not measure severity: a confirming copy after minor comments and a rejected selection both count as another cycle. And the 29 rows without a decided result are excluded from the 91-of-358 rate. The logs did not classify the reasons consistently, so this review does not assign them afterward.

What the numbers changed about how we work

We stopped trusting memory and started reading the log. Before counting, I'd have told you our share was maybe one in ten. In this sample it is one in four. If your numbering and results are consistent, your own answer is already sitting in the rows.

We spend the review time before the engineer does. One avoidable bounce has to make another trip through the queue. We review each package against its project requirements before it goes out: required items present, catalog numbers identified and constrained values supported.

We ask instead of betting. When the documents are ambiguous, an RFI asked before the package can settle the interpretation before the selection and its evidence are built around it.

We plan these projects from their measured review time. The 21-day sample median is more useful here than “a few days.” Your own log and the project's stated review period should set your baseline. When the package comes back, route the stamp and comments instead of treating them as paper to file.

Count your own

Your own rate is knowable in an afternoon and worth more than mine. Define the unit first: distinct subject packages, individual issuances or first-review outcomes. Then count the total in that unit, the decided outcomes, the resubmittal dispositions, the dated sent-returned pairs and the unresolved rows. Keep the denominator beside every percentage. Otherwise a revision-heavy job quietly turns into a claim the data never made.

How Submittal Kit handles this

Counting your own rate is straightforward when the log already holds the dates and dispositions, and painful when it has to be rebuilt from sent mail. The Submittal Log in Submittal Kit keeps every revision with its submitted and returned dates and review outcome, and a running day count flags work that passes its expected return date. Export the log to XLSX when you want to state your unit, filter the rows and keep the denominator with the result. The thirteen-log sample supplies defaults in the cost worksheet, which you can replace with your own package count, hours and resubmittal share. See Submittal log.

Disclosure: I build Submittal Kit, and the counting itself needs nothing but your log and an honest afternoon.

Where this lives in Submittal Kit

Want to see your BOM become a reviewable package?

Bring a CSV or Excel BOM, or use a demo project. You'll see the proposed matches before anything changes and review the compiled PDF before issue.

Book a walkthrough