Inspection Management Software for Service Providers

Most inspection management software is built for the company that owns the asset. This one is built for the company that gets called in to inspect it.

There is a structural difference between managing inspections on plant you own and running a business that inspects other people's plant. Owner-operator tools assume a fixed asset register, an internal workforce and no invoicing. Service providers have the opposite problem: the assets belong to clients and change every contract, the workforce is mobile and certified per method, and every job has to be costed, reported to a client-specific template and defended in a client audit. Atlantis NDT ERP is built for the second case.

What breaks when you use owner-operator tools as a service provider

The asset register assumes you own the assets. Client confidentiality, per-contract access control and asset handover between contracts have no natural home.
Personnel records track job titles, not method-level NDT qualification against a written practice — so the record a client audit asks for does not exist in the system.
Calibration is modelled for production equipment, not for flaw detectors, probes, wedges and reference blocks with ISO 17025 traceability chains.
There is no concept of a technician being dispatchable or not dispatchable based on certification currency.
Work orders are internal maintenance tasks, so job costing against an invoiced contract and client-specific reporting formats have to be built from scratch.

The system of record for an inspection business

Atlantis NDT ERP puts the six things that actually run an inspection company on one platform, so that a change in one is visible in the others: a certification that lapses on Friday removes that technician from Monday's dispatch automatically.

People — method-level qualification per SNT-TC-1A, CP-189, ISO 9712 or NAS 410, with vision exams, examination records, on-the-job hours and the governing written-practice revision.
Equipment — instruments, probes, wedges, reference blocks and step wedges with calibration intervals, certificates and traceability to a national standard.
Work — multi-crew, multi-site scheduling and dispatch, with mobilisation, standby and travel captured as costed time.
Assets — client plant/unit/line/component hierarchies with persistent CML and TML identity across campaigns.
Evidence — procedures, written practices and technique sheets under ISO 9001 revision control, with point-in-time recovery.
Money — job costing at work-order level, progress and milestone billing, retention handling and per-contract margin visibility.

Field capture that survives a refinery

Field data entry is where most inspection software fails in practice. Inspectors work in confined spaces, on scaffold, inside vessels and offshore, wearing gloves, with no signal and often against a permit clock. The mobile capture layer is built for that: full offline operation with deferred sync and conflict handling, method-specific forms that mirror the technique sheet, photo and sketch attachment with automatic location tagging to the CML, and digital sign-off that carries the inspector's certification state at the moment of inspection — not at the moment of upload.

Reporting to the client's template, not yours

Every major client wants the same inspection presented its own way. The reporting layer separates the dataset from the presentation, so one UT thickness survey can be issued as an API 510 vessel report to one client, an internal corrosion-trending summary to another, and a raw data export to a third — without re-keying and without three versions of the truth. Reports carry the procedure revision, the technician's certification state and the instrument's calibration status at the time of inspection, which is precisely the bundle an audit asks for.

Where it fits alongside what you already run

The platform is not an attempt to replace your instrument software or your accounting system on day one. It ingests instrument output through file import or REST API and runs alongside SAP, Oracle, NetSuite, Dynamics 365, QuickBooks and Xero. Where clients run their own integrity platforms, inspection results can be pushed back into SAP PM, Oracle eAM, IBM Maximo or ServiceNow so your data lands where the client expects it. When you also run the Atlantis Digital Twin, inspection results flow onto the 3D asset model without a second data entry step.

A realistic implementation

Typical rollout for a 20–60 technician inspection business
Stage	Duration	What happens
Discovery & mapping	Weeks 1–2	Written practice, certification matrix, calibration register, client and asset lists reviewed and mapped for migration.
Core configuration	Weeks 3–5	Certification, calibration and work-order modules configured; report templates built for your two or three largest clients.
Pilot	Weeks 6–7	One crew, one client contract, live. Field capture tested offline. Audit-evidence path rehearsed end to end.
Rollout & training	Weeks 8–10	Remaining crews onboarded, historical records migrated, dashboards handed to operations and QA.

Frequently Asked Questions

What is inspection management software?

It is the system of record for an inspection operation: who is qualified to perform which method, whether their certification and vision exams are current, whether the instruments are in calibration, which inspections are due on which client assets, what was found, how it was reported and what it cost. For service providers it also has to handle client contracts, multi-crew dispatch and job costing, which is what separates it from an owner-operator CMMS.

How is this different from a CMMS?

A CMMS is designed for an organisation maintaining assets it owns, so it optimises maintenance planning, spares and reliability. Inspection management software for a service provider optimises a different set of constraints: mobile certified personnel, calibrated instruments, client-owned assets that change every contract, client-specific reporting and per-job profitability. Companies that force a CMMS into the service-provider role usually end up maintaining a large custom-field layer to hold certification and calibration data the product was never designed for.

Can it handle multiple clients with different reporting formats?

