Start With the Category, Not the Vendor Shortlist

Start with the failure you are paying for

Every shortlist that goes wrong starts with a product demo instead of a symptom. Write down the last three things that cost you money and name where in the workflow each one happened. A report returned by a client for a missing acceptance criterion is a template problem. A crew that drove four hours and could not shoot because the source utilization log was not current is a scheduling-constraint problem. An invoice raised six weeks after demobilization is a job-to-cash problem. Three symptoms, three categories of software, and no vendor will tell you which one you have.

The four categories are instrument acquisition and analysis, reporting, inspection management, and ERP. They overlap at the edges and vendors blur the boundaries in marketing, so the reliable test is what the software refuses to let you do. Acquisition software will not let you dispatch a technician. A CMMS will not let you model a certification. Reporting software will not let you invoice. The refusal is the boundary. Once your symptom sits on one side of a boundary, the vendor list for that category is short and the comparison becomes tractable — the NDT inspection software guide carries the vendor-level view.

Buying two categories at once is normal; buying them in the wrong order is expensive. Reporting sits on top of inspection management, because the report inherits the job number, the technician, the equipment serial and the procedure revision from the layer beneath it. Buy the report layer first and you hand-key those fields forever, which is exactly the data-entry cost the purchase was supposed to remove. Buy the management layer first and the report becomes a rendering of records the system already holds. The reporting software comparison assumes that order.

Category one — instrument acquisition and analysis

Acquisition software lives with the instrument. It drives the flaw detector or scanner, records the raw waveform, and gives the analyst the tools to interpret it: A-scans, B-scans, C-scans, corrosion maps, TFM reconstructions, encoder-linked weld overlays. Evident's OmniPC and WeldSight, Waygate's Mentor, Eddyfi's Magnifi, Zetec's UltraVision and Sonatest's UTStudio+ all sit here. The output is a data file and an analysis, and the file format belongs to the manufacturer that wrote it.

This is the category technicians ask for by name, because it is the software they touch every day. It is also the category that solves none of the problems an owner has. It does not know which technicians hold current Level II certification in the method, when the wedge was last verified, which client the data belongs to, or whether the job cleared its cost. Buying more acquisition licenses because scheduling is chaotic is a category error the industry repeats every year.

The question that matters for the other three categories is what acquisition software will hand over. Ask for the export: a PDF of the analysis view, a CSV or XML of the readings, and a scan file the client's own analyst can open. Those three artifacts are what a reporting or management system attaches to a job record. A system that stores the native scan file, renders the analysis image into the report, and keeps both under one job number has closed the loop between the instrument and the deliverable.

Category two — NDT reporting software

Reporting software turns readings into the document the client pays for. Its real work is not layout. It is acceptance logic: the thickness reading compared against t-min, the indication length compared against the applicable ASME, API or AWS criterion, the units, the calibration block reference, the technician's signature block and certification level printed on the face of the report. Layout is what buyers watch during a demo. Acceptance logic is what determines whether the report comes back.

Judge a reporting product on three things: whether your own client-specific format can be reproduced without vendor development work, whether acceptance criteria are editable by your Level III rather than by the vendor, and whether revision history survives a reissue. A reissued report that overwrites the original leaves an audit with two documents bearing one number and no explanation of the difference. The best NDT reporting software 2026 breakdown works through both the template model and the criteria model product by product.

Reporting software bought standalone works for a shop running one or two methods with a stable client list and a single scheduler who holds the operation in their head. It stops working at the point where the same job needs a dispatched crew, a certification check, a calibrated instrument and an invoice, because the report is then one output of a larger record rather than the record itself. That transition is the moment the inspection management layer starts paying for itself.

Category three — inspection management software

Inspection management runs the operation between the client request and the invoice. It holds clients, sites, assets belonging to those clients, work orders, crews, technician qualifications by method and level, instrument calibration status, procedures and their revisions, field data, reports and report numbers. Generic field-service platforms model the schedule and the customer well and model none of the qualification constraints, because plumbing, HVAC and pest control do not have them.

The distinguishing behavior is refusal. The system declines to schedule a technician whose certification in that method expires before the job ends. It declines to issue a work order against an instrument whose calibration certificate has lapsed. It declines to accept a report written against a superseded procedure revision. Software that records these facts and permits the dispatch anyway is a database, not a control, and the distinction is the whole purchase.

Two capabilities decide whether this layer survives contact with the field. Offline data capture has to work inside a tank, a vault or a plant with no signal, and reconcile without duplicating records when the tablet reconnects. Crew scheduling and dispatch has to respect the qualification constraints while still letting a coordinator move a job at six in the morning. A product that handles one and not the other gets worked around, and the workaround quietly becomes the process.

Category four — ERP for inspection companies

ERP adds the money and materials layer on top of inspection management: quotes, contracts and rate schedules, timesheets, consumables and film or chemical stock, purchase orders, subcontractor costs, invoicing, and the general ledger. It answers questions the operational layer cannot. What did that job actually cost. Which client's work carries the margin. Which crew's utilization funds the overhead. How much revenue is sitting in reports that have been delivered and never billed.

