A completions management system is the database and workflow that proves a construction project is finished, system by system, before it is commissioned and handed over. It holds every tagged item, the inspection and test records (ITRs) that verify it, the punch items still open against it, and the certificates that close each stage, all organised by commissioning system rather than by construction area. Its job is to answer one question with evidence: is this system ready for the next stage?
That sounds simple. On a real project with tens of thousands of tags, dozens of contractors and a start-up date that will not move, it is one of the hardest information problems on site.
What is completions in construction?
Completions is the phase, and the discipline, that sits between construction and commissioning. Construction builds by area and by discipline: the piping contractor finishes a pipe rack, the electrical contractor pulls cables through a substation. Commissioning, on the other hand, needs to energise and operate whole systems: the instrument air system, the firewater ring main, a 400V switchboard and everything it feeds.
Completions translates one view into the other. The completions team takes construction output, verifies that each item has been installed and tested correctly, records any defects, and packages the evidence by system so commissioning can take over a coherent, safe scope. On oil and gas, LNG, power, renewables and pharmaceutical projects this usually runs through mechanical completion, pre-commissioning and commissioning, ending in handover to the owner or operator.
Terminology varies. Some companies call the whole thing "completions and commissioning" (C&C), some use "CSU" (commissioning and start-up), and others split "mechanical completion" from "systems completion". The underlying structure is much the same.
The building blocks of a completions system
Whatever software or spreadsheet you use, a completions database is built from the same core records.
The system and subsystem hierarchy
Systemisation breaks the plant into commissioning systems and subsystems, each with a defined boundary marked up on P&IDs, single-line diagrams and layout drawings. A typical hierarchy runs:
Project → System → Subsystem → Tag
A system might be "Cooling water", with subsystems for the pumps and headers, the heat exchangers, and the associated instrumentation. Every item on the project belongs to exactly one subsystem. That single rule is what lets progress, punch counts and certificate status roll up cleanly.
Tags
Tags are the individual items that get inspected and tested: a pump, a valve, a transmitter, a cable, a line, a junction box, a motor. The tag register records each one with its discipline, type, subsystem, location and the drawings it appears on. If a tag is missing from the register, its inspections will be missing too, and nobody will notice until a walkdown or, worse, until start-up.
Inspection and test records (ITRs)
ITRs, often called checksheets, record that a tag has been inspected or tested against defined acceptance criteria. Most projects split them into two families:
- A-type ITRs, carried out as part of mechanical completion: installation checks, alignment, torque, insulation resistance on cables, pressure test records, visual inspections.
- B-type ITRs, carried out during pre-commissioning: loop checks, motor solo runs, flushing, function tests of individual devices.
Each tag type is assigned a set of ITRs by discipline, which gives you the full scope of inspection work before a single sheet is filled in. Some companies add a C-type for commissioning-level checks. If you need discipline checklists themselves, checksheets.com covers ITR content by discipline in detail.
Punch items
A punch item is a defect or incomplete piece of work found during inspection or a walkdown. Each is raised against a tag and subsystem and given a category, usually A (must be cleared before the next certificate), B (can be carried past it, but must be cleared before handover or acceptance) and C (minor or cosmetic). The exact definitions are set by the contract or the client's completions procedure, so check yours.
Certificates
Certificates formally close each stage for a system or subsystem. Common examples include the mechanical completion certificate (MCC), ready for commissioning (RFC), ready for start-up (RFSU) and a handover or turnover certificate (TOC). Each certificate has prerequisites: all relevant ITRs complete and signed, no open Category A punch, required documents in place. Names and sequences differ between owners, contractors and methodologies such as OPERCOM, so the chain on your project will be defined in the completions or commissioning execution plan.
Handover documentation
Alongside the inspection data, the system collects the documents the owner will need: signed ITRs and certificates, vendor data, test reports, as-built drawings and operating and maintenance information, compiled into a dossier per system.
How the pieces fit together
The value of a completions management system comes from the links between these records, not from the records themselves.
| Record | Linked to | What the link lets you answer |
|---|---|---|
| Tag | Subsystem, discipline, drawings | What exactly is in this system's scope? |
| ITR | Tag, ITR type (A/B), signatory | Has every item been inspected and tested? |
| Punch item | Tag, subsystem, category, action party | What is still wrong, and does it block anything? |
| Certificate | Subsystem or system, prerequisite ITRs and punch | Can this system move to the next stage? |
| Document | Tag, system, handover requirement | Is the evidence the owner needs actually there? |
When those links are maintained, a completions engineer can open a subsystem and see, at a glance, "412 tags, 1,180 A-ITRs of which 1,140 are signed, 6 open Category A punch items, MCC not yet issuable". When the links are broken, that same question takes a day of cross-checking.
A typical completions workflow
A well-run completions process follows the same sequence on most industrial projects:
- Systemise the project. Define systems and subsystems, mark up the drawings and freeze the boundaries early enough for construction to plan around them.
- Build the tag register. Load tags from engineering deliverables and assign each one to a subsystem.
- Generate the ITR scope. Apply ITR templates by tag type and discipline so every required inspection exists as a record, even before it is done.
- Execute A-type inspections. Construction and QC complete installation checks and tests, with witnessing by the client or third party where the inspection and test plan calls for it.
- Walk down each subsystem. A joint walkdown by construction, completions, commissioning and often operations raises the remaining punch items.
- Issue mechanical completion. Once A-ITRs are signed and Category A punch is cleared, the MCC is issued for the subsystem.
- Execute B-type pre-commissioning. Loop checks, flushing and solo runs are completed, and further punch is raised and cleared.
- Progress through the certificate chain. RFC, commissioning, RFSU and start-up, each gated by its prerequisites.
- Hand over. Compile the system dossier and transfer care, custody and control to the owner.
The order matters. B-type tests on equipment that has not passed its A-type installation checks waste time at best and damage equipment at worst.
Why spreadsheets break down at scale
Many projects start completions in Excel, and on a small scope that can work. The problems appear as the project grows and the pace increases.
- Version control. Several contractors send back their own copies of the ITR tracker. Merging them becomes a weekly job, and nobody is sure which file is the truth.
- No enforced dependencies. A spreadsheet will happily show a subsystem as "MCC issued" while an A-ITR is still unsigned or a Category A punch item is still open. The rules live in people's heads.
- Weak audit trail. You can see a value but not who changed it, when, or on what evidence. That matters when an owner or regulator asks how a system was accepted.
- Evidence lives elsewhere. Signed ITRs are scanned into folders, photos sit on phones and punch lists are emailed. Linking evidence back to the tag is manual and often skipped.
- Concurrency. Only one person can safely edit a shared workbook at a time, and field teams cannot update it reliably from site.
- Reporting lag. Progress reports are compiled by hand, so they describe last week rather than today, just when the start-up schedule needs daily decisions.
None of this means spreadsheets are useless. They are a reasonable place to prototype systemisation or hold a small scope. But once you are tracking thousands of tags across multiple contractors with certificates that gate energisation, a spreadsheet stops being a control and becomes a record of what people believe.
What to look for in construction completions software
If you are evaluating a completions database or software platform, test it against the way your project actually works:
- System-based structure. Tags, ITRs, punch and certificates organised by system and subsystem, with progress rolling up automatically.
- Hard gating. The ability to block a certificate until its prerequisites are genuinely met, and to stop B-type work starting before A-type records are approved.
- Configurable categories and certificates. Your client's punch categories and certificate names, not the vendor's.
- Witnessing and sign-off. Clear assignment of who inspects, who witnesses and who approves, with a record of each action.
- Field capture. Inspectors recording results and photos on site rather than transcribing paper later.
- Handover output. A dossier per system that can be compiled from the records you already hold, including any owner data standard such as CFIHOS.
- Audit trail and access control. Every change attributable to a person and a time.
Managing completions in Accord
Accord is FNVi's completion execution platform. It structures a project as Project → System → Sub-system → Equipment/Tag, with completion metrics rolling up automatically. Its ITR framework covers 'A' mechanical-completion inspections and 'B' pre-commissioning tests, and its dependency engine stops 'B' records starting until the prerequisite 'A' records are approved. Punch, NCRs and queries are managed together with Category A/B/C criticality and stage-gate blocking. Certificates follow an enforced dependency chain (MCCR → DAC → MCC → SHC → RFCC → AOC → RFSU → TOC/TOM → PTC), witnessing is tracked end to end, and handover dossiers are compiled per system against a required-document matrix. If you want to see it against your own project structure, get in touch.
Frequently asked questions
What is the difference between a completions system and a document management system?
A document management system stores and controls documents. A completions system tracks the status of physical items and systems, linking each tag to its inspections, defects and certificates. Most projects need both, and good completions software links documents to the tags and systems they relate to.
Who owns the completions database on a project?
It is usually owned by the EPC or main contractor's completions team, with the client's commissioning or completions lead having visibility and approval rights. On some projects the owner provides the system and mandates that contractors use it. The contract or completions procedure should state who administers it and who signs what.
When should a completions system be set up?
Before construction starts producing inspection records, and ideally as soon as systemisation is stable. Setting it up late means loading months of paper ITRs retrospectively, which is slow and error-prone. Starting early also lets construction plan work to suit system completion.
Is completions only relevant to oil and gas projects?
No. The same approach is used on LNG, power generation, renewables, data centres, pharmaceutical facilities and large building services projects. The certificate names and inspection content change by sector, but the logic of tags, inspections, defects and certificates organised by system is common to all of them.
Can a completions management system replace walkdowns?
No. Software tells you what has been recorded; a walkdown confirms what has actually been built. The system makes walkdowns more effective by showing the team which ITRs are open and which punch items already exist before they go into the field, and by capturing new punch items against the right tag.