When an Excel NDT report template stops being good enough
Excel handles NDT reporting well until three things appear at once: more than one technician editing the same job, examination records that must survive an audit years later, and equipment or personnel certificates that expire silently. A spreadsheet stores numbers. It does not enforce who signed, which revision the client received, or whether the probe was in calibration on the examination date.
The honest comparison is not two columns but three. A workbook on a local drive or a shared network folder gives you calculation and layout control and nothing else. The same workbook on OneDrive or SharePoint adds co-authoring and file-level version history — Microsoft's default retention is 500 versions per document — which removes the emailed-copy problem and gives coarse who-saved-when attribution. Purpose-built NDT reporting software adds the things that live below the file: a value tied to a technician, an instrument serial, a calibration status and a procedure revision; a report identity with revisions and an issued-to log; hard blocks when a certificate has expired; and a queryable history that survives template changes. Most NDT companies pass through the middle tier and stay there for years. It works until an accreditation assessment, a client audit or a disputed reading asks a question the file system cannot answer.
Source: ISO/IEC 17020:2012, clause 7.3 (inspection records) and clause 7.4 (inspection reports and certificates); ASME BPVC Section V, Article 1, T-190 Records/Documentation; API Standard 653 (retention of tank inspection records); Microsoft, "Excel specifications and limits" and "Version history limits for document library and OneDrive" (Microsoft Learn).
| Requirement | Excel/Word on a local or network drive | Excel on OneDrive or SharePoint | Purpose-built NDT reporting software |
|---|---|---|---|
| Two people working one job at once | No — copies fork and are merged by hand | Yes with AutoSave on, but cell overwrites are unguarded | Yes, with record-level locking and merge |
| Who changed this value | Not recorded | Who saved the file, and when | Who entered the field, when, from which device |
| Version history depth | Whatever the backup policy happens to keep | 500 versions per document by default | Every field change retained for the life of the record |
| Calibration or certificate expiry | A date in a cell; nothing watches it | A date in a cell; nothing watches it | Blocks selection of an expired instrument or technician |
| Which revision the client holds | Filename convention | Filename convention plus file history | Revision number, reason for revision, issued-to log |
| Offline capture in the field | Yes — the file is local | No — co-authoring needs a live connection | Product-dependent; verify it in airplane mode |
| Find 7 years of readings on one line | Open every file | Search across files with drifting layouts | One query, provided the schema held |
| Hard size ceiling | 1,048,576 rows x 16,384 columns per sheet | Same, plus sync and upload limits | Database-bound; never the practical constraint |
The three conditions that push a team off Excel
Teams do not leave Excel because the arithmetic is wrong. They leave when three conditions arrive together: two or more people need the same job open at the same time, a client or accreditation body asks for a record from three years ago, and a certificate expires without anyone noticing. Each of those is a governance problem rather than a calculation problem, and each is invisible on a single technician's laptop. Until all three arrive, a well-built workbook is a defensible tool, and replacing it early buys change management and little else.
The trigger is usually one specific event. An assessor asks which revision of a report the client holds, and the folder contains report_final_v3_REV2_client.xlsx next to two files with the same modified date. A thickness reading is queried and the only proof of who took it is a name typed into a cell that anyone could retype. A probe's calibration certificate turns out to have lapsed two weeks before a job that has already been invoiced. None of these are Excel defects. They are the absence of a system that binds a number to a person, an instrument and a moment.
The useful question is not whether Excel is good software. It is whether the workbook can answer, without a human reconstructing it, who entered this value, on which equipment, under which procedure revision, and what changed between the draft and the issued report. If the workbook answers that, stay where you are. If a person has to rebuild the answer from memory and email threads, that reconstruction is a cost you are already paying every time it is asked for.
Where Excel is genuinely the right tool
Excel is the best engineering calculator most NDT companies will ever own. Corrosion rate from two thickness readings and a date interval, minimum required thickness, remaining life, next inspection interval, statistical sampling plans, weld map coverage percentages, sizing tolerance studies — all of these are better in a spreadsheet than in a rigid form, because the Level III doing them needs to see and change the formula. Purpose-built software that hides the calculation behind a black box is a downgrade for exactly this work, and experienced engineers rightly resist it.
Excel also wins at low volume. A sole-trader Level III, or a two-technician shop running a handful of jobs a month for clients who accept a PDF, has no coordination problem to solve. There is one author, one copy, one filing convention, and the overhead of implementing software would exceed the time it saves. The same is true of one-off deliverables: a bespoke study, a failure investigation, a client's custom data sheet that will never be issued a second time.
After migration, Excel keeps earning its place as an interchange format. Clients ask for raw thickness data in a spreadsheet. Analysts pivot years of readings to find outliers. Bid teams model resourcing. The decision in front of you is narrower than "Excel or software" — it is whether the spreadsheet remains the system of record for examinations. Removing that one role changes nothing about the other uses.
Audit trail: file version history is not an examination record
SharePoint and OneDrive version history is real and useful. It retains up to 500 versions per document by default, shows who saved and when, and lets you roll a file back. That gives you two things: recovery from a bad edit, and coarse attribution at the level of the whole file. For document control of a procedure or a written practice, that is often enough, and it is a genuine improvement over a network share.
The record an assessor or a client wants during a dispute is finer than that. It is per value: the reading, its unit, the instrument serial number, that instrument's calibration status on the examination date, the procedure and revision applied, the technician and their certification level for the method, and the moment of capture. Restoring a file version gives you a whole workbook from a point in time. It does not tell you which cell changed, who changed it, or why, without someone manually diffing two copies.
ISO/IEC 17020:2012 clause 7.3 requires a record system that demonstrates the effective fulfilment of the inspection procedures and allows the inspection to be evaluated, with primary records made as soon as practicable. Clause 7.4 requires the inspection report to be internally traceable to the inspector who performed the inspection. Both are achievable with spreadsheets plus procedural discipline. The difference is that the discipline lives in people, and people rotate. Our clause-to-record mapping for inspection bodies is at /erp/iso-17020-software-for-ndt-inspection-bodies.
Concurrent editing: what co-authoring fixes and what it leaves
Microsoft 365 co-authoring genuinely solves the worst spreadsheet failure mode. When the workbook lives on OneDrive or SharePoint in .xlsx format with AutoSave enabled, several people can work in it simultaneously and see each other's changes. That removes the emailed-copy fork, where a technician downloads the file, edits offline, and returns a version that has diverged from the one the coordinator has been updating. Any NDT company still emailing report workbooks around should make this change first, before evaluating any software at all.
What co-authoring does not add is protection at the level of the data. There is no row locking, so two people can overwrite each other's cells. During co-authoring, versions are captured periodically rather than on every keystroke, so an overwritten reading can be recovered only to the nearest captured version, and only if someone notices in time to look. Sheet protection is a shared setting anyone with edit rights can lift. Excel for the web does not run VBA macros, so workbooks that depend on macro-driven validation lose that validation for browser users.
Co-authoring also assumes a connection. A technician working inside a tank, on a pipe rack or offshore has no live session, so they take a local copy and merge afterwards — which reintroduces exactly the fork the feature was meant to remove. Field capture is the single hardest requirement to retrofit onto a spreadsheet workflow, and it is covered in detail at /offline-ndt-inspection-app.
Calibration and certification expiry: the failure that is silent by design
A spreadsheet is passive. It computes when it is opened and does nothing when it is closed. Nothing in a workbook watches the clock, which means every expiry control built in Excel depends on a person opening the right file on the right day. That works for months and then fails once, quietly, on the week that person is on leave or on a shutdown.
The list of things that expire in an NDT business is longer than most teams track: instrument calibration due dates, reference and calibration block certification, couplant and consumable batches, technician certification renewal under the employer's written practice, the annual near-vision acuity examination and the colour contrast differentiation check that written practices require, client-specific approvals, site inductions, and medical or safety training. Any one of them lapsing invalidates the examination it touched. The discovery point is usually invoicing or audit, by which time the work must be redone at your cost.
The behaviour that matters in software is blocking, not reporting. A dashboard of amber and red dates is still a report someone has to read. A control that refuses to let an instrument serial be selected on a report whose examination date falls after that instrument's calibration due date, and refuses to name a technician as examiner for a method they are not currently certified in, removes the human step entirely. That is a constraint enforced at the point of entry, and it is the single clearest thing a spreadsheet cannot do against a user in a hurry.
Revision control and the report the client actually holds
Excel's revision problem is not versions inside the file — it is versions loose in the world. One examination produces a workbook, an exported PDF, a copy in the client's document management system, an attachment on an email to the site engineer, and often a printout in a turnaround file. Correct one reading and there are now five artefacts, four of them wrong, and no mechanism that reaches out to any of them. Filename conventions are an attempt to solve this with human memory, and they survive precisely until two people use different conventions.
A reporting system replaces the filename with an identity. The report has a number, a revision, a reason-for-revision field, a status that moves from draft through review to issued, and a log of who it was issued to and when. Superseded revisions are marked as superseded rather than deleted, so the historical record still shows what the client was told at the time and what changed afterwards. When an assessor asks which revision the client received and how you know, the answer is a record rather than a recollection.
This matters most where the report is derived from instrument output rather than typed. If A-scan or phased array data is exported, re-analysed and re-issued, the chain from raw file to issued revision has to be traceable both ways. That path is described at /omniscan-data-to-inspection-report.
Retained records: retrieval in year seven, not storage in year one
Storage is not the constraint. Retention periods in this industry are long by design: API Standard 653 requires the owner-operator to retain tank inspection records for the life of the tank, and ASME BPVC Section V, Article 1, T-190 (Records/Documentation) places responsibility for the required examination records on the Manufacturer, fabricator or installer. Those are horizons measured in decades, over which staff, file servers, Excel versions and template authors all change.
The binding constraint is retrieval. A realistic future request is not "send me the 2019 report" but "give me every UT reading taken on line 12-P-402 between 2019 and 2026, with the technician, the instrument and the procedure revision for each." Answering that from a folder tree means opening hundreds of files whose column layouts differ, because the template changed four times in seven years. Excel's own ceilings — 1,048,576 rows and 16,384 columns per sheet — are almost never what stops you. Template drift is.
This is the least glamorous argument for a database and the strongest one. A schema forces every reading, from every year, into the same shape, so a query written in 2031 still returns 2019 data. It is also why history import should be selective rather than total: bringing across the CML register and the thickness series is high value, while bringing across a decade of narrative report text usually is not.
Data that only becomes valuable once it leaves the spreadsheet
Readings held as structured records can be used again. Corrosion rate per CML computes itself, remaining life updates on every new reading, the next inspection date is derived rather than typed, and a thinning trend on one circuit becomes visible against hundreds of others. The same values sitting in cell G14 of a workbook require a parser and a human before any of that is possible, which is why it usually never happens.
The visual layer depends entirely on that structure. Painting measured wall thickness onto a 3D model, so a corrosion pattern reads as a shape rather than a column of numbers, needs each reading tied to a located CML — the workflow described at /digital-twins-ndt/ut-thickness-overlay. Whether you need that visual layer at all, or an inspection data management system instead, is worked through at /digital-twin-vs-idms.
This reframes the decision usefully. Choosing a system of record is choosing whether the next five years of readings become a queryable asset or a searchable archive. Neither choice is wrong, but only one of them compounds, and the cost of switching later is paid on all the data collected in between.
A migration order that does not stall
Migrations stall when they start with history. The order that finishes is master data first — technicians with their certifications and expiry dates, instruments with serial numbers and calibration due dates, clients, sites, assets and the CML register. That data is small, high value, and it is what makes expiry blocking and traceability work from day one. Then move the single highest-volume report type, run it in parallel with the spreadsheet for a few weeks, and only then extend to the remaining methods.
Keep the calculation workbooks. Most teams retain one or two engineering spreadsheets permanently, and that is the correct outcome rather than an incomplete migration. What moves is the record of examination — the values, the attribution, the revisions and the retention. What stays is the maths the Level III wants to be able to see.
Write your requirements down before you sit through any demonstration, using the buyer-side checklist at /erp/ndt-software-rfp-requirements-checklist. Then ask every vendor, including us, to demonstrate four things on your own data rather than on a sample dataset: field-level audit trail on a single reading, a hard block on an expired certificate, issuing a revision to a named recipient, and full offline capture. Atlantis builds NDT reporting to be affordable, accessible and fully customisable — request a demo or a quote at /contact or info@atlantisndt.com.
Is a spreadsheet acceptable evidence to an ISO/IEC 17020 assessor?
Yes, if the surrounding controls are real. ISO/IEC 17020:2012 clause 7.3 requires a record system that demonstrates the inspection procedures were followed, with primary records made as soon as practicable, and clause 7.4 requires the report to be internally traceable to the inspector who performed the inspection. Nothing there names a technology. Assessors raise findings on uncontrolled copies and unattributed edits, not on the file format.
What does Microsoft 365 co-authoring actually fix, and what does it leave?
It fixes the emailed-copy fork: the workbook lives on OneDrive or SharePoint, AutoSave is on, and several technicians type into one file. It leaves cell-level overwrites unguarded — there is no row locking, and during co-authoring versions are captured periodically rather than on every edit, so a clobbered reading rolls back only to the nearest captured version. Excel for the web also does not run VBA macros.
How do you stop an Excel thickness log from silently corrupting CML data?
Lock the layout and validate at entry. Protect the calculation columns, restrict readings to a numeric range with data validation, keep the CML identifier as a locked key column so rows cannot be inserted freely, and never let a technician re-sort the sheet. That survives disciplined users. It does not survive a paste of a block of values one row out of alignment, which is the most common way thickness histories go wrong.
Does leaving Excel mean losing our existing report formats?
No. Layout is the easiest thing to carry across, because it is presentation rather than data. The work is mapping which cell in your workbook is a stored field, which is a calculation, and which is boilerplate. Client-mandated data sheets usually stay visually identical while the numbers behind them move into a database, and an Excel export stays available for clients who want raw values.
What does staying on Excel for another year actually cost?
Count it in hours, not licences. Time re-keying instrument output into cells, time reconciling which file is current, time assembling records for an audit, time redoing work performed under a lapsed certificate, and time a Level III spends checking arithmetic instead of reviewing indications. Those hours are already being spent. They are simply not on an invoice line, which is exactly why the cost stays invisible.
When is Excel still the right answer for an NDT company?
When one person owns the workbook, job volume is low, no accreditation body inspects your record system, and no client requires a controlled revision history. Engineering calculation sheets — corrosion rate, minimum thickness, remaining life, sampling plans — should stay in Excel permanently. Moving the record of examination into software does not mean removing Excel from the business, and vendors who claim otherwise are overselling.