Multi-Tenant ERP for NDT Franchise and Multi-Branch Operators

Why a Single-Branch ERP Breaks the Moment You Open a Second Office

Most NDT companies start as a single crew with a single office and a QuickBooks file. The tooling that gets you through that phase, spreadsheets for technician certs, a shared calendar for equipment, an accounting package with one set of books, works fine because there is only one version of the truth to keep straight. The moment you open a second branch, whether that is a regional office in Baton Rouge to cover Gulf Coast turnaround season or a Midland satellite to chase Permian Basin pipeline work, that single version of the truth splits into two, three, or five versions that someone has to reconcile by hand. That reconciliation work is where NDT companies quietly bleed margin: a technician's MT certification lapses in one branch's spreadsheet but not the corporate tracker, a UT probe gets transferred from Houston to Beaumont and nobody updates the calibration due-date log, or a branch manager quotes a job at a rate corporate already discounted for that client last quarter because the two offices don't share pricing history.

This is an architecture problem, not a discipline problem. You can hire the most conscientious branch administrator in the industry and they will still lose the reconciliation fight if the underlying system was never built to represent "one company, multiple branches" as a first-class concept. The right question isn't "should we get an ERP," it's "does this ERP's data model actually match how a multi-branch or franchise-style NDT operation runs." That's a narrower, more technical question, and it's the one this article answers.

Multi-Company vs. Single-Database Multi-Branch: Two Different Architectures

ERPs solve the multi-location problem in one of two fundamentally different ways, and the difference matters enormously for an NDT operator.

True multi-company architecture spins up a separate company record (and often a separate chart of accounts and separate legal books) for each branch or subsidiary, with the ERP providing cross-company reporting and shared master data as a layer on top. This is the right model when branches are legally distinct entities, for example a franchise structure where the Beaumont office is a separate LLC with its own tax ID, or a joint-venture branch with a local partner holding equity. Each company keeps its own P&L, its own bank accounts, and its own statutory filings, while corporate can still consolidate for board reporting.

Single-database, multi-branch (or multi-location) architecture keeps one company, one set of books, and represents branches as a dimension, an "analytic account," warehouse, or department tag, rather than as separate legal entities. This is the right model for the far more common case: one company (say, "Atlantis Gulf Coast Inspection LLC") operating field offices in Houston, Baton Rouge, Midland, and Beaumont, all rolling into one tax return, one bank account, one workers' comp policy.

The mistake we see most often is NDT operators buying multi-company software (heavyweight, expensive to configure, built for holding companies with genuinely separate legal entities) when what they actually run is a single-company, multi-branch operation. That mismatch shows up later as: duplicate vendor records across "companies" that are really the same vendor, technicians who can't be shared across branch job boards without a formal inter-company transaction, and consolidated reporting that requires a separate BI tool because the ERP's own multi-company consolidation was never designed for four field offices reporting labor hours daily.

Atlantis ERP's native multi-company module supports both patterns from the same install, which is precisely why it's worth understanding on its own terms rather than through a vendor's marketing copy. You can run Houston, Baton Rouge, Midland, and Beaumont as four "companies" under one Atlantis ERP database with shared partners and products but separate books per branch, or you can run them as one company with four analytic accounts, four warehouses, and branch-level access rules. The decision isn't which software to buy, it's which of those two data models actually reflects your legal and operational structure, and then configuring accordingly. Getting this wrong at implementation is expensive to unwind eighteen months later once two years of transactional history are sitting in the wrong shape.

Consolidated vs. Branch-Level P&L and Analytic Accounting

Whichever architecture you choose, the reporting requirement is usually the same: corporate wants a consolidated P&L across all branches, and each branch manager wants their own P&L to manage their crew's performance against. In Atlantis ERP's single-company model this is handled through analytic accounting: every job, purchase order, and payroll entry carries an analytic tag for the branch (and often a second dimension for the client or project), so the same general ledger produces both views without duplicate data entry. A Houston-based UT technician billed to a Beaumont refinery turnaround gets their labor cost tagged to the Beaumont analytic account even though their paycheck runs through the Houston payroll run, which is exactly the kind of cross-branch labor sharing that happens constantly in outage season and that spreadsheet-based tracking handles badly.