Yes, and this is one of the main reasons companies switch. The inspection dataset is stored once and rendered through client-specific templates, so the same UT survey can be issued in three different formats to three clients without duplicate data entry. Each issued report records the procedure revision, technician certification state and instrument calibration status applicable at the time of inspection.

Does it work for inspection disciplines beyond NDT?

Yes. The same model — qualified people, calibrated equipment, scheduled inspections on client assets, evidence-backed reporting — applies to coatings inspection, marine survey, geotechnical and materials testing, environmental testing, calibration laboratories and welding/fabrication QA. Those industry configurations ship as pre-built templates, and the platform is used across all of them.

Can we start with one module?

Yes, and most companies should. The usual entry point is certification tracking or calibration management, because those are where audit risk concentrates and where the value shows up fastest. Scheduling, field capture, job costing, CRM and document control are added afterwards without replatforming, since they are apps on the same Odoo foundation rather than separate products.

What integrations are available?

REST API and webhooks for anything custom, plus supported connectors for SAP PM, Oracle eAM, IBM Maximo, ServiceNow, NetSuite, Dynamics 365, QuickBooks and Xero. Instrument data enters by file import or API. Full bulk export is available at any time — you should be able to leave a platform with your data, and we make that explicit rather than awkward.

Is the platform accessible for a small company?

Yes. It is positioned as affordable, accessible and fully customizable, and is in use by companies from roughly ten technicians upward as well as by multi-country contractors. Commercial terms depend on scope, region and team size — request a tailored quote and a 30-minute demo run against your own workflow.

See it running on your own workflow

Thirty minutes, your job types and your reporting formats, co-presented by an ASNT NDT Level III. Affordable, accessible, fully customizable — request a demo and a tailored quote.

A service provider running inspection crews across multiple clients needs the software to keep each client's report template, terminology, and contract scope separate by default, not as a workaround. The same platform that tracks one client's asset hierarchy and report format has to keep a second client's entirely different template and scope boundary from bleeding into the first, especially when the same technician works both in the same week.

Owner-operator inspection software assumes one company, one asset register, one reporting standard, which is exactly backwards for a service provider whose business is running the same crews and the same methods across a rotating set of client contracts, each with its own report format, terminology, acceptance criteria, and scope boundary. A technician who ran UT thickness surveys for a refining client on Monday and a fabrication shop's weld inspections for a different client on Wednesday needs the platform to switch report template and terminology cleanly between those two jobs, without manually reformatting or risking one client's proprietary asset naming showing up in another client's deliverable. That separation has to hold at the data layer, not just the PDF output, because contract scope, billing boundaries, and certification requirements are also client-specific and can't be inferred after the fact from a single shared project structure.

Source: ASNT SNT-TC-1A

Keeping multiple clients and contracts legible in one system

The core problem is that a service provider's crew, equipment pool, and certification roster are shared resources deployed across many separate client relationships, while the reporting, terminology, and often the acceptance criteria for each of those relationships need to stay distinct. A platform built around a single asset hierarchy handles this badly — either every client's data gets visually mixed together, or the company ends up running a separate instance or spreadsheet per client, which defeats the purpose of having a system of record at all. The workable model keeps one underlying resource pool of technicians, equipment, and certifications, while partitioning report templates, terminology sets, and client-facing structure per contract.

Crew and certification availability is the second layer of the same problem. A scheduler needs visibility across every active client commitment simultaneously to answer a basic question — is a technician with current PAUT certification and no conflicting assignment available for a job starting Thursday — without that visibility leaking client-specific job details across contracts that shouldn't see each other. This is different from what an owner-operator's asset integrity platform needs to solve, because an owner-operator is scheduling against its own assets, not arbitrating capacity across a portfolio of unrelated client commitments.

Billing and scope boundaries follow the same logic. When the same technician logs time against a fabrication inspection for one client in the morning and a refinery turnaround job for another client that afternoon, the system needs those hours, that equipment usage, and that report output to stay attributable to the correct contract without manual reconciliation after the fact — otherwise scope creep between contracts becomes a billing dispute waiting to happen rather than something the software prevented by design. ERP integration on the billing and scheduling side is often what closes this gap for service providers running enough concurrent contracts that spreadsheet reconciliation stops being viable.

None of this requires a different platform per client relationship — it requires the underlying system to treat client and contract as first-class fields that every report template, every schedule entry, and every billing record inherits automatically, rather than something a project manager has to manually enforce by discipline and habit across dozens of concurrent jobs.

Terminology mapping is a smaller but constant friction point: one client calls a component grouping a circuit, another calls the same grouping a zone, and a third uses the numbering scheme from their own CMMS rather than any inspection-specific convention. A platform that hardcodes one naming convention forces the inspection company to either retrain technicians per client or manually relabel every report before it goes out, neither of which is where a service provider's differentiation should be spent.