How Kelviz Matches Toll Transactions to Turo Reservations

Kelviz matches a toll transaction to a Turo reservation by comparing the vehicle information in the toll record with whichever reservation was active at the transaction time. Clear records match automatically; missing or conflicting information stays unresolved or lands in a review workflow instead of getting forced through. This is the mechanics behind the general process described in How Toll Reconciliation Actually Works — this article goes one level deeper into what the matching step itself is actually comparing.

The two datasets the match actually needs

Toll activity with a travel timestamp, amount, location, and plate or transponder — and reservation history with the vehicle and exact trip window. A toll statement alone doesn't identify the guest; a reservation export alone doesn't show the toll. The match happens when the vehicle identifier and time window line up between the two.

Import, normalize, then generate the match

Provider files use different column names, date formats, plate styles, and identifiers, so the import step standardizes the fields reconciliation actually needs — and duplicate or rejected rows stay visible rather than silently counting as new charges (see How Kelviz Prevents Duplicate Toll Imports). From there, Kelviz evaluates the plate or transponder and searches for the reservation that had that vehicle at the toll's travel time — checking historical assignments, not just the vehicle's current tag, since a transponder moving between vehicles is common in a real fleet.

Exceptions stay visible instead of getting forced

Not every record should be pushed into the nearest trip. Unmatched or uncertain tolls commonly trace back to a missing or unrecognized plate, an untracked transponder reassignment, reservation data that was never imported, a transaction outside every trip window, overlapping back-to-back trips, or genuine host/delivery/maintenance use.