How Kelviz Prevents Duplicate Toll Imports

Toll providers often produce overlapping exports — a host re-downloads the latest 30, 60, or 90 days repeatedly to catch late-posting transactions, which means most rows in a new file have usually already appeared before. Without duplicate controls at import time, the same crossing can enter reconciliation, and eventually guest billing, more than once. This is the import-level half of the problem; see How to Prevent Duplicate Toll Charges in a Turo Fleet for the operational habits that complement it.

What an import report should actually separate

Total rows, newly accepted rows, duplicate rows, rejected rows, completion or failure status, and the source file and import time. In one real operating example, a large overlapping export contained hundreds of already-seen rows against only a handful of genuinely new tolls — that ratio is one fleet's data on a specific date, not a customer average, but it's representative of why the distinction matters at all.

Rejected isn't the same thing as duplicate

A duplicate is usually a valid transaction that's already in the system. A rejected row is missing or contains invalid information — it needs a reason and a correction path, not silent deletion that leaves someone wondering where a transaction went.

Import-level detection is only half the control

Catching a duplicate transaction at import time doesn't by itself stop one already-accepted transaction from being attached to two separate reimbursement cases later — see How to Handle a Duplicate Turo Reimbursement Request for that billing-level safeguard. Kelviz applies both: import-level duplicate detection against prior uploads, and a case-level check before a transaction goes onto a second invoice.