Carrier acquisition technology due diligence: carrier field guide

Make diligence an evidence exercise

An acquisition technology review should answer practical operating questions. Can the buyer dispatch the acquired fleet on the first business day? Can finance reconstruct open receivables and driver settlements? Can safety retrieve historical records after a vendor account changes? Can the buyer lawfully use each application under the proposed transaction structure? An application inventory is a starting point, but it does not answer these questions. Request demonstrations and source artifacts from named owners, then record findings against the exact company and system being acquired.

Define the scope with the transaction team. An asset purchase, equity purchase and partial fleet transfer can leave different data, contract and access boundaries. This playbook organizes technical evidence; counsel determines legal obligations and interprets contract assignment, privacy and license terms. Safety leadership determines the applicable carrier recordkeeping and operating requirements. Do not equate a green technical test with a legal or regulatory conclusion. Record which decisions depend on specialist review and when those decisions must be available for closing.

Use a finding ledger with one record per check. Include the source artifact, date obtained, system scope, test performed, owner, result, business consequence, remediation estimate and accepted disposition. Mark an item unknown when evidence is missing. Distinguish seller statements from independently reproduced results. Screenshots can support a finding, but a recoverability claim should include a witnessed restore or export test. Preserve the source evidence under access controls appropriate for customer rates, employee records and transaction-sensitive information.

Business continuity and system ownership: checks 1 through 8

• 1. Legal-entity system map. Identify the legal company, operating authority, terminal and business unit supported by every application. Request diagrams and validate a sample order through billing. Flag shared systems that also serve operations outside the transaction perimeter.
• 2. Application inventory. Record product, installed version, hosting arrangement, support owner and business purpose. Compare vendor invoices with running services and user interviews. Unlisted dispatch plugins and scheduled exports often represent dependencies that an asset schedule misses.
• 3. Critical workflow walkthrough. Witness order entry, dispatch assignment, proof-of-delivery capture, rating, invoicing and settlement. Capture the handoffs and manual spreadsheets. Record which people or credentials are necessary to complete each workflow during an ordinary operating shift.
• 4. Identity administration. Identify ownership of directory tenants, privileged accounts, recovery contacts and administrator roles. Request an access report and demonstrate an approved recovery path. Do not revoke seller administrators before the buyer has tested its own delegated access.
• 5. Hosting control. Confirm who owns cloud accounts, physical servers, virtual machines, backups and billing relationships. Inspect an authorized console or contract. Record accounts that cannot transfer and the lead time needed to establish replacement hosting with equivalent controls.
• 6. Network dependencies. Map terminals, dispatch connectivity, remote access, DNS and integration routes. Test access from the intended buyer environment. A working seller office connection does not establish that the acquired terminals can reach systems after network separation.
• 7. Support coverage. Review vendor support terms, escalation contacts, unresolved incidents and renewal dates. Interview the people who resolve overnight failures. Identify coverage gaps created by personnel departures, transaction announcements or a change in the contracting legal entity.
• 8. Recovery demonstration. Select a critical application and witness restoration into an isolated environment. Record recovery duration, restored data boundary, missing secrets and application usability. A backup success notification alone cannot establish that dispatch can resume from the saved data.

Database integrity and financial reconciliation: checks 9 through 16

• 9. Database ownership and engine. Record platform, version, edition, support status, instance owner and permitted access methods. Match the live environment to vendor support documentation. Identify custom objects and undocumented administrator changes that could complicate an upgrade or migration.
• 10. Key integrity. Test representative customer, order, movement, stop and invoice relationships. Count duplicate business identifiers and orphaned children within the reviewed scope. Preserve exceptions rather than repairing seller records during diligence, which could alter the evidence under review.
• 11. Open order control. Reconcile open dispatch work by company, terminal and operating status. Sample changed appointments, canceled orders and split movements. Confirm that the buyer receives the references and documents required to continue the actual shipments at closing.
• 12. Receivables control. Tie open invoices to an agreed accounting cutoff, by legal entity and currency. Sample unapplied cash, credits, disputed accessorials and aged balances. Record timing differences separately from missing invoices or transactions assigned to the wrong customer.
• 13. Driver settlement control. Reconcile pending pay, advances, deductions and settlement exports with payroll or contractor systems. Identify approval ownership and posting boundaries. Ask finance and payroll specialists to assess disputed items rather than treating a database balance as an accepted liability.
• 14. Historical financial lineage. Trace selected posted amounts back to source orders, rates and documents. Confirm which history remains in an archive or seller-owned accounting service. A summary balance can transfer while the evidence needed to explain it remains inaccessible.
• 15. Data extraction test. Produce an approved, protected sample export with schema, timestamps, key definitions and a manifest. Reconcile its counts against the source boundary. Record fields unavailable through supported interfaces and obtain a realistic cost for extracting them.
• 16. Retention and deletion controls. Inventory retention schedules, legal holds, archives and automated purge jobs. Identify who can approve changes. Confirm that a planned system shutdown will preserve required records without retaining unrelated seller data beyond the transaction's authorized scope.

