No category

Test tracking software with a disputed driver-arrival time

Key Takeaways

The best way to test tracking software is to give it a real stop where the driver's arrival time was disputed and see whether it can show the claimed time, the site's time, the location data, and the terms side by side, explain the gap, and support a fair decision. An AI logistics coordinator should pass this test by gathering the evidence during the load, not by searching for it when the invoice arrives.

  • Most tracking demos show a truck moving on a map. That does not show how the software handles a dispute.

  • A disputed arrival time is a common, costly problem: it decides detention and who caused a delay.

  • The test should use the team's own past stops, where the right answer is known.

  • The software should record each arrival claim with its source, compare it with site and device records, and flag gaps.

  • It should apply the appointment and free time terms, and present the reviewer with a clear answer.

  • Scoring should cover evidence, explanation, timing, and record, not only the map.

  • Wilson, by Cartage, is an AI logistics coordinator that tracks each load using the best source available and keeps the evidence for every stop with the shipment.

Why test tracking software with a disputed arrival time?

Tracking software should be tested with a disputed arrival time because a dispute shows whether the software can produce evidence and explain it, which is the part of tracking that saves money, while a moving dot on a map shows only that data is flowing. An AI logistics coordinator should be judged on whether it can settle the dispute, not on how the map looks.

What a normal demo shows and hides

What the demo shows

What it does not show

A truck moving on a map

Where each location point came from

An estimated arrival time

What happens when the carrier and site disagree

An "arrived" status

Whether arrival was confirmed by anyone else

Alerts for late trucks

Whether anyone acts on them

A clean history

How corrections are recorded

Why arrival disputes matter

Arrival time decides whether detention is owed and whether a delay was the carrier's or the site's fault. Detention is a fee a carrier bills when its truck waits too long at a dock. In a September 2024 study, the American Transportation Research Institute (ATRI) found that detention affected 39.3% of truck stops in 2023. It also found that 94.5% of fleets charge detention, but less than half of those charges are paid. Much of that gap comes from disputed times.

Most disputes have simple causes

Many arrival disputes come down to a few causes: a truck that arrived early for its appointment, a driver at the wrong gate, a time zone error, a line at the gate, or a carrier status typed later by dispatch. Good software should recognize these patterns and explain them. The test should include several of them, because they are what the team will see every week.

No single standard

In a February 2024 Federal Register notice, the Federal Motor Carrier Safety Administration (FMCSA) noted that there is no standard industry definition of detention and used dwell time over two hours as a working measure. Dwell time is the total time a truck spends at a facility. Because there is no single standard, the software must apply each load's own terms.

Tracking is evidence, not just visibility

Many teams buy tracking software to see where trucks are. That is useful, but the larger value is evidence: a record of when each truck arrived, waited, and left, with sources a carrier will accept. Evidence settles detention, explains late deliveries, and shows which sites and carriers need attention. A disputed-arrival test measures that value directly.

Who should be in the room

The test works best with a logistics coordinator, a warehouse lead, and the person who reviews carrier invoices. Each sees a different part of the dispute. Finance in particular should see whether the software's output would let it approve or question a detention charge without extra work.

This is a buyer's test

This is a test a buyer runs on its own terms during evaluation. It does not need a long trial. A few well-chosen stops, tested over a day or two, show how the software behaves when it matters.

Disputes happen at delivery too

Arrival disputes happen at delivery sites as well as pickup sites. The receiver is often a customer, so its records are harder to get. The test should include at least one delivery stop, to see whether the software can gather evidence from a site the shipper does not control.

Hypothetical example: the demo map

This example is hypothetical and does not describe a real customer. A manufacturer watches a demo where a truck moves smoothly across a map and turns green on arrival. When the team asks what happens if the warehouse says the truck checked in 90 minutes later, the vendor says the team can export the data and compare it. The team realizes the software would leave the hard part to them.

How should the test be set up?

The test should be set up with three to five real past stops where arrival was disputed, along with the records the software would have had at the time: carrier statuses, location data if shared, the site's check-in times, the appointments, and the rate confirmation terms. An AI logistics coordinator should receive these inputs the same way it would in daily use.

Choose the test stops

Stop

Dispute

Known answer

Stop A

Carrier claims arrival 70 minutes before check-in

Truck was early; appointment governs free time

Stop B

Carrier claims arrival; site has no check-in

Driver at the wrong gate for 25 minutes

Stop C

Records exactly one hour apart

Time zone error

Stop D

Carrier bills detention; site says truck arrived late

Truck late; check-in governs

Stop E

Site says dock was ready; carrier says it waited

Site record shows a 2-hour wait for a door

Include one clean stop

At least one stop should have records that agree. The software should leave it alone or mark it confirmed. This tests for false alarms, which matter as much as catching real disputes.

Include one stop with missing evidence