In a true multi-company setup, the equivalent is inter-company transactions: Houston "sells" technician-hours to Beaumont at an internal transfer rate, generating a real invoice between the two legal entities that nets out in consolidation. This is more accounting overhead but it's the only correct approach when the branches really are separate legal entities with their own liability exposure, which matters more than people initially assume in an industry where a single radiography incident can trigger entity-level liability.

Concrete decision criterion: if your branches share one EIN and one workers' comp policy, you want analytic accounting under one company. If they don't, you need real inter-company invoicing. Ask any ERP vendor to show you, not describe, both a branch P&L and a same-period consolidated P&L pulled from the same underlying job data, live, in a demo. If they can only show you one or the other, or if producing the second view requires an export to Excel, that's a structural gap you will hit in month three.

Technician Certification Visibility: Company-Wide vs. Branch-Restricted

Certification records are the one dataset in an NDT company that genuinely needs to be visible enterprise-wide even when everything else is branch-restricted. A Level II UT technician certified under your written practice to SNT-TC-1A doesn't stop being qualified because they're covering a shift in a different branch, and a scheduler in Midland needs to be able to search the full roster, not just the Midland roster, when a Permian Basin client needs a Phased Array tech with a current cert and the local branch is short-handed during a compressor station turnaround.

The permission model you want is: certification records (method, level, date of initial cert, recertification date, employer's written practice reference, physical exam date) visible company-wide and searchable by method and expiry across all branches, while job records, client pricing, and branch P&L stay restricted to that branch's staff unless a user has a corporate role. This is a genuinely different access pattern than most generic ERPs assume, because most multi-branch access control is designed around "branch manager sees only their branch, full stop," which is correct for financial data and wrong for certification data.

• Branch manager role: sees their branch's jobs, quotes, invoices, and P&L; sees company-wide technician roster and certification status (read-only) for scheduling purposes.
• Corporate/QA manager role: sees roll-up reporting across all branches, manages the written practice, approves recertifications, audits ISO 9001 document control compliance company-wide.
• Field technician role: sees their own assigned jobs, their own certification record and expiry countdown, and equipment assigned to them, nothing else.
• Corporate finance role: sees consolidated books and, depending on architecture, either the single company's full ledger or all inter-company transactions across entities.

An Atlantis NDT ERP configuration handles this by layering role-based access rules on top of the certification module so that visibility and restriction operate on different axes simultaneously, rather than forcing a single blanket "branch-only" or "company-wide" toggle that inevitably gets the certification use case wrong.

Equipment and Calibration Asset Pooling Across Branches

Capital equipment, phased array units, digital radiography panels, gamma projectors, is expensive enough that most multi-branch operators pool it rather than duplicating a full inventory at every office. That pooling only works safely if the ERP tracks equipment location and custody in real time, because an inter-branch transfer that isn't logged is how a calibration block or a probe goes "missing" for three weeks until someone finds it in the back of a truck that drove from Houston to Midland for a one-off job.

The asset record needs to carry, at minimum: current physical location (branch and, ideally, vehicle or technician custody), calibration due date, last calibration certificate reference, and a transfer log with timestamp, sending branch, receiving branch, and the job number the transfer was for. When a Houston-based OmniScan X3 gets sent to Beaumont for a turnaround, that transfer should generate a record the Beaumont scheduler can see instantly, not a text message to the equipment coordinator that may or may not get logged into the spreadsheet that week. This is also where calibration due-dates matter operationally, not just for audit purposes: if a probe's calibration lapses while it's in transit or sitting in a branch that doesn't own it, the receiving branch needs a hard block preventing that asset from being assigned to a job until recalibration is confirmed. A generic asset-tracking module bolted onto a generic ERP usually won't enforce that block automatically; a module built around NDT calibration intervals will.

Consistent ISO 9001 QMS Document Control Across Branches

ISO 9001:2015 certification (and the quality manual, procedures, and written practice that support it) has to be the same controlled-document set across every branch, not a Houston version and a slightly different Baton Rouge version that drifted apart because two branch managers each kept their own copy in a local folder. Document control failures like this are exactly what an ISO 9001 surveillance audit is designed to catch, and they're embarrassing to explain to an auditor when the root cause is "our software didn't have a single source of truth for controlled documents."

A multi-branch ERP needs a document control module where procedures, work instructions, and the written practice are versioned centrally, distributed to all branches automatically on revision, and where each branch's use of an outdated revision is flagged rather than silently possible. This ties directly into the certification and training records discussed above: when your written practice changes a qualification requirement, every branch's technician files need to reflect that change on the same effective date, and the system of record should make it obvious which branches have acknowledged the revision and which haven't.

Consolidated vs. Branch-Specific Invoicing and Billing

Billing is where the client relationship intersects with the branch structure, and it needs to flex both ways depending on the client. A national EPC client running turnarounds across Houston, Beaumont, and Midland simultaneously usually wants one consolidated invoice and one PO process at the corporate level, even though the work was performed by three different branch crews. A regional fabrication shop that only ever uses your Baton Rouge branch wants a standard branch-level invoice with no corporate overhead in the way.

The ERP needs to support both without forcing every client relationship into the same mold. In practice this means invoicing needs to be configurable at the client level (consolidated billing contact vs. branch billing contact) while still rolling every invoice, regardless of which contact it went to, into the same underlying job costing and analytic accounting so branch P&L stays accurate either way. Atlantis ERP's native multi-company and multi-branch invoicing supports this through partner-level billing address configuration combined with analytic tagging, which is one of the more underrated reasons it fits NDT operators better than accounting-first ERPs that treat every customer relationship as 1:1 with a single entity.

Decision Criteria: How to Evaluate an ERP on the Multi-Branch Axis

When you're evaluating ERP options for a multi-branch or franchise-style NDT operation, run the vendor through these specific tests rather than accepting a generic capabilities slide:

• Ask for a live demo of both a branch P&L and same-period consolidated P&L generated from the same transactional data without an export step.
• Ask how certification records are scoped. Can a branch manager search company-wide by method and expiry without seeing another branch's financials?
• Ask to see an equipment transfer logged live between two locations and confirm the receiving branch's calibration due-date view updates immediately.
• Ask how document control revisions propagate to branches and how the system flags branches still on an outdated revision.
• Ask whether billing can be configured per client (consolidated vs. branch-level) without breaking branch-level job costing.
• Confirm which of the two architectures, true multi-company or single-company multi-branch, matches your actual legal structure, and make sure the vendor is configuring for that structure rather than defaulting to whichever one is easier for them to implement.

None of this is exotic. It's the operational reality of running more than one office in an industry where technician qualifications, equipment calibration status, and QMS document control are subject to code and client audit, on top of the ordinary financial reporting every business needs. The ERPs that handle it well are the ones built with NDT's specific compliance surface in mind rather than retrofitted from a generic field-services template. Pairing that ERP backbone with a digital twin platform for asset-level inspection history across branches, and with NDT reporting software that pulls technician certification data straight from the same system that scheduled the job, closes the loop between what corporate can see and what's actually happening on-site at every branch, every shift.

If you're weighing a multi-company build against a single-database multi-branch configuration for your own operation, that's exactly the kind of architecture decision worth getting a second opinion on before you commit two years of transactional history to the wrong model.

Atlantis NDT Products & Services

Atlantis NDT pairs field expertise with software: NDT inspection management software, Atlantis ERP, a digital twin platform for asset integrity, and NDT reporting software. Build your team with NDT training & certification (ASNT SNT-TC-1A) and ASNT certification pathways, or bring in ASNT Level III consulting. Affordable, accessible, fully customizable, book a free consultation.