QuickBooks Integration for NDT Inspection Software

Why QuickBooks stays and the ERP adapts

In the United States, the small inspection contractor's accountant works in QuickBooks, files taxes from QuickBooks, and reconciles the bank feed in QuickBooks. Replacing it means retraining an outside CPA who bills by the hour and has no reason to learn an ERP's accounting module. So the sensible architecture for a five-to-fifty-technician NDT shop treats QuickBooks as fixed infrastructure. The operational software — jobs, technicians, equipment, reports — must integrate with it rather than compete with it, and the quality of that integration decides whether month-end close takes an hour or a weekend.

Most inspection software vendors treat the subject with one sentence — "integrates with QuickBooks" — on a features page. That sentence hides the four questions that matter: which objects sync, in which direction each flows, which system wins a conflict, and what happens to an invoice that gets edited after posting. Those answers are configuration decisions, and wrong ones surface as drift weeks later, when the books and the job list disagree by a few hundred dollars nobody can locate.

The division of labor that works: the NDT platform is the system of record for operations — job numbers, scopes, technician assignments, equipment usage, inspection reports, timesheets. QuickBooks is the system of record for accounting — chart of accounts, tax, deposits, payroll, reconciliation. Exactly four objects cross that boundary. This page walks through each one, the setup order that makes them behave, and the specific places drift creeps in when the boundary is drawn sloppily.

The four objects that sync, one at a time

Customers sync first because everything else hangs off them. The correct pattern is ID mapping: on first sync, each ERP customer is either matched to an existing QuickBooks customer and its QuickBooks ID stored on the ERP record, or created fresh with the new ID stored. From then on, every invoice references that ID, never the name string. Integrations that match by name create the classic QuickBooks disease — "Chevron", "Chevron Corp", and "Chevron Corporation" existing as three customers with three open balances.

Service items are the mapping layer between what you sell and where the revenue lands. Each ERP product — UT shift rate, MT technician day, per-diem, mobilization, report fee — maps to one QuickBooks item, and each QuickBooks item points at an income account. Get this right and the P&L reads revenue by service line with zero extra effort. Get it wrong and every invoice posts to a single "Services" account, which erases the answer to the one question worth asking: which methods make money.

Invoices flow one way: ERP to QuickBooks. The invoice is assembled in the NDT platform, where report numbers, shift counts, and job data live, approved by someone with billing authority, then pushed. It arrives in QuickBooks either as a posted invoice or — a defensible choice in the first months — as a draft the bookkeeper releases. The number sequence must have a single owner; two systems both assigning invoice numbers guarantees collisions with whatever the CPA created by hand.

Payments flow the opposite way: QuickBooks to ERP. Money is received, matched, and deposited in QuickBooks, where the bank feed lives. The integration reads payment events and marks the corresponding ERP invoices paid, so a project manager sees paid status on the job screen without asking the bookkeeper. The reverse event matters just as much — a voided or bounced payment must reopen the invoice in the ERP, or operations keeps treating a live receivable as closed.

What deliberately never syncs

Inspection reports, technician certifications, and equipment calibration records stay out of QuickBooks — not because syncing them is hard, but because they have no accounting meaning and QuickBooks gives them no revision control. A report PDF attached to a QuickBooks invoice becomes an orphaned copy the moment revision B is issued. The invoice line can and should carry report numbers as text — clients match invoices to deliverables that way — but the documents themselves live in the NDT platform, under its numbering and revision rules.

Timesheets and job costing deserve special caution. Labor cost belongs in job costing inside the ERP, and payroll belongs in QuickBooks or a payroll service — those are two different views of the same hours. Pushing raw timesheets into QuickBooks alongside payroll produces double-counted labor expense, one of the ugliest cleanup jobs in bookkeeping. Hours reach QuickBooks in exactly one form: as billable invoice lines after markup, never as cost entries duplicating what payroll already posted.

Setup order: the boring work that decides everything

Step one happens entirely inside QuickBooks: clean the chart of accounts and decide the income accounts — one per service line is the structure that makes the P&L useful for an NDT shop. Step two is the item map: list every distinct thing you invoice, create matching QuickBooks service items, and record the mapping. Contractors discover here that their invoicing has been improvised for years — the same mobilization charge entered five different ways. The integration forces the standardization that should have existed anyway.

Step three is customer deduplication, done before the first sync ever runs. Merge duplicates inside QuickBooks, then match ERP customers to the survivors and store the IDs. Skipping this step means the integration faithfully propagates the mess, and unwinding merged transactions later is worse than the original cleanup. Budget real hours for it: a ten-year-old QuickBooks file with hand-entered customers holds more duplicates than anyone expects, and every one left standing becomes a mis-posted invoice waiting to happen.

