7 criteria for choosing a toll collection solution provider

Why tolling is not a generic IT project

Toll collection is not a category most consultancies have built before. It sits at the intersection of real-time billing, GPS and OBU (On-Board Unit) integration, multi-jurisdictional tax logic, and revenue assurance auditing. A vendor with deep ERP experience but no tolling track record will discover, mid-project, that toll billing has properties most enterprise software does not have: retroactive recalculation when tariffs change, historical tariff windows that must be queryable for years, and per-region rules that change at administrative borders rather than country borders.

The result is a category of projects that look generic in the procurement document and turn into multi-million-euro recovery exercises in production. Operators evaluating candidates need criteria that filter for actual tolling experience, not just claims.

The criteria below come from production work on tolling environments where billing accuracy, auditability and legacy integration were not theoretical requirements, but daily operational constraints.

How to evaluate a toll collection solution provider

1. Real production experience on toll backend systems

The first filter is straightforward. Has the candidate shipped and maintained a toll billing system in production, against real OBU traffic, in at least one European country?

A public-facing calculation tool can demonstrate the usability of a digital service. Its visible behaviour is a useful reference; it does not establish which technologies or internal systems an organisation uses.

2. Track record on cross-border and EETS-aligned deployments

Tolling systems that operate in a single country are simpler than they look. Tolling systems that span multiple countries are an order of magnitude harder. Each country adds its own pricing logic, currency, tax jurisdiction, VAT treatment, and regulatory reporting requirements.

In Europe, cross-border tolling is not only a technical challenge. It also sits within the framework of Directive (EU) 2019/520 and the European Electronic Toll Service (EETS), which push interoperability across electronic road toll systems. For operators, this makes configuration, auditability and country-specific billing logic operational rather than optional.

Concrete indicators in a candidate: support for multi-currency invoicing within a single platform, ability to onboard new countries via configuration rather than code rewrites, and a documented framework for country-specific tax adjustments.

Cross-border software must accommodate business rules that differ between markets. A provider should explain how it validates changes and maintains continuity without disclosing the configuration of existing clients.

3. Revenue assurance and external audit readiness

In tolling, revenue assurance is not optional. Operators are accountable for every kilometer billed, and external auditors verify the platform's calculations. A vendor that has never built for external audit will not understand the engineering implications: audit trails on every transaction, idempotent reprocessing, full lineage from raw GPS event to final invoice, and the ability to reconstruct any past invoice from source data.

The question to ask is concrete: "Have you built a billing platform that has passed an external revenue assurance audit, and which auditor?" A vendor that has been through Deloitte-audited revenue assurance for toll billing knows the questions auditors ask before they arrive.

4. Legacy integration capability

Tolling operators rarely start greenfield. Most have legacy backend systems, often built over a decade ago, that handle existing customer records, payment flows, and third-party integrations. A modernization project that ignores these systems creates two parallel sources of truth and breaks within months.

An integration layer can connect business applications without replacing their core functions. Data validation, format translation and controlled exception handling help keep records consistent while reducing manual transfers.

5. Operational support model beyond go-live

Toll collection systems do not have a "done" state. Tariffs change. New countries onboard. Partner integrations evolve. A vendor whose engagement ends at go-live leaves the operator dependent on a system whose changes require complete project remobilizations.

The relevant question: what is the vendor's structure for sustained operational support after the initial delivery? A monthly support model with named engineers, response SLAs, and change capacity in the same team that built the platform is the production reality. A handover to a generic managed services team is a downgrade dressed as a transition.

6. Stack and architecture decisions for tolling scale

Toll billing platforms handle high-volume, real-time event streams. The architectural choices matter operationally. A mature integrator will articulate, without hedging:

• Event-driven architecture with a streaming backbone (Apache Kafka or equivalent) rather than batch reconciliation
• Microservices decomposition aligned with billing pipeline stages (ingestion → invoicing → payment requests → reconciliation) rather than horizontal layers
• A cloud-native deployment model with infrastructure as code, immutable infrastructure patterns, and observability built in
• Authentication and authorization handled by an identity layer (Keycloak or equivalent) rather than per-service implementations

A vendor that cannot articulate why each of these choices was made on past projects will discover the trade-offs in production.

7. Team continuity and senior engineering ratio

Toll billing platforms take years to mature. Teams with high turnover deliver systems whose institutional knowledge walks out the door annually. The relevant indicator is the seniority profile of the team that will work on the project: how many years of relevant production experience the lead engineers have, what other production tolling systems they have built or maintained, and how stable the team has been on comparable contracts.

A useful filter: ask for the engineering team's average tenure on similar contracts. Vendors with five-year or longer engagements on tolling clients have institutional knowledge that cannot be hired around.

Putting the criteria into practice

The seven criteria above are not a checklist to score in a procurement spreadsheet. They are evidence categories. A serious evaluation asks for concrete production examples in each category, with public artifacts, named clients, and team continuity data where possible.

The asymmetry of the selection deserves emphasis. The cost of selecting a generic IT vendor for a tolling project is not the engagement budget. It is the operational cost of a billing platform that fails an audit, requires recovery work, or blocks cross-border expansion. The cost of selecting a candidate with real tolling expertise is amortized over the multi-year sustained relationship that follows.

If you are evaluating toll collection technology vendors in 2026, the framework above gives you concrete questions to ask each candidate. The candidates that have actually shipped production tolling systems will answer with specific projects, public artifacts, named clients, and engineering team data. The candidates that have not will answer with frameworks, methodologies, and case study slides. The difference will be visible within the first hour of technical evaluation.

Discuss your toll collection project

DNA Solutions helps organisations assess and improve business software. Schedule a technical discussion to review the requirements of your project.