A modern toll collection system is, architecturally, a real-time billing platform connected to physical OBU devices and operating under external revenue assurance audits. The combination is unusual. It demands engineering choices that diverge from generic enterprise billing patterns. This article walks through a reference architecture for European toll backends — the layers it must contain, and the trade-offs that determine whether the system holds up in production.
What a toll collection system actually does
Strip away the marketing taxonomy and a toll backend has four responsibilities, executed continuously and in order:
- Ingest position events from OBU devices in vehicles
- Calculate the toll amount per event, using region-specific rules and tariffs valid at the moment of the event
- Invoice the calculated amounts to the responsible payer (transporter, sales channel, fleet operator)
- Reconcile payments received against amounts invoiced, with full audit trail
Each stage has architectural implications. Treating any of them as a single layer leads to systems that break under realistic load.
The reference architecture below comes from production work on European toll backends where billing accuracy, auditability and cross-border integration were not theoretical requirements, but daily operational constraints.
The 5 layers of a toll collection backend
Layer 1 — Event ingestion
OBU devices generate position events at high frequency. The ingestion layer must accept these events with low latency, validate them syntactically, and write them to a durable event log without back-pressure on the upstream OBU fleet.
The standard architectural choice for this layer is a streaming backbone such as Apache Kafka. The properties that matter:
- Durability: events must persist before acknowledgment, with replication across nodes
- Replay capability: downstream consumers must be able to reprocess events from any offset, for recovery and historical recalculation scenarios
- Partitioning: by vehicle, OBU, or route, depending on the downstream parallelism needs
DNA Solutions operates a microservices-based billing platform for a European tolling consortium with this architectural pattern, using Apache Kafka as the streaming backbone connecting ingestion to downstream invoicing and reconciliation services. The trade-off accepted with this design is that the system is asynchronous end-to-end. Operational dashboards and customer-facing applications must work with eventually-consistent state, not transactional state.
Layer 2 — Toll calculation
The calculation layer is where tolling diverges most sharply from generic billing. A toll amount depends on:
- The route taken (sequence of road segments)
- The vehicle category (mass authorized, emissions class, number of axles)
- The tariff in effect at the moment of the event
- The region administering each road segment
Each variable introduces complexity. Vehicle category is operator-administered and rarely changes per trip. Region is geographic and stable. Tariff is the hardest: it changes over time, can be retroactively corrected, and varies by sub-region within a single country.
As a concrete example of this calculation problem, DNA Solutions operates the public toll calculator application tollcalculator.satellic.be for Satellic, the operator of Belgium's national truck-tolling system. The application replicates the same pricing logic the OBU computes on board, with full support for multi-region rules (Flanders, Brussels, Wallonia) and historical tariff windows. Built on React + Spring Java + PostGIS for geolocation + Google Maps API, the system handles route resolution, regional boundary detection, and tariff lookup against a stored historical pricing table.
The architectural lesson is that tariffs must be stored as time-windowed data with explicit valid-from and valid-to dates, never as the "current" value in a configuration. Retroactive recalculation is a recurring operational reality in toll collection, and a system that overwrites tariff history cannot perform it.
Layer 3 — Invoicing
The invoicing layer transforms calculated events into invoices. The complexity here is not the calculation but the addressing: which legal entity pays for which event.
In a national toll operator, the addressing is usually straightforward (the registered transporter pays). In a cross-border system, the same vehicle can be invoiced through different sales channels depending on the country and contract structure. The system must resolve the correct invoice recipient per event, batch events to invoice cycles per recipient, generate invoice documents with country-specific formatting and tax treatment, and route them to delivery channels (sFTP, EDI, portal upload).
In Europe, cross-border invoicing operates inside the framework of Directive (EU) 2019/520 and the European Electronic Toll Service (EETS), which push interoperability across electronic road toll systems. Operationally, this means the invoicing layer must support multi-country product configurations and country-specific tax treatments as native concerns, not as bolt-on adjustments after the fact.
Cross-border tolling platforms generally support multiple country product configurations (Germany, Austria, Poland, Denmark and Belgium are common combinations in European deployments) and multiple sales channels per country, each with its own invoicing logic. The architecture must externalize these configurations so onboarding a new country does not require code changes.
Layer 4 — Payment requests and reconciliation
Payment requests close the cycle. Once an invoice is generated, the system tracks the payment request lifecycle: emission, partial payments, full payment, dispute, refund. The reconciliation engine matches incoming payments against open invoices, identifies under-payments and over-payments, and produces the reports that revenue assurance auditors will examine.
Two engineering properties matter here:
- Idempotency: payment processing must be safe to retry. Network failures, partner system issues, and operational replays will happen. The system must produce the same final state regardless of how many times an event is processed.
- Lineage: from any invoiced amount, the system must trace back to the underlying events that justified it. This is the property auditors verify, and the property that legacy monolithic billing systems often cannot provide.
Layer 5 — Audit and revenue assurance
The audit layer is not a separate runtime layer; it is a cross-cutting concern that touches every event in every other layer. Every position event, calculation, invoice, and payment must be persisted with:
- A unique identifier
- A timestamp of creation
- The identity (or service) that produced it
- A reference to the inputs that produced it (parent events, configurations valid at the time)
In production, auditors will request: "Show me the chain of evidence from this invoice line back to the OBU events that justified it, and confirm the tariff in effect at the time of those events." A system that cannot answer this in seconds will not pass.
Three architectural trade-offs that determine longevity
Monolith vs microservices
The monolithic billing platform with a relational database is the standard pattern in older toll operators. It is operationally simpler to understand. It also breaks at scale: schema changes become deployment-blocking, transaction lock contention becomes a daily issue, and the system becomes too big to redeploy safely.
The microservices alternative decomposes the platform along the four billing pipeline stages (ingestion, invoicing, payment requests, reconciliation), connected through a streaming backbone. The trade-off accepted is operational complexity: more services, more deployments, more observability work. The benefit is that each stage can scale independently, each service can evolve independently, and the streaming backbone provides replay capability for recovery.
For European toll operators serving multiple countries with explosive transaction volumes, the microservices pattern is the realistic choice. Lower-volume single-country operators may continue to operate on monolithic patterns for years before the trade-off shifts.
Cloud-native vs on-premise
On-premise toll backends still exist, particularly in older deployments. The arguments for keeping them are data sovereignty, regulatory clarity, and infrastructure already amortized. The arguments against are operational cost, slower scaling, and the talent market increasingly oriented toward cloud-native skills.
The middle path that most European operators take is cloud-native deployment on a sovereign cloud (regional AWS, Azure, OVH, or equivalent) with full encryption at rest and in transit, IAM-based access controls, and a documented data residency posture. This satisfies regulatory requirements while providing the operational elasticity needed for cross-border expansion.
Build vs integrate
The third trade-off is whether to build the full stack or integrate with existing components. The pragmatic answer is build what is differentiated (calculation logic, reconciliation engine, country adapters), integrate what is commodity (identity through Keycloak or equivalent, GIS through PostGIS, mapping through Google Maps API or OSM, ETL through standard frameworks).
The mistake is the inverse: building commodity components (custom identity layers, custom GIS) and integrating differentiated components (off-the-shelf billing engines that cannot model the specific country rules). Operators that fall into this trap end up with brittle systems that cost more to maintain and offer less competitive differentiation.
Patterns that recur in mature deployments
Across the toll collection systems DNA Solutions has built or operated, a few patterns recur:
- Bilateral integration with ERP via ETL middleware — most operators run finance on AFAS, SAP, Dynamics, or a custom ERP. A daily ETL job synchronizes invoice and payment data with the ERP. As an example of this pattern, BridgeSync (a middleware DNA Solutions built for Satellic) automates SAP-to-AFAS reconciliation with full audit logging and rollback capability on failed records.
- Public-facing calculator applications — operators benefit from offering a public tool that customers and channels can use to estimate tolls before committing to a trip. The calculator runs the same pricing logic as the OBU and serves as a debug tool for both customer support and internal teams.
- Time-windowed configuration for tariffs and partner contracts — every business-impacting parameter (tariff, channel commission, country product code) is stored with a valid-from and valid-to window. This is the only way to support retroactive recalculation cleanly.
When to refresh your toll collection architecture
The signals that a toll collection backend is approaching the end of its useful life are operational, not technical:
- Deployments take days or weeks because they require coordinated downtime
- Tariff changes require code releases rather than configuration updates
- Cross-border expansion is blocked by an inability to model new country rules
- Audit responses take days rather than hours
- Engineering team turnover is high because the codebase is unmaintainable
Operators encountering several of these signals are at the start of a multi-year modernization rather than a discrete project.
Discuss your toll collection architecture
DNA Solutions builds and operates toll collection backends for European operators — at Satellic, and across a European tolling consortium spanning Germany, Austria, Poland, Denmark and Belgium. If your organization is evaluating an architectural refresh, a cross-border expansion, or a billing platform modernization, we can help you challenge the technical assumptions behind the project before vendor selection begins. Schedule a technical discussion.