ITP and ITR are two of the most common acronyms in construction quality, they're only one letter apart, and they're constantly mixed up. The confusion is understandable — they're closely related and often live in the same folder — but they do genuinely different jobs. Getting the distinction right matters, because a quality system that muddles the plan with the record tends to produce weak documentation on both sides.
This article explains what each one is, how they differ, how they work together, and how to structure them so your project's quality records actually hold up.
The short version
An ITP (Inspection and Test Plan) is the plan. It's written before the work starts and defines what will be inspected, when, by whom, and against what acceptance criteria. It's a forward-looking document.
An ITR (Inspection and Test Report) is the record. It's completed during or after the work and captures what actually happened at a specific inspection or test — the measured result, whether it passed, who signed it, and when. It's a backward-looking document.
Put simply: the ITP says what you're going to check; the ITR says what you found when you checked it.
What is an ITP?
An Inspection and Test Plan is a structured document that maps out the inspection and testing regime for a scope of work. For each activity it specifies:
- The inspection or test item — what's being checked
- The reference — the drawing, spec clause, or standard that sets the requirement
- The method — visual inspection, measurement, test, or documentation review
- The responsible party — contractor, subcontractor, principal's rep, third-party inspector
- Hold points and witness points — mandatory stops and notification requirements
- The acceptance criteria — what a passing result looks like
The ITP is typically prepared and approved before work begins. It's the roadmap for quality on that scope — a concrete pre-pour ITP, a structural steel erection ITP, a pipeline installation ITP. One ITP usually covers a whole activity or work package, and it contains many individual inspection line items.
What is an ITR?
An Inspection and Test Report is the evidence that a specific inspection or test was carried out and what the result was. Where the ITP is the plan for the whole activity, an ITR is often the record for a single test or a specific instance of an inspection.
A typical ITR captures:
- What was inspected or tested — the specific element, location, and item
- The date and time it was carried out
- The method used and the equipment or test standard applied
- The measured result — the actual value, reading, or observation
- Pass or fail against the acceptance criteria
- The inspector — who performed and who verified it
- Supporting evidence — photos, test certificates, calibration records
Common ITRs include concrete compressive strength reports, compaction test reports, weld NDT reports, pressure test reports, and holiday-detection (spark test) reports for coatings. In many quality systems, the ITR is the objective evidence attached against a line item in the ITP.
ITP vs ITR: the key differences
| ITP (Plan) | ITR (Report) | |
|---|---|---|
| Purpose | Defines what will be checked | Records what was found |
| Timing | Prepared before work starts | Completed during/after the work |
| Direction | Forward-looking | Backward-looking |
| Scope | An entire activity or work package | A specific inspection or test instance |
| Contains | Items, methods, criteria, hold points, sign-off roles | Measured results, pass/fail, inspector, evidence |
| Quantity | One per activity | Often many per ITP |
| Answers | "What are we going to inspect?" | "What did we find when we inspected it?" |
How they work together
On a well-run project, the ITP and its ITRs form a matched set. The workflow looks like this:
- The ITP is written and approved before the work starts, setting out every inspection and test required for the activity.
- Work proceeds to the first inspection or hold point defined in the ITP.
- The inspection or test is carried out, and the result is recorded — either directly against the ITP line item, or as a separate ITR that's referenced back to it.
- Objective evidence is attached — for a test, that's the ITR (e.g. the lab's concrete strength report); for a visual inspection, it might be photos and a signed checklist line.
- Sign-off happens at hold and witness points as the ITP requires.
- At completion, the signed ITP plus all its supporting ITRs and certificates become the quality record for that activity — the package handed over as proof the work was built and verified to specification.
The ITP is the index; the ITRs and certificates are the evidence it points to. An ITP with no completed records behind it proves nothing. A pile of ITRs with no ITP tying them to a plan is disorganised and hard to audit. You need both, linked.
Where teams get it wrong
Treating the ITP as the record. Some teams fill acceptance results directly into the ITP and never produce distinct reports. That can work for simple visual inspections, but for anything requiring objective test data — concrete strength, compaction, weld integrity — you need the actual test report (the ITR) as evidence. The ITP line item should reference it.
Producing ITRs with no plan behind them. Labs and testing subcontractors generate ITRs constantly. If those reports aren't linked back to a controlling ITP, nobody can easily see whether all the required tests were done — only that some tests were done.
Losing the link. The single biggest failure is the ITP living in one place and the ITRs living in another — a folder of PDFs, an email thread, a subcontractor's filing cabinet. At audit or handover, reassembling which report satisfies which ITP line item is slow and error-prone.
Mixing up the acronyms in the contract. Because they're so similar, ITP and ITR sometimes get used interchangeably in specs and correspondence. When a contract calls for "ITRs for all concrete works," clarify whether they mean the test reports specifically or the full inspection-and-test package — it changes what you have to deliver.
Structuring ITPs and ITRs digitally
The relationship between an ITP and its ITRs is exactly the kind of thing paper and spreadsheets handle badly and software handles well. The ITP is the parent; the ITRs are children linked to specific line items. When they're linked digitally:
- Every ITP line item shows whether its required evidence has been captured
- Test reports and certificates attach directly against the item they satisfy
- A project manager can see, at a glance, which inspections are complete and which are outstanding
- At handover, the combined package — ITP plus every linked ITR — generates as a single, ordered record
- The sign-off workflow captures who verified each result, when, and where
This is where the confusion between the two acronyms stops mattering in practice: the plan and its records are one connected structure, not two separate piles of paper.
Getting started
If you're setting up quality documentation for a new scope, start with the ITP — it's the plan that everything else hangs off. Define your inspection items, acceptance criteria, hold points, and sign-off roles first. The ITRs and test certificates then slot in against those items as the work is inspected and tested.
HoldPoint QA is built around exactly this structure. Create an ITP template once with AI assistance, import it into any project, then link ITR documents and evidence directly against the relevant checklist items — so the plan and its records stay connected from first inspection to final handover. If you just need a standards-aligned ITP to start from, the free AI ITP generator will build one from a scope description in under a minute, or browse the ITP template library by trade.