A submittal review is the formal process by which contractors, suppliers, and design consultants submit technical documents — shop drawings, product data, samples, method statements, design deliverables — for review and approval before work proceeds. It is the quality gate between "designed" and "built": approve the wrong pump datasheet or fabrication drawing and the error gets poured in concrete.
This guide walks through the standard process, the review codes used across the industry, typical turnaround expectations, and the points where submittal reviews most often break down.
1. Preparation and transmittal. The submitting party assembles the package — document, revision, references — and transmits it with a unique submittal number. Incomplete packages are the first common failure: reviews start, stall, and restart when missing information surfaces mid-review.
2. Logging and distribution. The receiving side's document controller logs the submittal and distributes it to the disciplines that must review it. On multi-discipline packages, parallel review is where version confusion begins — three reviewers, three marked-up copies, one consolidation problem.
3. Review and comment. Each reviewer checks the submittal against contract documents, specifications, and applicable codes, and records comments. Serious teams record comments in a comment resolution sheet rather than loose PDF markups, so each comment has an ID, an owner, and a status.
4. Consolidation and return. Comments are consolidated, a review code is assigned, and the package is returned. The most common code sets look like this:
| Code | Typical Meaning | What the Submitter Does |
|---|---|---|
| A / Code 1 | Approved / No comments | Proceed with work |
| B / Code 2 | Approved with comments | Proceed, incorporating comments; resubmit for record |
| C / Code 3 | Revise and resubmit | Do not proceed; address comments and resubmit |
| D / Code 4 | Rejected | Do not proceed; fundamental issues |
5. Resolution and resubmission. For B and C codes, the submitter responds to each comment and issues a new revision. Open comments must carry forward — a comment answered in Rev B but never verified in Rev C is a comment lost, and lost comments are how rework happens. We quantify that risk in How to Reduce Costly Rework and Claims in EPC Projects.
6. Close-out. When all comments are closed and the code is A or B, the submittal is approved and archived with its full comment history as the audit record.
Contracts commonly allow 10 to 21 calendar days per review cycle. The real schedule killer is not the review duration — it is the number of cycles. A package that takes three C-coded round trips consumes two months even when everyone hits their deadlines. Cutting one review cycle out of each major package is usually worth more than compressing any single review; see our framework for faster engineering design reviews.
Every one of these is a workflow problem, not a people problem — the fixes are structural, and we detail them in 10 Reasons Your Engineering Design Review Workflow Isn't Working.
Contrat.io was built for exactly this process: submittals reviewed in one shared workspace, every comment tracked with an ID and role-based status, open comments carried automatically into the next revision, and automatic reminders on review deadlines. The full comment history becomes your defensible record at close-out. You can try it free for 30 days — no credit card required.