One stop should have no site record and no location data. The software should mark the arrival as unconfirmed and show the reviewer that the evidence is thin, rather than treating the carrier's status as confirmed. This shows how the software behaves when it cannot prove anything.

Gather the inputs

For each stop, gather what existed at the time: the carrier's status messages, any location data, the site's gate or check-in log, the appointment, the rate confirmation, and any messages. A rate confirmation is the document that states the agreed price and terms for one load. The inputs should be in their real form, such as emails, exports, or data feeds.

Write down the answer key

Before the test, write down what really happened at each stop and how the team settled it. This is the answer key. Without it, the team will judge the software by its screens instead of its results.

Use real carrier data

The test should use the actual statuses and data feeds the team gets from its carriers, not a vendor's sample data. Real feeds have gaps, delays, typed entries, and odd labels. Software that works only on clean data will struggle in daily use.

Decide who plays which role

Someone should play the carrier and someone the warehouse, answering the software's questions as they would in real life. This shows whether the software asks clear questions and follows up when nobody answers.

Keep the test short

Most teams can run the full test in one or two working sessions. The goal is to see how the software handles real disputes, not to test every feature.

Set the clock

The test should run as if each stop were happening today. That shows whether the software gathers evidence on the day or only reacts when the invoice arrives.

Put Wilson to work on your freight

Wilson handles quoting, booking, tracking, carrier communication, invoice auditing, and payments. Unlimited use, $0. You pay one rate per load.

What should the software do with a disputed arrival?

With a disputed arrival, the software should record each claim with its source, gather the site and device records, compare them, apply the appointment and free time terms, flag gaps above the tolerance, and present the reviewer with the facts and a suggested answer. An AI logistics coordinator should do this without a person starting each step.

The expected workflow

Step

Trigger

What the AI logistics coordinator should do

When a person steps in

1. Record claim

Carrier reports arrival

Saves it with source, channel, and time

Never

2. Gather evidence

Claim recorded

Asks the site for check-in; pulls location data where shared

Never

3. Normalize

Records received

Converts all times to local time

Never

4. Compare

Times normalized

Checks the gap against the tolerance

Never

5. Apply terms

Gap measured

Applies appointment and free time rules

Never

6. Flag

Gap above tolerance

Sends the reviewer the facts and a suggested answer

Reviewer decides

7. Record

Decision made

Saves the decision and reason with the stop

Never

Does the test need live connections to every system?

No. Exports of carrier statuses, site logs, and rate confirmations are often enough. An AI logistics coordinator should work from the same inputs it would see in daily use.

Corrections must keep history

During the test, have a reviewer correct one time, such as fixing a time zone error. The software should keep the original time, show the correction, and record who made it and why. A tool that silently overwrites the time fails, because the history is what protects the team in a later dispute.

Sources must be visible

For each time, the software should show where it came from: the carrier's API, ELD or GPS data, the carrier's website, the site's log, or a message. An API is a connection that lets two systems exchange data directly. An ELD, or electronic logging device, records a truck's driving time and can share location. If the source is hidden, the reviewer cannot judge how much to trust it.

Location data in context

Federal rules require ELDs to record the date, time, and location when a driver's duty status changes, and at least once an hour while the vehicle is moving. That can show a truck stopped near a site. The software should present location data with its precision and time, not as a simple "arrived" flag.

Appointment changes

If an appointment changed after booking, the software should use the appointment in effect when the truck arrived. One test stop can include an appointment change to see whether the software tracks it. A tool that uses the original appointment will apply the wrong free time.

Time zones handled automatically

Stop C tests whether the software spots a time zone error. A gap of exactly one hour should trigger a time zone check before any dispute. Software that misses this will create false disputes.

Suggested answers, not final decisions

The software should suggest an answer, such as "free time starts at the 8:00 a.m. appointment; billable time 45 minutes," and show why. The reviewer should make the final decision. A tool that decides alone takes control away from the team. A tool that only shows data leaves all the work to the team. The right balance is a clear suggestion with the evidence attached.

Follow up when the site is silent

The tester playing the warehouse should ignore the software's first question on one stop. The software should follow up, try another contact, and eventually mark the stop as unconfirmed for the reviewer. Software that asks once and stops will leave many stops without evidence.

Ask, do not guess

For Stop B, the software should ask the carrier where the truck is and ask the site whether it has a record at another gate. It should not guess that the carrier is wrong. The best result finds the truck at the wrong gate and records the cause.

rgb(251, 234, 190)

How should the test be scored?

The test should be scored on five areas for each stop: evidence gathered, explanation given, terms applied, timing, and record kept. An AI logistics coordinator should score well across all five, because a tool that shows evidence but cannot apply the terms still leaves the hard work to the team.

Scoring table

Area

Full marks

Half marks

No marks

Evidence