ELD and safety evidence: checks 17 through 24

FMCSA guidance states that carriers must retain ELD records of duty status and supporting documents for six months and keep the backup separately from the original storage. It also emphasizes driver privacy. Confirm the current obligations with safety leadership for the actual transaction; this duration is not a universal retention rule for every safety or personnel record. Use the FMCSA ELD retention guidance as a starting reference and document any longer applicable hold or contract requirement.

• 17. ELD provider and device inventory. Record provider, device model, vehicles, account ownership and contract contacts. Have safety verify the relevant registration status and operational suitability. Distinguish the software account transfer from moving physical devices or changing carrier identifiers.
• 18. Historical RODS retrieval. Witness an authorized export for a selected driver and date range. Verify readability, identity association and timestamps. Record whether historical access survives account closure, reassignment of vehicles or termination of the seller's vendor subscription.
• 19. Supporting-document retrieval. Sample dispatch records, trip documents and other applicable supporting evidence with safety leadership. Check that the document links survive an export. A file count does not prove that the buyer can associate records with the right driver and period.
• 20. Separate backup evidence. Inspect where ELD backups reside and demonstrate authorized retrieval. Identify retention settings, access controls and dependence on the same vendor account. Record whether a closing-related account change can remove access to both primary records and backup copies.
• 21. Unidentified driving review. Inspect the exception queue, review procedures and sample annotations with the safety owner. Record unresolved items and their evidence without editing history. Require a responsible person to assess their significance and document the preclosing or postclosing disposition.
• 22. Edits and certifications. Review the available audit trail for selected corrections and driver certification workflows. Verify that exports preserve the context needed to explain changes. Escalate missing history to safety leadership instead of interpreting an empty screen as proof of clean records.
• 23. Malfunction continuity. Request the current malfunction reporting procedure and demonstrate how dispatch and safety obtain records during a provider outage. Identify training materials and responsibility for follow-up. Include a scenario where both a terminal connection and the normal administrator are unavailable.
• 24. Driver privacy and permissions. Review which roles can view, export or modify driver-related records. Test a least-privilege role where authorized. Plan access for diligence, transition and steady operation separately, including secure transfer and disposal of temporary review copies.

Software rights and commercial exposure: checks 25 through 32

• 25. Executed license agreements. Collect the signed agreements, amendments, order forms and product schedules for each critical system. Compare the licensed customer entity with the transaction perimeter. Sales summaries and renewal invoices are insufficient evidence of the buyer's intended usage rights.
• 26. Assignment and change-of-control review. Ask counsel to interpret relevant clauses and identify required consents. Track requests, written responses and deadlines. Do not assume an asset transfer or common ownership automatically transfers the right to run software under an existing license.
• 27. License metric reconciliation. Compare deployed users, vehicles, terminals, servers and modules with the actual contract metrics. Request a defensible inventory. Record potential overdeployment for commercial review without inventing an exposure estimate before the agreement and vendor position are understood.
• 28. Renewal and termination schedule. Inventory renewal dates, notice windows, minimum commitments and cancellation requirements. Include hosting, EDI networks, telematics and document services. Build a transition calendar so an overlooked automatic renewal does not create an avoidable overlap or service interruption.
• 29. Third-party components. Identify database, reporting, mapping, document capture and integration components licensed separately from the main TMS. Review the entitlement evidence and deployment scope. A valid core application license does not establish rights to every connected tool or runtime.
• 30. Custom code rights. Collect repository access, development agreements, source ownership terms and build instructions for carrier-specific extensions. Have counsel review the rights. Demonstrate that an authorized engineer can produce the application from the supplied source without depending on a departed developer's laptop.
• 31. Vendor balances and service holds. Ask finance and procurement to verify unpaid invoices, disputes, support restrictions and conditions for reinstatement. Obtain written confirmation where material. A functioning service during diligence can still face interruption if a commercial hold takes effect near closing.
• 32. Exit and data access rights. Review export services, formats, fees, assistance windows and posttermination access. Test the practical export path. Compare contract promises with the data actually available, and identify whether an archive license or transition agreement is needed before canceling subscriptions.