The reason inspection contractors end up in ERP rather than a general small-business package is that the cost objects are unusual. A job's cost is technician hours at a certification-dependent rate, per-diem and mileage, consumables, equipment on hire, subcontracted scope, and a share of a calibration program. A general package models none of that natively, so the numbers get rebuilt in a spreadsheet every month. Job costing and profitability sets out the cost model and where each element enters it.

Atlantis builds this layer on Odoo, deployed in the cloud or on your own servers, with the inspection-specific objects — certifications, calibrations, procedures, methods, report numbering — added as modules rather than bolted on as custom fields on a generic form. Because you can hold the database yourself, the data-ownership question is settled at the start rather than at renewal. The ERP overview describes the module set. Affordable, accessible, fully customizable; demo and quote on request.

A ten-minute test for which category you need

Answer four questions in order and stop at the first yes. One: are your technicians unable to acquire or analyze data on the equipment you own? That is acquisition software, and the answer comes from the instrument manufacturer. Two: are finished reports being returned, reissued, or rebuilt by hand from spreadsheets? That is reporting software. Three: are jobs going out with the wrong person, the wrong instrument or the wrong procedure revision? That is inspection management. Four: do you not know what a job cost until the month closes? That is ERP.

Answering yes at three and four simultaneously is the common case, which is why the management and finance layers are usually bought together. The sequencing that works is management first, finance second, inside the same system, so the invoice draws its lines from the same work order the crew was dispatched against. Two systems joined by a monthly export recreate exactly the reconciliation work the purchase was meant to eliminate, and add a new argument about which one is right.

The RFP requirements checklist turns those four answers into a scoped requirement document you can send out unchanged. Send the same document to every vendor and score against it rather than against their demos: the demo is built to be impressive, the checklist is built to discriminate. The 2026 buyer's guide covers the trial protocol, the eight criteria, and the questions that separate the categories in practice.

What all four categories owe the audit

Every category eventually meets an auditor, and the same four artifacts get requested each time: proof the technician was qualified in the method on the date of the inspection, proof the instrument was in calibration on that date, proof the procedure used was the current approved revision, and proof the report on file is the report the client received. A system that cannot produce all four from records rather than from memory turns an audit into a week of archaeology in filing cabinets.

The failure is almost never that the facts are unknown. It is that they live in four places — a certification folder, a calibration spreadsheet, a controlled-document server and a report archive — with no key joining any of them to the job number. That join is the entire value of an integrated system. Audit preparation for inspection firms describes what the joined record looks like when a client auditor or an ISO 9001 registrar actually arrives.

Test it directly. Ask any vendor to produce, from a job you select at random during the trial, the technician's certification as of that date, the instrument's calibration certificate as of that date, the procedure revision in force, and the issued report with its full revision history. Time the answer. That single request separates systems that store these objects from systems that merely reference them in a text field.

Deployment, data ownership and the integrations that matter

Deployment model changes three things: where the data physically sits, who can restore it, and what happens at renewal. Cloud removes the server and the backup job from your responsibility. On-premise satisfies clients whose contracts prohibit inspection data leaving their network, which is a live requirement in nuclear, defense and parts of refinery and pipeline work. Atlantis supports both, so a data-residency clause in a client contract is a configuration question rather than a lost bid.

The integration list that matters for a US contractor is short. Accounting, because the ledger belongs to the accountant and the CPA. Payroll and time, because certification-dependent rates, overtime multipliers and per-diem drive it. Instrument data, because the scan file has to attach to the job. Client systems, because a portal or an SFTP drop is now a contract term on larger accounts. Everything else is negotiable and should be treated as such during evaluation.

Ask for the export format before you ask about anything else commercial. A full export means every object — clients, assets, jobs, readings, reports, certifications, calibrations — in an open format with the relationships intact, on demand, without a support ticket. A CSV of contacts is not an export. Vendors who answer this cleanly are the ones you can leave, and the ones you can leave are the ones worth signing with. Contact us for a demo or a quote on request.

Who should own the decision

Three people have to agree, and each has a different failure mode. The Level III owns procedures, qualifications and report acceptance logic, and will reject any system that lets an unqualified person change an acceptance criterion. The operations coordinator owns dispatch and will abandon any system that adds clicks to a six a.m. schedule change. The controller owns the ledger and will block anything that makes month-end longer. A demo that satisfies one of the three predicts precisely which department stalls the rollout.

Give each of them a defined test during the trial rather than a shared walkthrough. The Level III edits an acceptance criterion and reissues a report. The coordinator reschedules a crew into a certification conflict and confirms the system refuses rather than warns. The controller runs one job from work order to invoice to ledger entry. Three tests, one week, three independent verdicts, and the decision gets made on evidence instead of on a vendor's demo script.

Ownership after go-live matters as much as ownership during selection. Somebody has to maintain the certification register, the calibration schedule and the procedure revisions, because software fed stale data enforces stale constraints and teaches everyone to click through the warnings. Name that person before the contract, not after. Any vendor should be able to tell you, in hours per month, what keeping those three registers current actually costs your business.

Request a consultation