A file called “final.pdf” is not enough. Give every item a stable register ID, preserve each revision and response, and make the current action owner visible.
1. Set the register basis
Build the required-document list from the project specification, purchase order and agreed review route. A document type appearing below is an example, not a universal requirement.
2. List what is required before chasing files
| Register ID | Document type / description | Requirement source | Issuer | Reviewer | Required by / purpose |
|---|---|---|---|---|---|
| SUB-001 | Layout / shop drawing | Spec / PO ______ | ________ | ________ | Review / record / other |
| SUB-002 | Product data sheet | Spec / PO ______ | ________ | ________ | Review / record / other |
| SUB-003 | Test report / certificate, if required | Spec / PO ______ | ________ | ________ | Review / record / other |
| SUB-004 | Packing / origin / shipping document | Spec / PO ______ | ________ | ________ | Review / record / other |
Write the clause, drawing, purchase-order line or agreed schedule that creates the requirement. If no source is found, mark “confirm requirement” instead of presenting the document as mandatory.
3. Track submission, review and next action
| Register ID | File / document ID | Revision / issue date | Submitted / transmittal | Reviewer | Response / date | Next action / owner / due |
|---|---|---|---|---|---|---|
| ________ | ________ | Rev ___ / ______ | ________ | ________ | ________ | ________ |
| ________ | ________ | Rev ___ / ______ | ________ | ________ | ________ | ________ |
| ________ | ________ | Rev ___ / ______ | ________ | ________ | ________ | ________ |
Useful workflow states include “not requested,” “requested,” “received,” “under review,” “returned for revision,” “accepted for record,” “superseded” and “closed.” Use the project’s actual codes and record the formal response verbatim; never translate a reviewer’s response into stronger permission.
4. Preserve the revision chain
| Register ID | Revision | Change / comment reference | Submitted date | Response | Superseded by | File location |
|---|---|---|---|---|---|---|
| ________ | ________ | ________ | ________ | ________ | ________ | ________ |
| ________ | ________ | ________ | ________ | ________ | ________ | ________ |
| ________ | ________ | ________ | ________ | ________ | ________ | ________ |
Do not delete an earlier row when a revision arrives. Mark it superseded, link the replacement and keep the original response with the exact file it reviewed. The project change log should carry any approved change that affects the required document or product basis.
5. Close comments and distribute the current file
Before closing, confirm that the reviewer response, current revision and distributed file all carry the same register ID. Route current shipping and packing records into the delivery receiving checklist.
Questions buyers ask
What is a document submittal register?
It is an index of required and received project documents showing stable IDs, current revisions, issuers, reviewers, dates, responses, next actions and superseded files.
Which fence documents should be included?
Only documents required by the project specification, quotation, purchase order or agreed schedule. Depending on the job, that may include drawings, product data, samples, test reports, certificates, instructions, packing records or closeout information.
Does “received” mean approved?
No. “Received” records delivery to the process. Review disposition, technical acceptance and permission to proceed are separate decisions made by the authority named in the project documents.
How should revised files be named?
Use the project naming rule and include a stable document ID plus a revision or issue identifier that distinguishes each version. Avoid relying on filenames such as “new,” “latest” or “final.”
Can an old revision be deleted?
Do not use this page to decide retention. Mark the old row superseded, link the replacement and follow the project’s contract, quality and records-retention rules.
Evidence and limits
The U.S. Army Corps of Engineers RMS manual displays register fields for section, item, description, dates, review codes, primary reviewer and status, plus transmittal history. The DoD UFGS submittal procedure groups submittals such as drawings, product data, samples, reports, certificates, instructions and closeout records, while requiring project tailoring. NIST document-control guidance uses a master list to identify current revisions and separates active from obsolete or superseded documents. These are transferable control patterns, not universal fence-document requirements or approval codes.
Supports a register that makes item identity, action ownership and review status visible.
WBDG / DoD: UFGS 01 33 00 Submittal types and project-specific procedureShows common document categories and why the governing specification must define the actual submission and review rules.
NIST: Document Control and Master Lists Current revision and superseded recordsSupports recording the issuing source, revision status and separation of active from obsolete documents.