Integrations and transition execution: checks 33 through 40

• 33. Trading partner inventory. List shippers, brokers, EDI networks, message types, endpoints and operational contacts. Trace representative 204, 214 and 210 traffic. Identify partners that require recertification or new identifiers when the contracting or operating carrier changes.
• 34. Message reconciliation. Sample raw receipts, acknowledgments, business posting and outbound delivery evidence. Inspect oldest unresolved failures. Determine whether the buyer can replay selected messages without creating duplicate orders, shipment events or invoices after the transfer of integration ownership.
• 35. Credential and certificate ownership. Inventory integration secrets, API subscriptions, signing certificates and expiry dates without exposing secret values in the diligence report. Assign rotation ownership and sequence changes so replacement access is tested before old credentials are retired.
• 36. Customer and location crosswalks. Compare the seller's customer, shipper, consignee and terminal identifiers with the buyer's model. Test ambiguous names and reused references. Keep a governed mapping ledger so consolidating systems does not send an invoice or status update to the wrong party.
• 37. Day-one operating boundary. State which TMS, accounting system, document store and safety platform are authoritative immediately after closing. Define temporary interfaces and manual handoffs. Avoid a partial migration in which both systems can independently dispatch or invoice the same shipment.
• 38. Transition service dependencies. Document any seller-provided hosting, administration, reporting or support required after closing. Assign service measures, access boundaries, escalation contacts and exit criteria through the transaction team. Test the service path rather than relying solely on the transition schedule.
• 39. Cutover rehearsal. Perform an isolated rehearsal using representative orders, financial documents and message fixtures. Record sequence, duration, acceptance evidence and failed steps. Include a stop decision and demonstrate how work created after the switch would be preserved if recovery is required.
• 40. Remediation ownership and funding. Convert findings into dated actions with named owners, budget assumptions and acceptance tests. Obtain transaction-team decisions on closing conditions, temporary controls and deferred work. Leave unresolved evidence requests explicit so they cannot disappear into a generic integration project.

Turn findings into transaction decisions

Use consequence and timing to prioritize findings. A missing dispatch recovery path may threaten day-one operations; an uncertain license consent may require a preclosing decision; a reporting cleanup may be scheduled after stabilization. Estimate the cost of remediation from the actual environment, including vendor assistance, overlapping subscriptions, internal staff, testing and historical access. Keep estimates as ranges with assumptions. Do not convert a technical concern directly into a purchase-price adjustment without finance and transaction-team review.

Present the decision package with the finding ledger, dependency map, entitlement register, recovery evidence and transition plan. For each material issue, state the observed fact, the operating consequence, proposed options and the person who must decide. Distinguish an accepted temporary control from a completed remediation. After closing, reconcile the transferred evidence and access against the agreed inventory before declaring the handover complete. Strong Tower Consulting's carrier acquisition advisory can organize this technical review alongside the buyer's existing specialists.

Use the companion legacy TMS SQL guide for financial data lineage and EDI implementation blueprint for message continuity. Plan the longer-term operating model with fractional freight CIO advisory. The checklist is a proposed diligence method, with no claim that its completion alone establishes compliance, resolves license liability or predicts the commercial success of an acquisition.

Frequently asked questions

Does this checklist certify acquisition compliance?

No. It organizes technical evidence and remediation. Counsel, safety leadership and commercial owners must assess obligations and transaction terms.

What makes an audit item complete?

A dated source artifact, a named owner, a reproducible test, a recorded finding and an accepted disposition make an audit item reviewable.

Scott Elliott, Founder and Principal Systems Architect. Scott Elliott, Founder and Principal Systems Architect, Strong Tower Consulting, LLC. Minnesota SOS filing 2948628-2. Continuous commercial operation since July 29, 2008. The firm name comes from Proverbs 18:10.