Toll Back Office and Violations Software: Why the Image Queue Becomes a Revenue Problem

Why a toll back office is a revenue system, not an IT system

It is 2:15am and the image review queue has 38,000 unreviewed plate captures on it. Some are motorcycles photographed at an angle. Some are trailers obscuring the towing vehicle. Some are dealer plates. A contracted review team in another time zone is clearing them at a rate that will not catch up before the statutory notice window closes on the oldest ones, at which point those transactions stop being revenue and become writeoffs. Nobody on the authority side can see the queue depth in real time, because the queue lives inside the vendor platform and surfaces once a month in a report.

This is the part outsiders miss about tolling. The back office is not a billing system bolted onto a highway. It is the highway's revenue system, and on a facility financed with revenue bonds, the numbers it produces feed covenant tests that a trustee checks. Leakage is not a metric an operations director gets nagged about at a quarterly review. It is a financial control. So is the dispute rate, because a violation programme that generates hearings it loses is a programme that will be politically ended.

The platform vendors in this space are Conduent, TransCore, Kapsch TrafficCom and Emovis. They are real operators running real back offices at scale and they know tolling far better than a generalist software firm. The structural problem is the contract shape rather than the engineering. These systems are procured against a specification written years before the facility opened, delivered as a configured instance of a product designed for many agencies, and then changed through a change order process. When your board approves a new peak period rate that starts in nine weeks, or your state passes a statute changing the notice sequence on unpaid tolls, the question is not whether the vendor can do it. It is what the change order costs and whether nine weeks is achievable inside their release train. Agencies live with workarounds because the alternative is a procurement.

Problem one: matching a transaction to an owner is a chain, and every link leaks

A transponder read is easy. It arrives with a tag ID, the reader matches it to an account, the account is in good standing, the toll posts. That is the happy path and it is most of your traffic, which is exactly why the unhappy paths get underbuilt.

Everything else is a chain. A plate image has to be read, by optical character recognition first and a human second when confidence is low. The read has to be resolved to a registered owner, which means a state motor vehicle lookup for in state plates and an out of state request through the NLETS network for the rest, both of which fail on leases, rentals, recent transfers and plates that were surrendered last month. Then a pay by plate invoice is generated to an address that may be stale. Each link drops a percentage of transactions, and the drops compound. When an authority tells us they cannot explain a gap between gantry counts and posted revenue, the answer is almost never a single leak. It is four small ones multiplying.

What a custom build does differently is make the chain visible as a first class object. Every transaction carries its own resolution history: the read, the confidence score, the reviewer decision, the lookup request and response, the invoice, the escalation. When the finance director asks where 300,000 transactions went last quarter, the query is one filter, not a vendor ticket. That single change in observability is usually what pays for the project, because it turns leakage from a mystery into a work queue.

Problem two: image review is a cost centre priced by the image

Image review is the single largest variable operating cost in most back offices, and it is charged per image reviewed. That gives the vendor no reason to reduce the volume flowing into review and gives you no lever to pull. Confidence thresholds sit where the vendor set them. Nobody is tuning them against your specific camera angles, your specific lighting at that specific gantry, or the fact that one lane has produced twice the review rate since a resurfacing job changed the vehicle approach.

A custom build treats review volume as an engineering target. You own the threshold per lane and per camera, you can raise or lower it and see the effect on both review cost and dispute rate the same week, and you can retire images automatically where a second camera on the same vehicle already produced a high confidence read. Machine reading of plates is a mature commodity now, and the useful work is not building a new reader. It is the routing layer around it: which reads go to a human, in what order, with what context, and what happens when two agencies read the same plate differently.

Problem three: interoperability settles both directions, every day, and reconciliation breaks quietly

The federal interoperability requirement in MAP-21 pushed the industry toward a world where a customer with one transponder drives through other agencies. Operationally that means you send away transactions to other agencies daily and receive theirs, in agreed file formats such as the E-ZPass Group interagency communications definition, with reject and correction cycles running behind them. Your customer service representative is looking at a posted transaction from a facility 400 miles away that arrived nine days after the trip, on an account the customer closed a week ago.

The failure mode is not dramatic. It is a small daily variance in a settlement file that nobody has time to chase, repeated for eleven months, discovered by an auditor. Platform back offices handle interoperability, but they typically hand you a summary and a rejects file, not an investigable ledger. A build that is worth the money models each away and home transaction as a posting with a full lifecycle, matches settlement files line by line, and raises an exception the day a variance appears rather than at year end.