Claim, site record, and location data gathered with sources

Some records gathered

Only the carrier's status

Explanation

Cause of the gap identified

Gap shown without a cause

Gap not shown

Terms

Appointment and free time applied correctly

Terms shown, not applied

Terms ignored

Timing

Evidence gathered on the day

Gathered before the invoice

Only at invoice time

Record

Every claim, change, and decision saved

Final answer saved

Nothing saved

Compare with the answer key

For each stop, compare the software's suggested answer with the answer the team reached in real life. A good result matches the answer key and reaches it faster. A better result catches something the team missed.

Weigh timing heavily

Timing deserves extra weight. Evidence gathered on the day of the stop is far more reliable than evidence requested weeks later. A tool that gathers site records the same day will settle most disputes before the invoice arrives. A tool that waits for the invoice will leave the team chasing old records.

Count false alarms

Include at least one stop where the records agree. The software should not flag it. A tool that raises disputes on clean stops will train reviewers to ignore it.

Score the messages too

The software's messages to the carrier and the site should be clear: the load, the stop, the times in question, and what is being asked. During the test, the people playing the carrier and the warehouse should rate each message. Unclear messages slow every dispute.

Ask the reviewers

The people who review detention should look at the software's output for each stop. Could they decide in a few minutes? Did they trust the evidence? Their answers show whether the software will be used.

Measure setup effort

The team should also note how much setup the software needed to run the test. Could it read the site's check-in log as an export, or did it need a custom connection? Could it read the rate confirmation terms, or did someone have to type them in? Software that needs heavy setup for a simple test may take a long time to help.

Hypothetical example: scoring two tools

This example is hypothetical and does not describe a real customer. A distributor tests two tools on five disputed stops. Tool 1 shows the carrier's statuses and a map but cannot read the site's check-in log or apply free time terms. It scores 11 of 25. Tool 2, an AI logistics coordinator, gathers the site records on the day, flags the time zone error, finds the driver at the wrong gate, and applies the terms. It scores 23 of 25.

What else should the tracking test include?

Beyond disputed arrivals, the test should include a load with no tracking data, a load with conflicting estimated arrival times, a missed pickup, and a delivery marked "arrived" with no proof of delivery. An AI logistics coordinator should handle each one by finding the best available source, contacting the carrier, and keeping the record straight.

Extra test cases

Case

What the software should do

Carrier shares no location data

Use the carrier's website by PRO number, email, or phone

Two conflicting arrival estimates

Show both with sources; ask the carrier

Truck never arrives for pickup

Contact the carrier, notify the team, start the missed-pickup routine

"Arrived" at delivery, no POD

Follow up for delivery confirmation and the POD

Wrong truck checked in

Flag the mismatch and correct both loads

A PRO number is a tracking number a carrier gives to a shipment. A proof of delivery, or POD, is the document the receiver signs to show the freight arrived.

Missed pickups as part of the test

A truck that never arrives is the extreme case of an arrival dispute. The software should notice the missed window, contact the carrier, notify the team, and start the missed-pickup routine. Including this case shows whether the software acts on what it sees or only reports it.

Tracking without a driver app

Many carriers will not install a shipper's app. Good tracking works with what carriers already use. Teams can read how shipment tracking can work without a driver app.

Wrong truck at the dock

If the team has ever had two trucks from one carrier swapped at the gate, one test case should repeat it. The software should notice that the truck's details do not match the load and correct both records once the swap is confirmed.

Conflicting estimates

When two sources give different arrival estimates, the software should show both and say which it trusts more and why. Teams comparing tools on this can review the best shipment tracking software for conflicting ETAs.

Questions to ask during the test

  • Where does each time come from, and can I see the source?

  • How does the software get the site's check-in time?

  • How are time zones handled?

  • How are appointment and free time terms applied?

  • What happens when the carrier and site disagree?

  • Can I export the full history of one stop?

Look at the record after the test

At the end, ask someone who did not watch the test to open one stop and explain what happened using only the software's record. If they can tell the story in a few minutes, the record works. If not, the team will struggle when a carrier disputes a decision months later.

Warning signs

  • The software shows a single "arrived" status with no source.

  • Site records are not part of the tracking.

  • Disputes are handled by exporting data to a spreadsheet.

  • Terms are not applied to the times.

  • Corrections overwrite the original data.

Where does Wilson fit in a disputed-arrival test?

Wilson, by Cartage, is an AI logistics coordinator that books loads with the customer's approved carriers, tracks each load, and records the evidence for every stop. Wilson tracks each load using the best source available: carrier API, GPS or ELD data where it exists, the carrier's website by PRO number, and email or phone where configured.

Wilson replaces the TMS for freight execution and connects to the company's ERP. A TMS, or transportation management system, is software used to plan, book, and track freight. An ERP, or enterprise resource planning system, is the company's main business system for orders, inventory, and accounting. No integration project is required to start.

