Both documents move between the field and the design team. Both get logged, tracked, and turned around on a deadline. It's no surprise that "RFI" and "submittal" get used interchangeably on some job sites — but they exist to solve two almost opposite problems, and mixing them up costs time in both directions.
The Short Version
| Submittal | RFI | |
|---|---|---|
| Direction of information | Contractor → Design team | Contractor → Design team, asking for an answer back |
| Purpose | "Here is exactly what I intend to install — please confirm it matches the design." | "The documents are unclear, contradictory, or silent on this — please clarify." |
| Triggered by | The spec section's submittal requirements | An ambiguity, conflict, or missing detail discovered in the field or during drafting |
| Typical response | Approved / Approved as Noted / Revise and Resubmit / Rejected | A written answer, sometimes with a sketch or a reference to the correct detail |
Submittals: Confirming What You'll Install
A submittal is proactive documentation. The spec already tells you what's required — a submittal is how you prove, before you buy or fabricate anything, that what you're planning to install actually satisfies that requirement. It's a one-way confirmation loop: you propose, the architect or engineer stamps it, and (assuming approval) that becomes the reference for what gets built.
RFIs: Resolving What the Documents Don't Say
An RFI exists because the drawings and specs are never perfectly complete — a dimension is missing, two details contradict each other, or an existing condition in the field doesn't match what's shown. An RFI is a formal question, not a proposal: it asks the design team to resolve the ambiguity so work can proceed correctly, and it usually needs an answer faster than a submittal does, because field crews are often waiting on it.
A Simple Way to Tell Them Apart
If you already know the answer and just need it confirmed, it's a submittal. If you genuinely don't know the answer and need the design team to tell you, it's an RFI.
Where They Overlap in Practice
The two aren't always separate events. A submittal review sometimes surfaces an RFI — the reviewer marks a shop drawing "Revise and Resubmit" and adds a comment that reveals a conflict the drafter had no way to know about without the design team's input, which itself gets tracked as an RFI. And an RFI answer can change what needs to go into a submittal — if the RFI response swaps a detail, the submittal has to be redrawn to match it before it goes back out for approval.
Keeping the two logs separate — even when they're related to the same issue — matters for schedule tracking. A submittal log measures "is our product approved yet." An RFI log measures "are there still unresolved questions blocking the design." Mixing them into one undifferentiated pile makes both harder to manage.
Why This Distinction Matters for Your Schedule
Treating an RFI like a submittal (waiting on the normal submittal review cycle for something that's actually blocking the field) stalls work that didn't need to stop. Treating a submittal like an RFI (assuming a quick verbal answer is enough) skips the formal approval record you need if a dispute comes up later about what was actually authorized. Knowing which document you need, and routing it correctly, keeps both processes moving at the speed they're each designed for.
We Handle Both, So Nothing Falls Through the Cracks
Beyond compiling submittal packages, we also draft, send, and follow up on RFIs for subcontractors who'd rather have someone else own that paperwork — flagging genuine ambiguities as RFIs instead of trying to force an answer into a submittal package where it doesn't belong.
Have a stack of submittals and open questions piling up?
Send us your spec book and drawings index. We'll sort what needs a submittal from what needs an RFI, and handle both.
Get a Flat-Rate Quote in 48–72h