# Closeout Checklist for a Control System Project

The deliverables that stand between substantial completion and final payment, when each should have started, and a checklist to run from day one instead of the last week.

Closeout is where control system projects go to stall. The system runs, the client is happy, the crew has mentally moved to the next job, and final payment sits behind a list of documents: as-builts, O&M manuals, test records, warranties, training. Weeks become months. The margin that looked healthy at startup leaks away in remobilized document work and retention you can't invoice.

The fix isn't working harder in the last week. It's recognizing that almost every closeout deliverable is a byproduct of work done months earlier, captured at the time or reconstructed at the end. Captured is cheap. Reconstructed is expensive and worse.

## The checklist

What follows is the common core. Your actual list comes from the contract's closeout sections and each technical section's own closeout demands, which you found during [the spec read](/learn/read-a-spec-section-for-submittals). Build the project-specific list at kickoff, not at substantial completion.

### As-built drawings

The approved [panel drawings](/learn/panel-drawing-package) plus every field change, incorporated. The only economical way to produce them is to capture each change as a redline when it happens, in the panel shop and in the field, then incorporate the accumulated redlines at the end. As-builts reconstructed from memory during closeout week are fiction, and the operator who trusts them inherits the risk.

### As-left programs and configuration

The final PLC programs, HMI applications, drive parameters, instrument configurations, and network configs, exactly as commissioned, with versions and save dates recorded. Not the office copy from before startup; the as-left copy. Handing these over cleanly is also self-defense: the service call in two years starts from the delivered baseline instead of an argument about which version is real.

### O&M manuals

Usually the largest single deliverable, and often themselves submitted for review, which means their review cycle belongs on the schedule, not discovered after substantial completion. Structure and process are covered in [how to build a control panel O&M manual](/learn/build-a-control-panel-om-manual); the short version is that a manual assembled from an equipment register maintained all job long is an export, and one built from scratch in closeout week is a research project.

### Test and commissioning records

Signed FAT and SAT results, loop check sheets, calibration records. These exist the day the tests pass; the only closeout question is whether they were filed against the project record then or must be excavated from a truck laptop now. File them then.

### Warranties and certifications

The warranty statements the spec requires, with start dates, which are worth reading carefully: warranty-from-shipment versus warranty-from-acceptance can differ by a year of coverage on a long job. Plus any certifications promised in the submittals and not yet delivered.

### Spare parts and special tools

If the contract requires spares, they need to be ordered early enough to exist at closeout, delivered against a transmittal, and receipted. Spares discovered as an obligation during closeout week arrive after final payment was supposed to.

### Training

Sessions delivered per the spec's hours and topics, sign-in sheets kept, and any required training materials or recordings handed over. Training is a scheduling deliverable; the operators you're contracted to train stop being conveniently available once the plant is theirs.

### Punch list closure

Every item closed or formally accepted as-is, with the responsible party's sign-off. The punch list is also the discipline that keeps closeout honest: small enough items tracked visibly, instead of a fog of "a few loose ends" that never quite ends.

### The final documentation submittal

Closeout deliverables are usually themselves submittals: numbered, transmitted, reviewed, sometimes revised. The record of *what you handed over and when* matters as much at closeout as it did at design review, because retention release and warranty start dates hang off it. The same [log discipline](/learn/submittal-numbering-revision-schemes) applies to the last package as the first, and the whole set is what the industry calls the turnover package; the taxonomy is in [submittal, O&M manual, turnover package](/learn/submittal-om-manual-turnover-package).

## Running it from day one

Three habits turn the list above from a closeout crisis into an assembly task:

1. **Build the project's closeout list at kickoff**, from the contract, with an owner and a due date per item. Twenty minutes, and long-lead items (spares, training scheduling, manual review cycles) surface while they're still schedulable.
2. **Capture at the moment of creation.** Redlines when the change happens, test sheets when the test passes, configuration saves when commissioning ends. Every capture deferred becomes reconstruction.
3. **Review the list monthly.** One recurring agenda line: what's complete, what's capturable now, what's drifting. The project that does this closes out in weeks. The project that doesn't donates its retention to the calendar.

*Disclosure: I build [Submittal Kit](/), which keeps the equipment register, redlines, punch list, and submittal log on one project so the closeout deliverables assemble from records that already exist. The habits above are the actual product; software just makes them cheaper to keep.*

---
Submittal Kit · Learn · Updated 2026-08-17
Canonical: https://submittalkit.com/learn/control-system-closeout-checklist
