# What Approved as Noted Actually Requires You to Do

The review stamps on a returned submittal, what each one obligates the integrator to do next, and the follow-through that keeps the approval meaningful.

The package comes back. There's a stamp on it. Now what?

Every firm words its stamp a little differently, but the outcomes fall into a canonical set, and each one carries a specific obligation. Getting this wrong in either direction hurts: treat "Approved as Noted" as a clean approval and you build in the reviewer's uncorrected comments; treat it as a rejection and you burn a review cycle nobody asked for.

## The stamps, and what each one means

**Approved** (some firms: *No Exceptions Taken*, *Reviewed*). Proceed. Order the equipment, release the drawings for fabrication. File the returned copy in the log, because this stamp is the thing you'll point at later if anyone questions the equipment selection.

**Approved as Noted** (*Make Corrections Noted*, *Furnish as Corrected*). Proceed **and** incorporate every comment. This is the one that gets mishandled, so it gets its own section below.

**Revise and Resubmit**. Do not proceed on the commented items. Fix the package and issue the next revision. The clock this consumes is the reason to review your own package before the engineer does: each cycle typically costs two to four weeks of calendar, and procurement is usually waiting on it.

**Rejected**. The proposed equipment or approach doesn't meet the spec, full stop. Usually this means a substitution the engineer declined or a fundamental misread of the requirement. Before resubmitting, get on the phone; resubmitting a rejected package without a conversation is how you collect a second rejection.

**For Information Only** (*Record Copy*). No review performed, no approval granted. Note it in the log and understand clearly that nothing about this stamp protects you.

## Approved as Noted, in practice

The stamp says two things at once: *your package is close enough that we won't make you resubmit*, and *you are now contractually expected to do everything written in the margins*. The comments are not suggestions. They're conditions of the approval.

The follow-through that keeps you safe:

1. **Read every comment, on every page.** Comments hide on page 47 of a returned PDF. Someone whose job it is has to page through the whole returned document, not just the stamp page.
2. **Log the response and keep the returned copy.** The marked-up document the engineer sent back is part of the project record. Attach it to the revision it answers, with the response date. When a dispute surfaces two years later, "what did the engineer's markup actually say" is a question you want to answer in thirty seconds from the log, not never.
3. **Push each comment to the person it affects.** A comment about wire labeling goes to the panel shop. A comment substituting a part goes to purchasing *before the PO cuts*. This handoff is where Approved as Noted most often fails: the stamp gets celebrated, the PDF gets filed, and the comments reach nobody who could act on them.
4. **Decide whether any comment changes scope or contradicts the spec.** Sometimes a "note" quietly asks for something the contract never included. That's not a submittal comment, that's a change, and it should route through your change process with a price and schedule impact before you build it. And a comment that conflicts with the spec itself deserves an RFI before you build on it; see [submittal versus RFI](/learn/submittal-vs-rfi). Absorbing scope through submittal comments is a slow leak that shows up at the end of the job as margin you can't find.
5. **Confirm whether a conformed copy is required.** Some specs want a corrected resubmission for record even after Approved as Noted. The spec's submittal article says; read it rather than assuming.

## The log is what makes any of this real

Every returned submittal, whatever the stamp, produces the same three records: the response, the date, and the returned marked-up copy, attached to the exact revision that went out. Kept diligently, this log answers the questions that otherwise turn into arguments: which revision was approved, when did review actually take, what did we change between Rev 1 and Rev 2 and why.

It also gives you something most integrators never see: their own numbers. Count the packages that came back Revise and Resubmit last year, multiply by the hours a resubmittal cycle costs you, and you have the honest cost of sending packages out unreviewed. (I did this count against my own firm's logs; the results are in [what real submittal logs say about resubmittal rates](/learn/submittal-resubmittal-rates).) Most shops that do this arithmetic change how they prepare packages; the self-review pass in [what goes in a control system submittal package](/learn/control-system-submittal-package) is where the improvement comes from. And a log is only as good as its numbering, which is its own craft: see [submittal numbering and revision schemes](/learn/submittal-numbering-revision-schemes).

*Disclosure: I build [Submittal Kit](/), which keeps the submittal log this way: every issued revision frozen byte for byte, with the response, date, and returned markup attached. The obligations in this article are yours regardless of tooling.*

---
Submittal Kit · Learn · Updated 2026-08-17
Canonical: https://submittalkit.com/learn/approved-as-noted