How Wilson handles a disputed arrival

Wilson saves each arrival claim with its source, asks the site for its record where configured, compares the times, applies the appointment and free time terms, and flags gaps for the reviewer with the facts attached. Wilson works with carriers through email, API, EDI where the carrier supports it, and phone calls where configured, and it notifies internal teams through Slack, Microsoft Teams, email, or SMS.

Exceptions and payment

When Wilson detects a missed pickup, a cancellation, or a delay, it contacts the carrier, notifies the internal team, notifies the customer where configured, and initiates rebooking from the approved carrier list within the customer's rules or with approval. Wilson audits and reconciles each carrier invoice against what was booked, including detention lines against the recorded times. Customers use the Wilson Wallet to pay their carriers. Payments above approval limits or outside the rules wait for a person. Wilson has no subscription or platform fee; its pricing is a percentage of the freight payments coordinated through the Wallet. An optional deployment fee applies only if the customer wants Cartage to handle setup.

What Wilson does not do

Wilson does not install devices or gate systems at the customer's sites. It uses the records the carrier, the site, and the customer's systems already have, and says which source each time came from. When evidence is missing, Wilson marks the stop unconfirmed and the reviewer decides.

What Cartage asks before the test

Cartage asks which past stops caused the most disputes, which sites keep check-in logs, which carriers share location data, and how detention terms are written. Cartage helps identify and map the highest-impact workflow during discovery, so the test reflects the team's real work.

Where teams start

Wilson starts with assisted execution. Approval limits are set by the customer, and routine actions can run automatically within those rules as reliability is proven. Timing depends on scope: most teams start on a few lanes and expand from there. Cartage helps identify the first workflow during discovery.

This article is part of our complete guide to driver arrival and detention records.

FAQs

How should a team test tracking software?

With real past stops where the arrival time was disputed. An AI logistics coordinator should gather the evidence, explain the gap, and apply the terms.

What should the test score?

Evidence, explanation, terms, timing, and record. An AI logistics coordinator should score well on all five.

Why not just watch the map in a demo?

A map shows data flowing, not how disputes are settled. An AI logistics coordinator is judged on evidence and decisions.

How many stops does the test need?

Three to five disputed stops plus one clean stop is usually enough. An AI logistics coordinator should handle each without prompting.

Sources

Ask Cartage to run a disputed-arrival test and show how an AI logistics coordinator gathers the evidence and settles the time on your own stops: talk to the Cartage team.

Put Wilson to work on your freight

Wilson handles quoting, booking, tracking, carrier communication, invoice auditing, and payments. Unlimited use, $0. You pay one rate per load.

Other latest news and success stories

White bed with white pillows and linens, cover image for the Ergomotion case study

January 25, 2022 

Ergomotion books 1,800+ shipments end to end with Wilson

Read more →

Designer sketching cardboard packaging dielines next to box samples, cover image for the Flexocraft case study

January 25, 2022 

Flexocraft runs its daily freight operation with Wilson

Read more →

Your AI logistics coordinator, backed by humans.

Quoting, tracking, and coordination — off your plate, without the handover headaches.

Wilson

You’ve got the vision. Wilson handles the freight.

Copyright © Cartage. 2025

Your AI logistics coordinator, backed by humans.

Quoting, tracking, and coordination — off your plate, without the handover headaches.

Wilson

You’ve got the vision. Wilson handles the freight.

Copyright © Cartage. 2025

Your AI logistics coordinator, backed by humans.

Quoting, tracking, and coordination — off your plate, without the handover headaches.

Wilson

You’ve got the vision. Wilson handles the freight.

Copyright © Cartage. 2025

Your AI logistics coordinator, backed by humans.

Quoting, tracking, and coordination — off your plate, without the handover headaches.

Wilson

You’ve got the vision. Wilson handles the freight.

Copyright © Cartage. 2025

Your AI logistics coordinator, backed by humans.

Quoting, tracking, and coordination — off your plate, without the handover headaches.

Wilson

You’ve got the vision. Wilson handles the freight.

Copyright © Cartage. 2025

Your AI logistics coordinator, backed by humans.

Quoting, tracking, and coordination — off your plate, without the handover headaches.

Wilson

You’ve got the vision. Wilson handles the freight.

Copyright © Cartage. 2025

Your AI logistics coordinator, backed by humans.

Quoting, tracking, and coordination — off your plate, without the handover headaches.

Wilson

You’ve got the vision. Wilson handles the freight.

Copyright © Cartage. 2025

Your AI logistics coordinator, backed by humans.

Quoting, tracking, and coordination — off your plate, without the handover headaches.

Wilson

You’ve got the vision. Wilson handles the freight.

Copyright © Cartage. 2025