# Building the Submittal Register at Award How to build the submittal register in the first weeks after award: walking the spec book, one row per required submittal, dates from lead times, owners, and keeping it current. Six months into the job, the GC asks for your training plan. You did not know you owed one. It was in Part 1 of a section you skimmed in week one, listed under closeout submittals, due before startup, which is next month. Nothing went wrong except that the list of what you owe lived in your head, and your head had three other jobs in it. The submittal register fixes that. Built once, at award, it is the full list of everything the spec requires you to submit, with dates and owners. This article is how to build it: walking the spec, writing one row per submittal, setting dates from lead times, assigning owners, and keeping it alive. ## What the register is The register, or submittal schedule, is a list of every submittal the contract requires from you, planned before any of them exist. The submittal log is the same list, tracked after they go out: dates sent, dates returned, dispositions. On a small job they are one spreadsheet. The difference is timing. The register is a plan, written at award, and the log is the history of carrying it out. Many Division 01 submittal procedures sections require the contractor to submit a submittal schedule within a set number of days after notice to proceed, and some require it before the first payment application. The number of days varies by spec, so check yours; [reading 01 33 00](/learn/reading-01-33-00) covers where that requirement sits. On a job where you are a subcontractor, the GC usually builds the master register and asks each sub for its piece. Build yours anyway. The GC's version is often a copy of the spec's submittal paragraphs with no dates in them. ## Walk the spec book Start with the sections you own, which is usually fewer than you fear: your controls section, the instrumentation sections, any system integration or network section, and the parts of Division 26 your panels touch. [Which CSI divisions a controls integrator actually owns](/learn/csi-divisions-for-integrators) helps draw that line. For each section, read the whole Part 1 first, not only the article titled Submittals. Requirements hide in quality assurance, in closeout, in warranty, and in delivery and storage. Then skim Part 3 for tests, demonstrations, and training, which almost always produce submittals of their own. The reading order that catches the buried ones is in [how to read a spec section for submittal requirements](/learn/read-a-spec-section-for-submittals). Then read Division 01 once for the whole job: submittal procedures, quality requirements, closeout, O&M data, record documents, and demonstration and training. Those sections add submittals that apply to every trade, and they set the format and review times every row will use. Write down every deliverable as you find it, with the paragraph that requires it. The paragraph reference matters. When someone asks why a row exists, or argues that it does not, the answer is a citation, not a memory. ## One row per required submittal Granularity is the decision that makes or breaks the register. Too coarse, and "Section 40 61 13 submittals" hides eleven deliverables in one row. Too fine, and you have a row per datasheet. The right grain is one row per package that will travel under its own transmittal and come back with its own stamp. A row carries: - **Number.** In the format the spec or the GC requires. See [submittal numbering and revision schemes](/learn/submittal-numbering-revision-schemes). - **Spec section and paragraph.** The section number, title, and the paragraph that requires the submittal. - **Description.** What the package is: "PLC and I/O product data," "Control panel shop drawings, LCP-1 to LCP-4." - **Type.** Action, informational, or closeout. Action submittals need a stamp before you proceed; the others are reviewed for record or gate closeout. - **Responsible party.** Who produces the content: you, your panel shop, an instrument vendor, a programming subcontractor. - **Reviewer.** The engineer of record, the commissioning authority, the owner's IT group, or several. - **Lead time.** For product data that covers purchased equipment, the manufacturer's lead time after approval. - **Need-by.** When the approved item must be on site, in the shop, or in hand. - **Submit-by.** The date the package must go out, worked back from the need-by. - **Status and ball in court.** Filled in as the job runs. Group rows by when they come due, not only by section. Action submittals cluster early, test procedures in the middle, closeout at the end. A register sorted by section number hides the fact that eight of your packages are due the same week. ## Dates from lead times The submit-by date comes from arithmetic, not optimism. Work backward from when the material or document is needed: ``` Need-by (panel fabrication start) 2027-03-15 minus manufacturer lead time 14 weeks Order-by 2026-12-07 minus review time, per spec 3 weeks minus one resubmittal cycle allowance 3 weeks Submit-by 2026-10-26 minus time to assemble the package 2 weeks Start assembling 2026-10-12 ``` Use the review time the spec gives, not the one you hope for. Decide on purpose whether to allow time for a resubmittal on long-lead items. Leaving it out is a bet that the first submission will be approved. The full method, and which packages to send first when everything looks urgent, is in [sequencing submittals against lead times](/learn/sequencing-submittals-against-lead-times). Rows with no equipment, such as test procedures, training plans, and O&M manuals, get their dates from the project schedule instead. The spec usually ties them to a milestone: so many days before testing, before training, before substantial completion. Write the milestone on the row along with the date, so when the milestone moves you know which rows move with it. ## Owners Every row gets one named owner, a person and not a company. "Acme Controls" does not chase a vendor for a revised datasheet; a project engineer does. Where the content comes from a vendor or a sub, the row's owner is the person on your side responsible for getting it, and the register should show the date you need it from them, which is earlier than the submit-by date. Send each owner their rows with dates at the start. Nobody reads a 140-row spreadsheet to find their six. ## Keep it alive A register written at award and never touched again is worse than none, because people trust it. Things that change it: - **Addenda and bulletins.** Read each one for new or changed submittal requirements. - **RFI answers and change orders.** A design change can add a package, change one, or move its date. - **Schedule changes.** When the fabrication start moves, every row tied to it moves. - **Review outcomes.** A revise and resubmit adds a cycle and pushes the order-by date. If the item is long-lead, that is a schedule problem to raise now. - **Splits.** When you split a package to release a long-lead item early, the register gets a new row. Review it weekly, and before every coordination meeting sort it by submit-by date and by ball in court. The rows overdue on your side are the first thing to talk about, before anyone else brings them up. At closeout, the register is the checklist. Every row either has an approved or accepted disposition, or a written reason it was waived. The question "did we ever submit the spare parts list?" gets answered by the row. ## How Submittal Kit handles this Rebuilding the list of what you owe from memory, and finding the missing row at closeout, is the problem here. In Submittal Kit you [upload the spec book](/help/upload-specifications), claim your sections, and each claimed section is read for what it asks you to submit, each demand quoted with its article reference. Answer each with Create, Already covered, or Not required. The [Submittal Log](/help/submittal-log) shows how many demands are still unanswered, and once packages go out it tracks status, ball in court, submitted and returned dates, and overdue reviews. Export it as XLSX or PDF when the GC asks. Order-by dates for equipment come from [coverage and lead times](/help/coverage-and-lead-times). See the [submittal log](/features/submittal-log). *Disclosure: I build Submittal Kit. A register built this way in a spreadsheet does the same job.* --- Submittal Kit · Field Guides · Updated 2026-10-04 Canonical: https://submittalkit.com/learn/building-the-submittal-register