Step four is a hard cutover date. Invoices dated before it live only in QuickBooks; invoices after it originate only in the ERP. Resist backfilling history through the sync — pushing a year of old invoices into a file where they already exist creates duplicates by the hundreds, and duplicate revenue is the kind of error that surfaces at tax time. Historical reporting can read from QuickBooks directly; the integration's job starts at the cutover and runs forward.

Where double-entry drift comes from

Drift is the state where the ERP and QuickBooks disagree about a number and nobody knows which is right. Its root cause is singular: the same object accepting edits on both sides of the boundary. The bookkeeper "fixes" a pushed invoice in QuickBooks — adds a line, adjusts a rate — and the job record no longer matches the books. The fix is procedural, not technical: corrections happen in the system that owns the object, then re-sync. An invoice wrong in QuickBooks gets corrected in the ERP.

The second source is identity matching. Name-string matching spawns duplicate customers; reused invoice numbers apply payments to the wrong job; loosely matched items post revenue to wrong accounts. Every one of these disappears when the integration stores hard IDs — QuickBooks' own record identifiers — on the ERP side and matches on nothing else. Ask a vendor directly whether their sync matches on ID or on name; the answer sorts real integrations from checkbox ones in a single sentence.

The third source is arithmetic. Tax computed in two places with two rounding rules produces penny mismatches that block reconciliation and stack into real discrepancies across hundreds of invoices. The rule: QuickBooks computes tax, using its own jurisdiction tables, from taxable-status flags the ERP sends per line. Discounts and credit memos follow the same logic — issue them in the ERP, let QuickBooks post them, and the two systems stay in lockstep down to the cent.

NDT invoicing is why the ERP must build the invoice

An inspection invoice is not a product invoice. A single turnaround job bills straight-time and overtime shifts at different rates, per-diem days per technician, mobilization and demobilization, equipment charges for a PAUT rig, exposure counts on RT work, and minimum call-out charges when a two-hour job bills as four. All of that data originates in dispatch and timesheets — inside the NDT platform. Rebuilding it by hand in QuickBooks is where office evenings go to die, and every retyped line is a fresh drift opportunity.

Progress billing on long jobs follows the same principle. The billing schedule — a mobilization draw, progress draws against percent complete, retainage — lives on the ERP job. Each draw becomes an ordinary invoice pushed to QuickBooks, while the ERP tracks billed-to-date against contract value. What breaks is trying to run QuickBooks-side progress invoicing against a QuickBooks estimate, because the ERP cannot see the estimate and the two billed-to-date figures immediately diverge.

QuickBooks Online versus Desktop for inspection contractors

QuickBooks Online is the version built for integration: a REST API, OAuth authorization, event notifications for payments, and no software running on your machines. Every modern NDT platform that syncs at all syncs with Online. Intuit has also spent years steering Desktop customers toward Online — new US subscriptions for most Desktop editions stopped in 2024 — so the platform direction is settled, and new integration work targets the Online API.

Desktop integration still exists through the QuickBooks Web Connector — a Windows service polling on a schedule — or third-party bridges. It works, with more moving parts: a host machine that must stay on, a sync that runs on intervals rather than events, and file-locking quirks in multi-user mode. A contractor still on Desktop with an integration project ahead should sequence it deliberately: migrate to Online first, stabilize one full month of books, then connect the ERP.

How to test a vendor's QuickBooks claim before buying

In the demo, script four scenarios and watch them happen live. One: create a job, invoice it, push it, open it in QuickBooks. Two: edit that invoice inside QuickBooks and see what the ERP does — the honest answers are "flags a conflict" or "overwrites on next sync," and you need to know which one you are buying. Three: receive a payment in QuickBooks and watch the job close in the ERP. Four: void that payment and watch the job reopen. A vendor who cannot demo scenario four has a one-way sync wearing a two-way costume.

In writing, require the object list (customers, items, invoices, payments at minimum), the direction of each, ID-based matching, approval-gated invoice push, and payment-reversal handling. These belong in your requirements document verbatim — the full set is in the /erp/ndt-software-rfp-requirements-checklist. Contractors running API 510, 570, and 653 inspection programs alongside NDT services should also read /erp/api-inspection-contractor-management-software, because inspection-interval data adds its own integration questions on top of the accounting ones.

Atlantis configures its Odoo-based NDT ERP either way — synced to QuickBooks Online for shops whose CPA stays in QuickBooks, or running Odoo's own accounting for shops bringing the books in-house. Affordable, accessible, fully customizable. A working demonstration against a copy of your own QuickBooks file is the fastest way to judge any vendor's claim, ours included — a demo is available on request.

Request a consultation