An API 570 inspection report is the documented record of a piping system's condition, the methods used to assess it, and the inspector's professional judgment on remaining fitness for service. Every compliant version needs the same core skeleton whether the piping is carbon steel or exotic alloy: a clear header identifying the system, an inspector of record with valid certification, thickness data traceable to specific CMLs, findings classified by severity, and repair recommendations that distinguish what's mandatory from what's advisable. This guide walks through each of those pieces with worked examples, copy-ready table layouts, and phrasing you can adapt directly.
Before you write a single paragraph, run your draft against this checklist:
- Report header with number, unit, owner, location, and piping system ID
- Inspector name, API 570 certification number, signature, and date
- Inspection scope, dates, and methods (visual, UT, RT, PT, MT)
- UT/thickness data table with corrosion rate and remaining life
- CML references cross-linked to the isometric drawing
- Findings with severity classification and clause citations
- Recommended actions split into mandatory, short-term, and long-term
- Attachments index (isometrics, photos, NDE reports, calibration records)
The sections below include example tables, a corrosion-rate calculation walkthrough, and a full report template you can copy into your own reporting tool.
Key Takeaways
A compliant API 570 inspection report succeeds when every thickness reading traces to a specific CML, every finding cites a clause or tmin comparison, and mandatory repairs are labeled distinctly from recommendations.
| Point | Details |
|---|---|
| Header must be traceable | Include report number, unit, owner, and specific P&ID or drawing references, not generic line labels. |
| Tag every CML consistently | Cross-reference each UT reading to the same isometric callout across every inspection cycle. |
| Show the corrosion-rate math | Include nominal thickness, measured thickness, tmin, corrosion rate, and remaining life in one table. |
| Separate mandatory from recommended | Use explicit tmin or clause references when labeling a repair as mandatory. |
| Digitize capture to cut errors | A platform like Inspekto links field photos and UT data directly to CMLs, producing export-ready audit packages. |
Table of Contents
- What Goes Into an API 570 Inspection Report Section by Section
- Building UT Tables, CML Records, and the Corrosion-Rate Math
- How Should You Organize Attachments and Supporting Files?
- What Findings Language and Severity Labels Should You Use?
- A Ready-to-Copy API 570 Report Skeleton
- Mapping Your Report to API 570 Clauses for Audit Purposes
- Why Digital Capture Beats Paper for API 570 Consistency
- Turn Field Captures Into Audit-Ready Reports Automatically
- Sources
What Goes Into an API 570 Inspection Report Section by Section
Every section of the report has a specific job, and auditors know exactly where to look for gaps. Treat each one as a data requirement, not a formality.
Report header and identification. This block needs the report number, owner/operator name, unit designation, physical location, piping system ID, and the specific P&ID or drawing references tied to that circuit. Skip the drawing reference and you've already created a traceability problem for the next inspection cycle.
Inspection scope and dates. State the start and end dates of the inspection, the type performed (visual, ultrasonic thickness, radiographic, penetrant, or magnetic particle), how much of the circuit was covered, and any access or scheduling limitations that restricted scope.
Inspector identity and certification. Full name, API 570 certification number, signature, and the date the report was finalized. This is non-negotiable and the first thing auditors check.
Methods and instruments. List make, model, and stated accuracy for every UT gauge and NDE instrument used, along with the calibration reference or block number. A thickness reading is only as good as the instrument that produced it, and API's guidance on piping inspection intervals and methods makes clear that qualified personnel and documented methods are baseline expectations, not extras.
Attachments index. List every isometric, CML record, photograph, and NDE report referenced in the body, with a short pointer to where each lives in the appendix.
Building UT Tables, CML Records, and the Corrosion-Rate Math
The thickness table is where most reports live or die. Auditors read it first because it's where the actual evidence sits.
Structure your UT/thickness table with these columns: location tag, ISO callout, material, nominal thickness, measured thickness (with the reading date), tmin, corrosion rate, remaining service life, and the retirement criteria that applies. Here's a sample row layout:
Each CML record should cross-reference the isometric sheet number and callout point, not just a generic "line 12" label. Inconsistent tag mapping between the report and the ISO drawing is one of the most frequent failure modes in manually built reports, since a structured CML workflow depends on every reading tying back to the same physical point over time.
Here's the corrosion-rate math worked through: if a CML measured 0.280 inches nominal and now reads 0.198 inches after 10 years in service, the corrosion rate is (0.280 − 0.198) ÷ 10 = 0.0082 inches per year, or 8.2 mils/yr. Remaining life is then (0.198 − 0.147) ÷ 0.0082 = 6.2 years, using tmin of 0.147 inches for that schedule and material. These calculations are exactly what the API 570 Authorized Piping Inspector Body of Knowledge lists as examinable competencies, because they're the numbers that actually drive repair decisions.
Pro Tip: Round consistently, either to the nearest thousandth of an inch or the nearest 0.1 mil/yr, and never mix units mid-table. Document the instrument's stated accuracy next to the calibration reference so anyone reviewing the report years later can judge measurement uncertainty without guessing.
How Should You Organize Attachments and Supporting Files?
Attachments carry as much audit weight as the narrative report, so treat naming and structure with the same discipline.
Include isometrics with CML callouts marked, raw NDE data files, timestamped inspection photos, prior repair records, and any rerate or alteration paperwork tied to the system. A photo without a timestamp or tag reference is close to useless for future comparison.
Use a naming convention that survives a folder reshuffle: ISO-001_CMLs.pdf, UT_RAW_CML-12_20260401.csv, PHOTO_Tag-12_20260401.jpg. Keep a flat folder structure by unit and inspection date rather than nesting attachments five levels deep.
Reference attachments directly in the narrative rather than leaving readers to guess: "See Attachment A — ISO-001, sheet 2; CML-12" tells the reviewer exactly where to look without flipping through the whole appendix.
What Findings Language and Severity Labels Should You Use?
Ambiguous wording is one of the most common audit findings inspectors run into, and the fix is standardizing your severity classes before you write a single finding.
- Critical/Immediate: Measured thickness at or below tmin, or active leak indication. Requires shutdown or immediate repair.
- High/Short-term: Thinning trend projecting below tmin within the next inspection interval. Requires repair scheduling within a defined window.
- Medium/Planned: Localized corrosion or CUI (corrosion under insulation) with adequate remaining life. Requires monitoring and inclusion in the next turnaround scope.
- Low/Monitor: Minor surface indications with no measurable wall loss trend. Requires continued routine monitoring.
Sample phrasing for common findings: "Localized external corrosion identified at CML-12, measured thickness 0.198 in against tmin of 0.147 in, remaining life calculated at 6.2 years." For a mandatory repair, be direct: "Wall thickness at CML-08 measured below tmin (0.132 in vs. 0.147 in required). Mandatory repair required per API 570 fitness-for-service evaluation prior to return to service." That kind of explicit tmin reference is exactly what the BOK's calculation requirements point toward, since a vague "recommend repair" leaves too much open to interpretation.
A Ready-to-Copy API 570 Report Skeleton
Copy this structure directly into your reporting tool and fill in the placeholders for your specific piping circuit.
- Cover page: Report number, owner, unit, piping system ID, inspector name and certification number, report date.
- Executive summary: One paragraph stating overall condition, headline findings, and whether any mandatory repairs exist.
- Inspection scope: Dates, methods used, extent of coverage, limitations encountered.
- Equipment list / CML index: Every CML tag with ISO reference, keyed to the piping circuit's actual P&ID.
- UT/thickness tables: Insert the table format from the data section above, one per circuit or system.
- Findings: Each finding with severity classification, tmin comparison, and clause reference where applicable.
- Required repairs: Mandatory items only, with deadline and code basis.
- Recommendations: Short-term and long-term items, separated clearly from mandatory repairs.
- Attachments index: List with file names and reference pointers used in the narrative.
- Inspector signature block: Name, certification number, signature, date.
Place tables immediately after the section that references them rather than bundling everything into one appendix. That keeps the narrative and the evidence close together, which matters when a reviewer is checking the report months after the inspection.
Mapping Your Report to API 570 Clauses for Audit Purposes
Auditors work from clause numbers, so citing them inline saves everyone time and shows you've done the mapping deliberately rather than as an afterthought.
Reporting and records requirements sit in Section 7.9 of API 570 Fifth Edition, which spells out the code's intent for accurate, timely assessments that let owner-operators respond to findings requiring corrective action. Reference this directly: "Evaluation per API 570, Section 7.9, Reporting and Records." Inspection interval and method requirements draw from the sections covering piping classes and risk-based inspection, while repair and alteration documentation ties back to the code's rerating and alteration clauses.
Your recordkeeping checklist should include: inspector signatures, calibration records for every instrument used, raw NDE data (not just summarized results), repair certificates, and any rerating calculations. Confirm you're citing the correct edition and addenda, since API maintains effectivity notices tracking which clause numbers apply to which edition. A report citing outdated clause numbers from a superseded edition is an easy, avoidable audit flag.
Why Digital Capture Beats Paper for API 570 Consistency
Reporting works best as a continuous data-capture habit rather than a scramble after the inspection ends. Structured digital capture, photos tagged to a specific CML, voice notes recorded in the field, GPS timestamps on every reading, closes the gap between what an inspector observes and what ends up in the final report.
That consistency matters most for corrosion-rate tracking, where every reading has to tie back to the same physical point over multiple inspection cycles. A continuous capture approach reduces the missing cross-references and inconsistent units that plague manually assembled reports.
Pro Tip: When exporting a digital report builder's PDF or Excel output, drop it directly into the skeleton's attachments index rather than reformatting the data by hand. Inspekto's platform, for instance, links captured photos and UT readings straight to CML records, so the export already matches the structure auditors expect.
Editor Note: The Mistakes That Keep Showing Up in API 570 Reports
I keep seeing the same four errors: CML tags that don't match the isometric, thickness readings mixing mils and inches in the same table, no calibration record attached to a UT gauge, and repair wording so vague nobody can tell if it's mandatory or optional.
The fixes are boring but effective. Standardize units project-wide. Require a calibration entry every time an instrument gets used. Attach a photo and a tag reference to every critical CML reading, no exceptions. Adopt the template above and the digital capture habits from the last section, and most of these problems disappear before they reach a reviewer's desk.
Turn Field Captures Into Audit-Ready Reports Automatically
Building the tables, calculations, and clause citations above by hand works, but it's slow, and every manual entry is a chance for a tag mismatch or a unit error to slip through. Inspekto automates that handoff: inspectors capture photos and voice notes in the field, and the platform pre-fills report fields, links attachments to the right CML, and exports the finished package as a structured PDF or Excel file.
Three things matter most for teams preparing API 570 reports on a recurring basis:
- Templates mapped to API 570 structure, so header fields, UT tables, and findings sections follow the same order auditors expect every time.
- Photos and UT readings linked directly to CMLs, removing the tag-mismatch problem that trips up manually assembled reports.
- Exportable audit packages in PDF or Excel, ready to attach to the report skeleton without reformatting.
If your team is producing these reports quarter after quarter, visit Inspekto to see how a trial or demo maps to your specific piping systems and reporting cadence.
Sources
- Piping Inspection Code: In-service Inspection, Rating, Repair, and Alteration of Piping Systems
- BODY OF KNOWLEDGE API-570 AUTHORIZED PIPING INSPECTOR
- API 570 – Technical Toolboxes Knowledge Center