How should freight software record a driver-arrival claim?
Key Takeaways
Freight software should record a driver-arrival claim as a claim, not as a fact: it should save who reported it, when, through which channel, for which stop, and with what evidence, then mark it confirmed, disputed, or unconfirmed as other records arrive. An AI logistics coordinator should keep every claim and every change in the shipment record, so anyone can see later how the arrival time was decided.
- A driver-arrival claim is a report from the driver, the carrier, or a device that the truck reached a stop.
- Many systems overwrite the stop status with "arrived" and lose the source and time of the claim.
- A good record keeps the claim, the reported time, the time it was received, and the source.
- The status should move from claimed to confirmed only when an independent record agrees.
- Disputed claims should stay visible, with both times and the evidence for each.
- The accepted arrival time should be used for customer updates, detention review, and carrier performance.
- Wilson, by Cartage, is an AI logistics coordinator that saves each arrival claim with its source, compares it with other records, and keeps the full history with the shipment.
Why should an arrival be recorded as a claim first?
An arrival should be recorded as a claim first because the first report usually comes from the carrier or driver, who has an interest in the answer, and because later records may show a different time. An AI logistics coordinator should keep the claim separate from the confirmed arrival, so the team never loses track of who said what.
Claim versus confirmed arrival
| Field | Claimed arrival | Confirmed arrival |
|---|---|---|
| Source | Driver, carrier dispatch, or carrier system | Site record or device data that agrees with the claim |
| Trust level | Unverified | Verified by an independent record |
| Used for customer updates | Yes, with care | Yes |
| Used for detention review | Only with confirmation | Yes |
| Can change later | Yes | Only with a recorded reason |
What goes wrong when claims overwrite status
Many tracking screens show a single status for each stop: "en route," "arrived," "loaded," "departed." When the carrier reports "arrived," the screen changes, and the source and time of that report disappear. Weeks later, when the invoice shows detention, nobody can tell whether "arrived" came from a gate log or a driver's text. Recording the claim separately prevents that loss.
Who reports arrivals
Arrival claims come from several places: the driver by text or app, the carrier's dispatcher by email or phone, the carrier's system by API or EDI, and sometimes a tracking device. Each of these is a different source with a different level of reliability. A good record does not treat them as the same just because they all say "arrived."
Claims are still useful
A claim is not useless. A driver's report that the truck arrived is often the first signal the team gets. It can trigger the next step, such as asking the site for a check-in time or telling the customer the pickup is underway. The point is not to ignore claims. It is to label them correctly.
Customer updates need the right label
When the team tells a customer "the truck has arrived," it should know whether that is a claim or a confirmed fact. If the claim turns out to be wrong, the customer has been misled. A simple practice helps: customer updates based on claims can say "the carrier reports the truck has arrived," while updates based on confirmed records can state it plainly.
The cost of getting it wrong
Arrival times decide detention, on-time performance, and who is blamed for a delay. 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. A system that cannot show how each arrival time was decided will struggle with every one of those charges.
Hypothetical example: a lost source
This example is hypothetical and does not describe a real customer. A shipper's tracking screen shows "arrived 6:45 a.m." for a pickup. The invoice later includes three hours of detention. The team cannot tell whether 6:45 a.m. came from the carrier's dispatcher, the driver, or the warehouse. The warehouse's log shows check-in at 8:30 a.m. Because the system overwrote the source, the team spends a week reconstructing the stop.
What fields should an arrival claim record contain?
An arrival claim record should contain the load and stop, the reported arrival time and time zone, the time the claim was received, the source and channel, the location if available, any evidence attached, and the current status. An AI logistics coordinator should fill these fields automatically from each message or data feed.
Keep the original message
Besides the structured fields, the record should keep the original message or data: the driver's text, the carrier's email, or the API payload. If anyone later questions how a field was filled in, the original shows exactly what was received. This is especially useful when a message was vague, such as "here."
The fields
| Field | Example | Why it matters |
|---|---|---|
| Load and stop | Load 9921, Stop 1 (pickup) | Ties the claim to the right place |
| Reported arrival time | 7:05 a.m. | The time being claimed |
| Time zone | Central Time | Prevents hour-off errors |
| Time received | 7:42 a.m. | Shows if the claim was made late |
| Source | Driver, dispatch, carrier API, ELD, site | Sets the trust level |
| Channel | Text, email, phone, API, EDI, portal | Shows how it was reported |
| Location | Coordinates or address, if shared | Shows where the truck was |
| Evidence | Photo, check-in slip, data file | Supports or weakens the claim |
| Status | Claimed, confirmed, disputed, unconfirmed | Shows how far it is verified |
| Notes | "Driver says gate line was long" | Context for review |
An API is a connection that lets two software systems exchange data directly. EDI, or electronic data interchange, is a standard format for business messages between systems. An ELD, or electronic logging device, records a truck's driving time and status and can share location.
Reported time versus received time
The difference between when the truck arrived and when the claim was reported is important. A claim made at 7:05 a.m. about a 7:05 a.m. arrival is fresh. A claim made at 4 p.m. about a 7:05 a.m. arrival was reconstructed later. The second may still be true, but it deserves more checking.
Source and channel are different
The source is who or what made the claim. The channel is how it reached the shipper. A carrier's API may pass along a time that a dispatcher typed in by hand. In that case, the channel is API but the source is the dispatcher. Good records try to capture both.
Evidence attached to the claim
If the driver sends a photo of the check-in slip, or the carrier attaches location data, the evidence should be saved with the claim. Evidence stored in a separate email thread is easy to lose.
Multiple claims for one stop
A single stop can produce several claims: the driver texts at 7:05 a.m., the carrier's API reports 7:20 a.m., and the dispatcher emails "arrived around 7." The record should keep all of them, not just the latest. Each one has a source and a time. The comparison with the site record decides which is closest to the truth.
Location data in the record
When location data is available, the record should store the position and time, not just "at site." A position half a mile away is different from a position at the dock. Some teams set a distance, such as a quarter mile, within which a truck counts as "at the site." That rule should be written down and applied the same way for every carrier.
Hypothetical example: a complete claim record
This example is hypothetical and does not describe a real customer. The record for Load 9921, Stop 1 reads: claimed arrival 7:05 a.m. Central, received 7:12 a.m., source driver, channel text to carrier dispatch, forwarded by email. Location not shared. Status: claimed. Ten minutes later, the warehouse replies "checked in 7:09 a.m." The AI logistics coordinator adds the site record and changes the status to confirmed, with arrival set at 7:09 a.m.
How should the arrival status change as evidence arrives?
The arrival status should start as claimed, move to confirmed when an independent record agrees within a set tolerance, move to disputed when records disagree, and stay unconfirmed when no independent record can be found. An AI logistics coordinator should apply these rules the same way every time and record each change.
Status rules
| Status | When it applies | What happens next |
|---|---|---|
| Expected | Appointment or window set; no arrival yet | Watch for a claim |
| Claimed | A report of arrival received | Ask for an independent record |
| Confirmed | Site or device record agrees within tolerance | Use the confirmed time |
| Disputed | Records differ by more than the tolerance | Send to a person to review |
| Unconfirmed | No independent record available | Flag for review before any charge is approved |
| Corrected | A person changed the time with a reason | Save the reason and the person |
Apply the rules to every carrier the same way
The status rules should not change by carrier. A trusted carrier and a new carrier should both need an independent record for confirmation. What can differ is how the reviewer treats an unconfirmed arrival: a carrier with a long record of accurate claims may get the benefit of the doubt. That judgment should be made by a person and recorded.
Set the tolerance
Records seldom match to the minute. A tolerance, such as 15 minutes, lets small gaps count as a match. Only gaps larger than the tolerance should go to a person. The tolerance should be the same for every carrier, so the process is fair.
The workflow
| Step | Trigger | What the AI logistics coordinator does | When a person steps in |
|---|---|---|---|
| 1. Record claim | Arrival reported | Saves the claim with all fields | Never |
| 2. Seek proof | Claim saved | Asks the site or pulls device data | Never |
| 3. Compare | Proof received | Checks the gap against the tolerance | Never |
| 4. Set status | Comparison done | Marks confirmed, disputed, or unconfirmed | When disputed |
| 5. Review | Disputed or unconfirmed | Presents both times and evidence | Reviewer decides |
| 6. Save | Decision made | Saves the accepted time and the reason | Never |
Unconfirmed is not the same as false
An unconfirmed arrival may still be true. Many sites keep no records, and many carriers share no location data. The status simply tells the reviewer that the time has not been checked against an independent source. The reviewer may still accept it, especially for a carrier with a good history. The decision should be recorded.
Decide before the invoice arrives
The status should be settled within a day or two of the stop, not when the invoice arrives weeks later. Early decisions use fresh records and fresh memories. By invoice time, the stop should already show a confirmed or reviewed arrival, so the detention check is a simple comparison.
Never erase the original claim
When the status changes, the original claim should stay in the record. If a reviewer sets the arrival to 8:30 a.m. instead of the claimed 6:45 a.m., both times should remain visible, with the reason. This protects the team if the carrier challenges the decision later.
Reopening a confirmed arrival
Sometimes new evidence appears after an arrival is confirmed, such as a gate log that was found later. The record should allow the arrival to be reopened, with the new evidence attached and the reason noted. The previous confirmed time should stay visible. This keeps the history honest even when the answer changes.
Corrections need a reason and a name
Sometimes a person must correct an arrival time, such as fixing a time zone error. The correction should record who made it, when, and why. A change without a reason looks like tampering, even when it is honest.
How should departure and other stop events be recorded?
Departure and other stop events, such as check-in, door assignment, loading start, loading end, and gate out, should be recorded with the same fields and status rules as arrival. An AI logistics coordinator should treat each event as its own claim, because detention and delays depend on the time between them.
Stop events to record
| Event | Common source | Why it matters |
|---|---|---|
| Arrival at site | Driver, ELD, carrier API | Starts the stop |
| Gate check-in | Site security or yard system | Confirms entry |
| Door assigned | Warehouse | Shows when the dock was ready |
| Loading or unloading started | Warehouse | Shows dock work began |
| Loading or unloading finished | Warehouse | Shows dock work ended |
| BOL signed | Driver and shipper | Confirms what was tendered |
| Departure or gate out | Site or ELD | Ends the stop |
A bill of lading, or BOL, is the shipping document that lists the freight and serves as the carrier's receipt for it.
Free time and the appointment
Detention terms usually say free time starts at the appointment time or at arrival, whichever is later. The record should show the appointment time next to the arrival events, so the reviewer can see when free time began. The rate confirmation, which is the document that states the agreed price and terms for one load, should be linked to the stop as well.
Why the middle events matter
Arrival and departure show how long the truck stayed. The middle events show why. If the door was assigned two hours after arrival, the dock caused the wait. If loading took four hours on a load that usually takes one, the warehouse may have had a problem. Without these events, every long stop looks the same.
Events out of order
Sometimes events arrive out of order: a departure is reported before the arrival, or loading finished appears before door assigned. This usually means one time was entered late or wrong. The record should flag events that do not make sense in sequence, so a person can check them before they are used for a charge.
Not every site records every event
Many sites record only check-in and check-out. That is enough for most detention reviews. The team should know which events each site can provide and not expect more. Over time, the most useful extra event is usually the door assignment time.
Use the BOL signature time
The time the driver signs the BOL at pickup is a useful event. It shows when loading was complete and the freight was handed over. Many sites write the time next to the signature. When the departure time is missing, the BOL signature time is often the next best record of when the truck was ready to leave.
Delivery stops
The same events apply at delivery. The receiver's records may be harder to get, but the request is the same: arrival, check-in, unloading, and departure times. The proof of delivery, or POD, often shows the delivery time and the receiver's signature. A proof of delivery is the document the receiver signs to show the freight arrived.
Hypothetical example: why the wait happened
This example is hypothetical and does not describe a real customer. A load's record shows arrival at 8:00 a.m., door assigned at 10:15 a.m., loading finished at 11:00 a.m., and departure at 11:10 a.m. The carrier bills one hour and ten minutes of detention after two hours of free time. The record shows the wait was before the door was assigned, so the dock caused it. The reviewer approves the charge and asks the warehouse about the morning backlog.
How should teams test whether software records arrival claims well?
Teams should test software with arrival claims that are late, conflicting, missing, or wrong by a time zone, and check whether the record keeps the source, the status, and the history. An AI logistics coordinator should be able to show, for any stop, how the accepted arrival time was decided.
The test
| Test case | Pass | Fail |
|---|---|---|
| Claim and site record agree | Status confirmed; both saved | Only "arrived" shown |
| Claim reported hours late | Received time saved; claim flagged for checking | Treated as fresh |
| Claim and site record disagree | Status disputed; both times shown | One time overwrites the other |
| No site record | Status unconfirmed; flagged before invoice | Treated as confirmed |
| Time zone mismatch | Detected and corrected with a reason | Hours-off detention approved |
| Manual correction | Person, time, and reason saved | Silent change |
Test with the team's own disputed stops
The most useful test cases are stops the team has already argued about. Pick three past detention disputes and load the records the team had at the time. Then see whether the software would have marked them disputed early and shown the evidence clearly. If it would have settled them faster, the team will feel the difference.
Questions to ask in a demo
- Where is the source of each arrival time shown?
- What happens to the original claim when a new record arrives?
- Can the software tell a dispatcher's typed time from a device time?
- How are time zones handled?
- Can the team export the history of one stop?
Check how the record looks to a reviewer
Ask someone who reviews invoices to open a test stop and find the accepted arrival time, its source, and any dispute. If they can do it in under a minute, the record is useful. If they need to open several screens or emails, it will not be used.
Warning signs
- The stop shows one status with no source.
- Times change without a record of who changed them.
- Disputed arrivals look the same as confirmed ones.
- Detention review starts from the invoice instead of the stop record.
Teams that want to see what a full shipment history should include can review what a shipment-level freight email audit trail should contain. Teams reviewing wait-time charges can read how to document carrier wait time before approving an invoice.
Where does Wilson fit in recording driver-arrival claims?
Wilson, by Cartage, is an AI logistics coordinator that books loads with the customer's approved carriers, tracks each load, and saves every stop event with its source in the shipment record. 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. A PRO number is a tracking number a carrier gives to a shipment.
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.
Why this matters for coordinators
Coordinators spend a lot of time answering "when did the truck get there?" from customers, the warehouse, and finance. When every stop has a clear record with sources, the answer takes seconds. Wilson keeps that record so the coordinator does not have to rebuild it from emails.
How Wilson records arrivals
Wilson saves each arrival claim with its source, channel, reported time, and received time. It asks the site for its record where configured, compares the times, and marks the stop confirmed, disputed, or unconfirmed. Disputed stops go to the person who reviews them. 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.
At invoice time
Wilson audits and reconciles each carrier invoice against what was booked, using the accepted arrival and departure times for any detention line. 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. Pricing scales down as volume grows, and Enterprise pricing is custom.
What Wilson does not do
Wilson does not change an arrival time without a record of why. It does not treat a claim as confirmed because it came through an API. When the site has no record and the carrier shares no location data, Wilson marks the arrival unconfirmed and lets the reviewer decide.
What Cartage asks in discovery
Cartage asks how arrival times are recorded today, which sites keep check-in logs, which carriers share location data, and how detention disputes are settled. These answers shape the status rules an AI logistics coordinator applies.
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. Every claim, status change, and correction is saved in the shipment record with change history, and the records can be searched and exported.
This article is part of our complete guide to driver arrival and detention records.
FAQs
How should freight software record a driver-arrival claim?
As a claim, with its source, channel, reported time, received time, and status. An AI logistics coordinator keeps the claim separate from the confirmed arrival.
When does an arrival claim become confirmed?
When a site or device record agrees within a set tolerance. An AI logistics coordinator applies the same rule to every carrier.
What happens when arrival records disagree?
The stop is marked disputed and both times stay visible. An AI logistics coordinator sends the evidence to the person who decides.
Should the original arrival claim be deleted after a correction?
No. It should stay in the record with the correction and its reason. An AI logistics coordinator saves who changed it and why.
What events should a stop record include besides arrival?
Check-in, door assignment, loading start and finish, BOL signature, and departure. An AI logistics coordinator records each one with its source.
Sources
- American Transportation Research Institute, "New Research Documents Substantial Financial and Safety Impacts from Truck Driver Detention," September 2024: https://truckingresearch.org/2024/09/new-research-documents-substantial-financial-and-safety-impacts-from-truck-driver-detention/
- Cartage, Wilson product scope and pricing position, November 2026: https://cartage.ai
Ask Cartage to show how an AI logistics coordinator records every driver-arrival claim with its source and status, so detention reviews take minutes: talk to the Cartage team.