Strong Tower Consulting Enterprise Systems Case Studies: How the Work Is Done

How to read these engagement patterns

Strong Tower Consulting, LLC is an independent systems architecture and technology advisory firm founded in Minnesota in 2008 by Scott Elliott. For more than 18 years it has worked with motor carriers, freight brokers, private fleets, and enterprise clients on the systems that move freight and money: the TMS, EDI with trading partners, driver settlement, rate and tariff tables, accounting integration, SQL data, ELD and telematics feeds, and applied AI.

Buyers often search for case studies to answer one question: what will actually happen if we bring this firm in? A published result from someone else's fleet does not answer that well, because every carrier's data, contracts, and staff are different. A clear description of the method does. So each pattern on this page is written the same way. It names the typical problem, lists the diagnostic steps Strong Tower Consulting runs, describes the deliverables, and states what the client team owns after the engagement ends.

The patterns are anonymized on purpose. They describe recurring situations, not a particular company. If one of them sounds like your operation, that is the point: it shows where the work would start.

The Strong Tower Consulting engagement lifecycle

Every pattern below runs through the same lifecycle. The order matters. Nothing changes in production until the findings have been read and agreed to by the people who will own the fix.

Pattern: TMS optimization and configuration review

Typical problem. The TMS was configured years ago, the business has changed, and staff now work around the system. Rate tables have duplicate or expired rows, accessorial codes overlap, and reports disagree depending on who runs them. People trust spreadsheets more than the system of record.

Diagnostic steps. Strong Tower Consulting maps the order-to-cash flow as people describe it, then traces sample loads through the database to see where manual steps enter. The review lists rate and accessorial rows with no recent use, codes that mean the same thing, and fields that are filled in by habit rather than by rule. It also identifies reports whose logic is undocumented.

Deliverables. A configuration findings document, a cleaned list of rate and accessorial codes with a proposed retirement plan, a short list of reports to rebuild against documented logic, and a prioritized change list. Where a TMS change is larger than configuration, the findings connect to the TMS implementation or TMS data migration practice.

What the client owns afterward. The code lists, the rule documentation, and the review calendar. A named person approves new rate or accessorial codes so duplicates do not return.

Pattern: EDI 204, 990, 214, and 210 rebuild

Typical problem. Trading partner maps grew one partner at a time. Load tenders (204) arrive and are answered (990) late or not at all, status messages (214) miss milestones, and freight invoices (210) are rejected or never sent for loads that delivered. Each partner has its own exceptions that live in one person's head.

Diagnostic steps. Strong Tower Consulting pulls the transaction logs and pairs every 204 with its 990, every delivered load with its final 214, and every delivered load with its 210. Unpaired transactions become the findings list. The team also compares each partner map to the partner's published implementation guide and records where they differ.

-- Delivered EDI loads with no accepted 210
SELECT l.load_id, l.customer_id, l.delivered_at
FROM loads l
LEFT JOIN edi_210_invoices i
  ON i.load_id = l.load_id AND i.ack_status = 'ACCEPTED'
WHERE l.status = 'DELIVERED'
  AND l.bill_via_edi = 1
  AND l.delivered_at < DATEADD(day, -3, CAST(GETDATE() AS date))
  AND i.load_id IS NULL;

-- Accepted 210s with no delivered load behind them
SELECT i.invoice_no, i.load_id, i.total_charge
FROM edi_210_invoices i
LEFT JOIN loads l
  ON l.load_id = i.load_id AND l.status = 'DELIVERED'
WHERE i.ack_status = 'ACCEPTED'
  AND l.load_id IS NULL;

Deliverables. Rebuilt or corrected partner maps, a mapping document per partner, the pairing queries for 204 to 990, load to 214, and load to 210, and an exception queue design so unpaired transactions surface every day. Related reading: the EDI 204, 990, 214, and 210 implementation guide and the ELD and EDI integration practice.

What the client owns afterward. The partner mapping documents, the daily exception queue, and the pairing queries. A named billing lead clears the 210 queue, and a named operations lead clears missing 214 milestones.

Pattern: driver settlement audit

Typical problem. Drivers and owner-operators dispute statements, the settlement desk makes manual adjustments every week, and nobody can show how a deduction got on a statement. Escrow balances drift, and the statement does not always match the ledger.

Diagnostic steps. Strong Tower Consulting recomputes a sample of past settlements from source records: trips, accessorial pay, fuel-card files, the deduction schedule, advances, and escrow. Each line on the statement is traced to a source document. Lines with no source, deductions with no authorization, and escrow balances that do not follow the balance equation become findings.

Deliverables. A findings report with each failing line and its source, a deduction schedule with approvals, an escrow balance check, and a weekly close checklist. The full method is described in the driver settlement deduction audit guide.

What the client owns afterward. The deduction schedule, the allow list of people who may add a one-time deduction, and the weekly close checklist. A named settlement lead signs off before statements are published.

Pattern: accounting GL integration and SQL data cleanup

Typical problem. Revenue and expense in the TMS do not tie to the general ledger at month end. Customer and vendor records are duplicated across systems, GL account mappings were set up by hand, and the close depends on journal entries that "make it tie." Underneath, the SQL data has orphaned rows, inconsistent codes, and slow reports.

Diagnostic steps. Strong Tower Consulting reconciles TMS invoice and settlement totals to GL postings by period and account, lists every unmapped or manually mapped code, and profiles master data for duplicates. The SQL review covers orphaned records, missing keys, and the queries behind the reports finance relies on. See the transportation accounting integration and SQL data mining practices.

Deliverables. The GL mapping document, the tie-out queries, a master data cleanup plan with the corrections log, and tuned or rewritten report queries where performance or logic was the problem.

What the client owns afterward. The mapping document and the month-end tie-out. A named controller approves new codes before they post, and the corrections log stays with the client's data team.

Frequently asked questions

Published October 23, 2026 by Strong Tower Consulting, LLC. Founded 2008 in Minnesota by Scott Elliott.