Telematics data arrives looking authoritative: precise coordinates, exact timestamps, decimal fuel figures. That precision is not accuracy, and decisions built on unvalidated telematics data are frequently wrong in ways nobody notices for months.
The eight common defects
1. Position drift and jumps. Urban multipath produces positions tens of metres off, and occasionally hundreds. On a stationary vehicle, drift can accumulate into fictitious short trips.
2. Missing data during coverage gaps. Devices buffer and upload later, but buffer capacity is finite. Extended dead zones produce genuine gaps, and distance calculated across a gap is a straight line rather than the road actually driven.
3. Odometer discontinuities. Device replacement, vehicle repair, ECU replacement or a change from vehicle-read to GPS-derived mileage all produce steps in the odometer series. Left uncorrected, they corrupt cost per mile and maintenance scheduling.
4. Ignition and trip misdetection. Devices infer ignition from voltage or port data. Voltage-based detection can split one trip into three, or merge a stop into the drive, distorting both trip counts and dwell times.
5. Driver attribution errors. Where drivers are assigned to vehicles by roster rather than by identification, any deviation from the roster misattributes the entire day. Behaviour scores built on this are unfair and indefensible.
6. Threshold artefacts. Harsh event counts depend entirely on configured thresholds. A threshold change mid-year makes before-and-after comparisons meaningless, and this is rarely documented.
7. Timezone and daylight saving errors. Endemic. Symptoms include trips appearing to start before they ended, and shift analysis shifting by an hour twice a year.
8. Duplicate records. Retransmission after a failed upload can produce duplicated positions or trips, inflating distance and event counts.
Park a vehicle for a full weekend and look at the data. You should see no trips, no distance and no events.
Validation rules to run
Implement these as automated checks, ideally daily:
| Check | Flag when |
|---|---|
| Speed plausibility | Implied speed between consecutive points exceeds vehicle capability |
| Distance vs odometer | GPS distance and odometer delta diverge beyond tolerance |
| Trip duration | Below a minimum (likely misdetection) or implausibly long |
| Position accuracy | Reported HDOP or accuracy figure below threshold |
| Coverage gaps | Time between reports exceeds expected interval |
| Odometer monotonicity | Odometer decreases, or jumps beyond plausible |
| Duplicate detection | Identical timestamp and position for a device |
| Driver assignment | Vehicle in use with no assigned driver |
| Idling plausibility | Idling duration exceeding a shift |
Publish the exception counts alongside the reports they affect. A utilisation report with a note that 4% of records failed validation is far more trustworthy than one that silently includes them.
Cleaning approaches
Filtering. Discard positions below an accuracy threshold before computing distance. Simple and effective for drift.
Map matching. Snap positions to the road network. Substantially improves distance accuracy and route reconstruction, at some computational cost. Many platforms do this natively; ask whether yours does.
Interpolation across gaps. Estimate the route between the last position before a gap and the first after it, using the road network rather than a straight line. Flag interpolated segments so they are visible in reporting.
Odometer reconciliation. Maintain a corrected odometer series with documented adjustments at device changes. Never overwrite the raw series — keep both.
Trip stitching. Merge trips separated by very short gaps where ignition detection is unreliable.
Governance
- A single source of truth for distance. Decide whether reporting uses vehicle odometer or GPS-derived distance, document it, and use it consistently. Two teams using different sources will produce different cost per mile figures and spend months arguing.
- Document every threshold change with a date, so trend analysis can account for it.
- Reconcile monthly against an independent source — fuel card mileage entries, service records, physical readings on a sample.
- Own the data. Someone should be accountable for telematics data quality, in the same way someone owns financial data quality.
When it matters most
Data quality tolerance should match the decision:
| Use | Tolerance |
|---|---|
| Live dispatch view | High — approximate position is fine |
| Customer ETA | Moderate |
| Utilisation reporting | Moderate |
| Cost per mile | Low — errors compound |
| Maintenance scheduling | Low — wrong mileage means wrong intervals |
| Driver behaviour scoring | Very low — affects individuals directly |
| Billing customers | Very low — disputes are expensive |
| Legal or regulatory evidence | Very low — must be defensible |
The last three deserve explicit validation before use. Using unvalidated data to score, bill or discipline is how a telematics programme loses credibility permanently.
Questions readers send us
How accurate is telematics-derived mileage? With map matching and good coverage, typically within a small percentage of the true figure. Without map matching, in poor coverage, or with frequent gaps, errors can be considerably larger — which is why vehicle odometer readings are preferable where available.
Should we use vehicle odometer or GPS distance? Vehicle odometer where it is reliably available, because it is what maintenance intervals and legal records are based on. Use GPS distance as a cross-check and for vehicles where odometer access is unavailable. Document which you use for which purpose.
How do we handle device replacement in reporting? Record the change as an event with the odometer reading at swap-out and swap-in, and apply an explicit offset in your corrected series. Undocumented device changes are one of the most common causes of nonsense mileage reporting.
What accuracy should we demand from a vendor? Ask for their stated position accuracy, their map matching approach, their handling of coverage gaps, and their duplicate prevention. Then verify with a pilot rather than accepting the specification — real-world performance in your geography is the only figure that matters.
Is it worth building our own validation layer? If telematics data drives money — billing, scoring, cost allocation — then yes, a validation layer is proportionate. If it is used only for live visibility, the platform's own handling is usually sufficient.