Problem four: violations are a legal process with clocks, and clocks are code

Escalation is where authorities get hurt. An unpaid pay by plate invoice becomes a notice of violation, then a second notice, then a civil penalty, then a registration hold or a referral to collections, and each of those steps has a statutory clock and a required content in your state. A day of drift in the timing, a notice that omits required language, or an evidence packet that cannot be reproduced at a hearing, and the penalty is unenforceable. Do that at volume and you have a programme that generates press coverage rather than revenue.

Dispute handling is the mirror image. A customer who disputes should get the image, the read, the lookup result and the notice history in one packet, and the hearing officer should get the same packet. If assembling that takes a representative twenty minutes across three screens, your dispute cost exceeds the toll by two orders of magnitude and staff quietly start waiving instead.

What a custom toll back office has to include

• A transaction ledger where every posting carries its full resolution history and can be replayed, with no in place edits and a complete audit trail.
• Rate schedules as versioned, effective dated data by facility, lane, vehicle class and time of day, changeable by your own staff without a code release.
• An image review workbench with per camera confidence thresholds, reviewer productivity and quality sampling, and automatic retirement of duplicate reads.
• Registered owner lookup with in state motor vehicle integration and NLETS handling for out of state, including retry logic and stale address detection.
• Interoperability file exchange in both directions with line level settlement matching and daily variance exceptions.
• A violations engine where the notice sequence, clocks and required notice content are configuration, so a statutory change is a data change reviewed by counsel.
• A customer facing account portal and a representative console that share one view of the transaction, plus a one click evidence packet for hearings.
• Revenue reporting built to the definitions in your bond covenants and your annual audit, produced from the ledger rather than from a spreadsheet.

What this costs and how long it takes

A focused first release, meaning transaction ingest from your roadside system, plate to account matching, the image review workbench and pay by plate invoicing, runs $150,000 to $320,000 and ships in 16 to 22 weeks. That is a system your team uses daily, not a pilot. The full back office adding interoperability settlement, the violations engine with statutory escalation, the customer portal and covenant grade revenue reporting runs $450,000 to $900,000 phased over 12 to 24 months.

What drives the number up in tolling specifically: the count of interoperability partners, because every hub and every agency pair has its own quirks in practice; the number of states you look up plates in, since each motor vehicle department integration is its own effort; the payment stack, because card present kiosks, walk up centres and stored value accounts each carry their own compliance scope; and the roadside interface, since older lane controllers speak protocols that need a real integration rather than an API call. What keeps the number down is starting with one facility, the current rate schedule and the existing violation sequence, and leaving the customer portal for phase two.

When you should not build

Do not build if you run a single facility under roughly 15 million transactions a year with a stable rate schedule and no reciprocity obligations. A hosted back office from an established vendor is cheaper than the staff you would need to run your own, and your leakage is probably a camera alignment problem rather than a software problem. Do not build if your agency has no permanent technical staff at all, because owning a revenue system means owning its operations.

Build when two or more of these are true. Your rate or fee schedule changes more than once a year and every change is a change order. Your image review cost per transaction has never gone down. You cannot answer a leakage question without asking your vendor. Your violation programme has lost hearings on evidence production. Your interoperability variances are discovered by auditors rather than by your own team. At that point the coordination logic between reads, owners, notices and settlements is your business, and it should not sit inside a product configured for someone else's statute.

How to choose a developer for a toll back office

Ask them to whiteboard the transaction lifecycle before you sign anything. A team that has done this draws the read, the resolution attempt, the owner lookup, the invoice, the notice chain and the settlement posting as separate events on one ledger. A team that draws a transactions table with a status column has built an ecommerce checkout and is about to learn tolling on your budget.

Ask how they handle the statutory clocks. If the answer is a scheduled job that fires notices, ask what happens when your legislature shortens the window by ten days, and listen for whether counsel can review the change as data. Ask what they have actually integrated: a roadside lane controller, a state motor vehicle interface and an interoperability file exchange are three different problems and only one of them looks like a normal API.

Ask who owns the code and get it in writing before kickoff. Given how this industry works, this matters more here than in most sectors. You should own the repository, the cloud accounts and the unrestricted right to hire a different firm to continue the work. At Digital Heroes the client owns the code from the first commit, and we would tell you to walk away from anyone who hedges on it, because the whole reason you are having this conversation is a dependency you cannot exit.