Rows are arranged so the team can review requirements, responsible sections, and status without starting from a blank spreadsheet.
SubPro turns a project spec book into a first draft your team can check: every row cites its spec page, the rows that need a decision are flagged, and it all exports as an editable Excel file.
The first pass shows up as draft rows with their matched documents and clear next actions, ready to inspect before export.
Every experienced PM has met one. The spreadsheet looks complete: tidy columns, plausible section numbers, a respectable row count. Then month five arrives. The GC asks for the fire-stopping product data, and the log has no such row, because the requirement lived in a paragraph on page 412 and the engineer who typed the log was reading page 412 at eleven at night, three weeks into a transcription marathon.
Nobody did anything wrong, exactly. A human read eight hundred pages and hand-typed several hundred rows, and humans doing that make between a few and a few dozen errors, silently. The rows that exist look identical to the rows that should exist but do not. There is no highlighting for the requirement that never made it in, no red flag on the section that got skimmed because two spec books shared a folder and only one got read.
That is the real danger of the hand-built log. Not that it is slow, though it is. It is that its errors are invisible until they are expensive: a missed submittal becomes an unapproved product, becomes rejected material, becomes schedule. The log is the one document where wrong quietly beats late.
Submittal log software earns its keep on exactly this failure. Not by promising perfection, but by making every row checkable and every gap findable while the mistake still costs minutes.
The first draft is where the day usually disappears: rows, page numbers, responsible sections, and the nagging sense that Division 07 hid something nasty. SubPro builds a practical first pass that shows what the spec requires, where it came from, and which rows deserve a closer look before handoff.
The requirements arrive as a working draft, grouped by section, so your team reviews a list instead of building one.
When someone asks why a row is there, the answer is the spec page attached to it, not another hunt through the manual.
Review it, clean it up, and export it to Excel. Your tracker gets a finished starting set instead of an empty register.
The value of submittal log software is not a pretty dashboard. It is what you can hand the next person. SubPro exports a standard editable XLSX log with one row per submittal requirement, each carrying its CSI section, submittal type, responsible party, the source specification page, review status, and notes.
Because it is an ordinary spreadsheet and not a locked format, your team can sort it by section, filter to one trade, add or delete rows, and paste it straight into whatever tracker you already run. The draft removes the blank-sheet grind. Your team keeps full control of the final log.
The columns are the ones a working log actually needs, not the forty a template salesman thinks you need. Submittal number for referencing it in a phone call. Section and title so a stranger knows what trade owns it. Type, because a sample and a test report follow different paths. Responsible party, so Friday's question has a name on it. The source page, which is the column everything else stands on. Status and notes, because the log is a conversation, not a monument. Enough structure to run a job, little enough that people keep it current.
Every row keeps its source page reference, so when a reviewer questions a line, the answer is one click away instead of a hunt back through the manual. That is the difference between a list you trust and a list you re-check by hand.
Claims about accuracy are cheap. Every product page on the internet says accurate. So SubPro does not ask you to believe an adjective. It attaches the evidence: each row in the drafted log carries the specification page it was read from, and the citation is a working link, not a footnote. Doubt a row, click it, read the paragraph, decide. Checking a suspect row takes less time than complaining about it.
The citations change what an error costs. In a hand-typed log, a wrong row survives until a human happens to compare it against the manual, which in practice means it survives until it hurts. In a cited log, wrong rows die in review, at a desk, in minutes. A reviewer sweeping the draft with the sources one click away catches the misread requirement while it is still a line item and not a lien item.
Coverage gets the same treatment as correctness. Because SubPro reads every section rather than a tired sample of them, the draft does not have the skimmed-Division-hole problem, and the rows that genuinely need human judgment arrive flagged rather than blended in. Uncertain beats confidently wrong, every time, and the flags say exactly where uncertain lives.
Then the log stays trustworthy after the draft. Statuses record which rows have been verified by a person. Edits and revisions accumulate on the row instead of overwriting it. Six months in, the log is not a snapshot of somebody's optimistic kickoff week. It is a running record of what was required, what was checked, and what was decided.
Take Section 08 71 00 Door Hardware, the section estimators dread and architects love. Forty pages of hinges, closers, and keying language, carrying one of the longest submittals lists in the book. It is exactly the section where a hand-typed log starts dropping rows, so here is how it lands in the draft.
A row for the required hardware schedule submittal, tagged with the 08 71 00 section and the spec page behind it.
Separate rows for the specified hinges, closers, locksets, and exit devices, so each product line can be reviewed on its own.
A row flagged as an owner decision, because keying is coordinated with the owner rather than picked from a catalog.
All the 08 71 00 rows drop into the editable XLSX alongside every other section, ready to sort, filter, and hand off.
Most submittal logs die young. They get built in a burst of kickoff energy, they are accurate for about six weeks, and then reality outruns the spreadsheet: rows change hands, revisions land in inboxes, and the log becomes the thing people mean to update on Friday. By the end, the real state of the submittals lives in email threads and the log is a historical fiction.
SubPro's log does not need a Friday. Status changes happen where the work happens, on the row, as rows get reviewed, sent, returned, and revised. Nothing about keeping the record current is a separate chore someone has to remember, which is the only kind of record-keeping that survives contact with a real project.
The payoff compounds quietly. In month two it means a PM answers "where are we on hardware?" by sorting a column instead of convening a meeting. In month eight it means the new engineer inherits a log that explains itself, every row carrying its source, its history, and its current state. And at the end it means closeout starts from a complete, cited record instead of a reconstruction project. The log you built on day one is the log you hand over on the last day, and it never stopped being true.
The log has an owner on every job, whether the org chart admits it or not. Usually it is whoever complained about it least recently. These are the desks it tends to land on, and what changes for each of them.
Your scope, your rows, without borrowing a week from estimating to type them. The trades with submittal-heavy sections feel it first.
The first pass stops being a rite of passage. You review a cited draft and spend the reclaimed week on coordination that actually needs an engineer.
A log with source pages and statuses built in, instead of a formatting project with forty tabs and a naming convention only you understand.
Mid-project takeover? Run the specs, get a cited baseline, and reconcile it against whatever the last team left behind.
Door hardware is famously submittal-heavy, so here is the other kind of test: Section 23 05 29, Hangers and Supports for HVAC Piping and Equipment. Nobody dreads this section, and that is the trap. It reads like boilerplate, gets skimmed like boilerplate, and then a seismic bracing requirement surfaces during inspection with no submittal behind it.
Rows for hanger types, channel framing, and attachment hardware, each citing the 23 05 29 page that requires it.
Seismic bracing details ride in a reference paragraph, not the submittals article. The draft carries the row anyway, citation attached, where a skim would have lost it.
Support layout drawings need engineering coordination, so the row arrives flagged for a human call instead of pretending to be routine.
Sorting the XLSX by section splits the mechanical scope cleanly from Division 08, so each coordinator reviews their own rows.
"Our Excel log works fine." It does, until the project where it does not, and nobody gets to pick which project that is. The spreadsheet that survived a 200-page tenant fit-out meets an 850-page ground-up job with three addenda, and the same process that worked starts shedding rows. The failure arrives exactly when the stakes are highest, because row count and page count are what make hand-typing break. If your projects are getting bigger, the question is not whether the manual log fails, but which job it fails on.
"We tried AI extraction once. It made things up." Fair, and worth being precise about. Unverifiable AI output deserves the distrust. The fix is not a better promise, it is a checkable one: every SubPro row points at the page it came from, so a fabricated row has nowhere to hide. Click the citation and the paragraph either says what the row claims or it does not. You are never asked to trust the machine, only to read what it read. The rows it was unsure about arrive already flagged, which is the opposite of making things up.
On data: your spec book is processed for your job and then removed, full stop. The particulars, including what gets deleted and when, live on the data handling page in plain English.
Identify submittal requirements from the specifications, keep source page context close, flag items that need review, and carry each row's status and history forward, so the log stays a live record instead of a spreadsheet that dies after kickoff.
An editable XLSX log with a row per requirement, carrying the CSI section, submittal type, responsible party, source specification page, review status, and notes. Being a standard spreadsheet, your team can sort, filter, and paste it into an existing tracker.
Yes. The draft is a starting point, not a locked output. Your team edits rows, adds or removes requirements, and owns the final log. SubPro removes the blank-sheet grind, it does not make the decisions.
No. SubPro prepares a reviewable starting point. The project team still verifies requirements, responsibility, substitutions, and final package decisions before anything moves forward.
A spec book is a hostile document, and nobody who reads them, human or software, bats a thousand. What SubPro commits to is checkability: the citation on every row, flags on the uncertain ones, and a review pass that catches errors while they cost minutes. Verifiable beats take-my-word-for-it.
Yes. Each row carries a live status through review and keeps it moving after: what has been verified, what went out, what came back, and which revision is current. The same log that started the job is the record you open at closeout.
Hours, scaled by spec size, and most of that is machine time you do not sit through. The hand-typed version of the same pass is measured in days of a project engineer's calendar. The review that follows is the only part that still costs your team attention.
The exports are ordinary files: XLSX for the log and schedule, PDF for packages. Whatever platform the GC requires, those drop in without a fight, and your own cited record stays intact on your side.
The affected rows update as revisions rather than silent overwrites, and the prior state stays in the row's history. You can always answer what changed, when, and what the log said before.
No seat licenses, no onboarding call. The one-off Log Build runs the same engine on a single spec book and hands you the finished draft to keep.
From the draft log to the register, the AI behind it, and the files you get at the end.
How the first draft appears before anyone opens the spec book.
The same data as a register, page citations riding along.
The export formats your GC and your closeout binder will want.