Prepare an as-built document register by defining the required final scope, identifying every document that must reflect the completed work, confirming its final revision and acceptance status, and reconciling the register with the actual handover files. Record exclusions and unresolved items explicitly instead of treating an incomplete folder as complete.
An as-built package is not created simply by renaming construction drawings. It should represent the completed work and meet the asset owner's required format, approval and information standards.
Start from the handover requirement
List the required document types, systems, assets, formats and metadata. Depending on the project, the scope may include drawings, specifications, equipment schedules, test results, commissioning records, certificates, operations manuals, warranties and asset data.
Use the contract and asset information requirements as the baseline. A generic closeout checklist is useful, but it cannot override project-specific obligations.
Build a controlled final-status view
For each required item, record the document number, title, discipline or system, final revision, status, responsible organisation, acceptance date and expected filename. Add the source requirement or package reference when several contracts contribute to the handover.
Confirm what “as-built” means
The project procedure should define the required status and evidence. A drawing may need verified site mark-ups incorporated, checked and approved before it is accepted as as-built. A construction issue with a changed status label is not automatically a faithful record of the completed asset.
Reconcile the register and package
- Freeze the final handover folder and decide whether subfolders are included.
- Export the relevant as-built register rows.
- Compare expected files with the folder.
- Investigate missing, unexpected and duplicate candidates.
- Check title blocks, approval status and technical contents through the normal review process.
- Repeat the file comparison after corrections.
- Preserve the final register, package and check report together.
Check formats and usability
Confirm that files open, naming follows the requirement and native formats are included where required. Check that external references, linked models and password protection do not make the delivered information unusable. A complete list of filenames can still describe an unusable package.
When Deliverable Preflight helps
Deliverable Preflight handles the deterministic register-to-folder comparison on Windows. It can show whether each expected filename or document-number token has zero, one or several matching files, and whether the folder contains unlisted extras.
Use the exported result as supporting evidence, not as a substitute for technical as-built verification or client acceptance.
View Deliverable Preflight in Microsoft Store →Related guides
Use the document handover checklist and turnover package index guide alongside this process.
Further reading
- nbn: as-built handover checklist
- Victorian Infrastructure Delivery Authority: digital engineering standards and handover data
Questions people ask
What should an as-built document register contain?
It should identify each required final document, its number, title, system or discipline, final revision, acceptance status, responsible organisation, date and file location.
Does as-built mean the same as issued for construction?
No. An issued-for-construction document directs work; an as-built or as-constructed record should reflect the completed work under the project's verification process.
Should incomplete items stay in the register?
Yes. Keep required but outstanding items visible with an owner and agreed action rather than hiding the gap.