What Real Submittal Logs Say About Resubmittal Rates

Every number you've read about submittal rejection rates came from a survey. Somebody asked contractors what their rejection rate was, contractors estimated, and the estimate became an industry statistic with a decimal point on it. I've never found that convincing, because I keep submittal logs, and my logs disagree with my own gut estimates every time I check.

So here's the other kind of number. My integration firm has run roughly 700 projects. I pulled thirteen of our project submittal logs, spanning 2022 through 2026, small jobs and monsters alike, and counted. Not what we remembered. What the log rows say.

The headline numbers

Across the thirteen logs: 387 packages issued. Of the 358 that have a decided review result so far, 91 came back for resubmittal. That's one in four.

Review turnaround, measured from date sent to date returned across 322 dated pairs: 21 days median, 32.5 days mean, and a quarter of all reviews took longer than 41 days. The mean sits well above the median because the tail is long; a package can sit for months when a reviewer's queue backs up or a holiday lands wrong.

Sit with that pairing for a second, because it's the whole schedule story. A resubmittal doesn't cost you the rework hours. It costs the rework hours plus another trip through a three-week median review queue. One bounced package is a month of calendar, minimum, on whatever that package was gating. Procurement usually waits on approval, so the month lands on equipment lead times too.

The spread matters more than the average

The one-in-four figure hides how lumpy this is, 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 decided packages came back. Same company, same people, same templates.
• The biggest: a multi-site job running since 2022, 263 issuances and counting, 58 of them resubmittals. About one package in five on that job has needed at least a second trip, and a few needed a third. Five years in, it's still generating log rows.

Same integrator, wildly different rates. Which tells you the rate isn't mostly a property of the contractor. It's a property of the job: how clean the spec is, how the reviewing engineer works, how much of the scope is familiar, how many parallel sites multiply every small confusion. Any single-number industry benchmark flattens exactly the variation that decides your schedule.

Two honesty notes on the counting. First, a "resubmit" row isn't always a failure; some of ours are a reviewer asking for a confirming copy after minor comments, which costs a cycle but not much rework. Second, 29 issuances in these logs have no decided result yet, some because they're recent, some because a response simply never came back and nobody chased it. Both patterns will be in your log too.

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 resubmittal rate was maybe one in ten. It's one in four. If you run projects, your gut number is probably wrong in the same comfortable direction. The fix costs one afternoon: your log already has the numbering and the results if you've been keeping it; count last year.

We spend the review hour before the engineer does. A quarter of packages bouncing means the cheapest schedule insurance available is reviewing your own package against the spec before it goes out: every demanded item present, every catalog number marked, every constrained value provable. An hour of self-review against a month of calendar is not a close call.

We ask instead of betting. Some of those resubmittals were interpretation bets that lost: the spec was ambiguous, we picked a reading, the reviewer picked the other one. An RFI asked early is a week; a bet lost in review is a month.

We plan reviews at three weeks, not "a few days." The median is 21 days. Baseline it in the schedule, chase what goes quiet past it, and treat the response obligations as work to route the day the package comes back, not paper to file.

Count your own

Your rate is knowable this afternoon and it's worth more than any benchmark, mine included. Pull last year's logs and count four things: packages issued, packages returned for resubmittal, days from sent to returned, and packages that never got an answer at all. Whatever the numbers are, they'll tell you where next year's month of schedule is hiding.

Disclosure: I build Submittal Kit, and these thirteen logs are the numbers behind the defaults in our cost worksheet, which does this arithmetic with your figures instead of mine. The counting itself needs nothing but your log and an honest afternoon.