RFIs, Submittals, and Change Orders: The Paper Trail That Actually Protects You

RFIs, submittals, and change orders get used loosely on a jobsite, sometimes as if they're interchangeable paperwork for "something changed." They're not. Each one does a specific job, and most payment disputes trace back to one of the three being late, vague, or skipped entirely under the assumption that everyone already agreed verbally.

An RFI Asks a Question. That's the Whole Job.

A Request for Information exists to resolve something unclear or missing in the design before work proceeds on it, a dimension that doesn't match between two drawings, a detail that's missing entirely. An RFI doesn't authorize anything and doesn't change the contract. It just gets an answer on record, with a date sent and a date answered. A verbal clarification from the architect during a site walk isn't a substitute, because six months later nobody can prove it happened.

A Submittal Proves You're Building What Was Specified

Submittals, product data sheets, shop drawings, samples, exist to prove that what's about to be fabricated or installed actually matches what was specified. They need approval before that work happens, not after. Installing material on a submittal that's still pending is a real financial exposure: if it gets rejected after it's in the wall, the cost of removing and replacing it is very hard to argue your way out of.

A Change Order Is the Only Document That Actually Changes the Contract

Of the three, only a change order actually changes price or scope. A superintendent saying "yeah, go ahead and do it" in the field is not a change order, no matter how reasonable it sounded at the time. The price and the scope aren't officially different until the change order itself is signed, and work performed on a verbal promise is work performed at your own financial risk.

Where the Three Actually Connect

On a real job, these documents often form a chain. An RFI reveals a design gap. The architect's answer implies scope that wasn't in the original contract. That new scope needs a change order before anyone builds it, and the new scope might need its own submittal if it involves a different product. Breaking any link in that chain, building the implied scope straight from the RFI answer, for instance, is exactly how a contractor ends up doing extra work for free.

What a Clean Log Actually Looks Like

• →Every RFI has a date sent, a date due, and a date answered, not just a date sent.
• →Every submittal shows pending, approved, or rejected, with the actual date it changed status.
• →No work starts on a changed scope until the change order itself is signed, not just verbally agreed.
• →One person, not everyone, owns updating this log, so it doesn't go stale.

None of this is about generating more paperwork for its own sake. It's about making sure the paperwork that already exists actually says what happened, in the order it happened, so nobody's arguing from memory six months later.