How to Investigate Rejected Toll-Import Rows

A rejected row is a different thing from a duplicate row. A duplicate is a transaction the system already has; a rejected row is one the system couldn't safely turn into a valid transaction at all — which means it needs a specific reason, not just a generic "failed" label.

Capture the actual rejection reason

Missing transaction time, invalid amount, an unknown or unsupported date format, a blank plate and transponder, a malformed row or shifted columns, an unsupported transaction type, a required header that's missing entirely, or a currency/encoding problem — each of these needs a different fix, so a generic "row failed" status isn't enough to actually act on.

Look for a pattern across the rejected rows

If every rejected row comes from the bottom of a statement, the export may include summary totals or footnotes that were never meant to be individual transactions. If one specific column fails consistently across many rows, the provider's export format itself may have changed since the last successful import.

Correct without corrupting the evidence, and reimport safely

Preserve the original file, work from a controlled copy, fix only fields you've actually verified, and document what you changed — never invent a plate, date, or amount just to get a row to pass validation. Before reimporting corrected rows, confirm how they'll be deduplicated against the rows the first import already accepted, and validate the resulting transaction counts and amounts afterward rather than assuming the correction worked.

A worked example

An import rejects 12 rows, all with the same error: invalid amount. Opening the raw file shows those 12 rows have amounts formatted as "$4.50 CR" (a credit adjustment) instead of a plain number — the provider changed how it represents refunds partway through the statement. That's a pattern, not 12 unrelated failures, and the fix (teach the mapping step to recognize the CR suffix) is different from fixing 12 individually corrupted rows.