U-ETDS passenger reporting for transfer companies
Transfer companies that run non-scheduled passenger transport under a D2 authorisation are required to report every trip to Turkey’s Electronic Transport Tracking and Inspection System (U-ETDS). This article walks through who the obligation applies to, what data it needs on what timeline, and how that data is fed automatically from the trip record.
Who U-ETDS reporting applies to
U-ETDS is an official system that tracks transport activity electronically under the Road Transport Law and the Road Transport Regulation; according to the transport authority’s own page, non-scheduled passenger transport operators holding an A1, A2, B2 or D2 authorisation certificate are required to report (source: U-ETDS — Passengers). Most transfer companies hold a D2 certificate, so this article focuses on that scenario; if you are comparing systems, our choosing transfer software article also covers how this reporting load is typically carried. The system treats scheduled transport (a fixed bus route, for instance) and non-scheduled transport as separate processes; transfer work falls under non-scheduled transport by its nature, because every trip is its own record with its own route and its own passengers.
What data, on what timeline
Per the same official page, a trip must be entered into U-ETDS no later than 1 hour before departure; if a passenger does not travel or does not complete the journey, that must be reported within 30 minutes of the event. The report itself carries the vehicle’s plate, the assigned driver, the passenger’s identity number or (for a foreign national) passport details, the route, departure and arrival points, departure date and time, and the passenger count — all fields that are already part of daily trip planning, so no separate form is needed.
From the trip record to the report
In a transfer company, most of these fields already live in the trip record: the driver and vehicle assignment, departure and arrival details, the passenger list. The U-ETDS module’s job is not to have you enter this data a second time, but to push it to the official system the moment the trip record is ready. Operations plans the trip through its normal flow in the transfer software, and the report goes out in the background within its own window.
How missing data stops a trip
Before a trip moves to its next stage — “on the way” — the system checks the fields the D2 profile requires: a complete driver identity number, a validly formatted vehicle plate, province/district codes for departure and arrival, and either an identity number or a passport plus nationality for every passenger. If any of these is missing, the trip cannot move to “on the way”; the system states plainly which field is missing, so a report is never attempted with incomplete data.
What you see if a submission fails
The official system can be temporarily unresponsive, or it can reject a field. A well-built U-ETDS integration does not swallow this silently: the submission attempt, its result and any error text stay visible on the trip record, so operations can see from the panel which trip’s report is still pending and retry if needed. When and with what result a report was submitted is kept as a record, which lets you answer “was this trip reported” instantly if it is ever asked.
Example: a morning transfer with a delayed flight
A transfer company has a transfer booked for 07:15 to meet a family of four arriving on an 08:00 flight. When the flight is delayed 40 minutes, the trip time is updated; the system shows the report is still within its one-hour window, and the team notifies the driver of the new time. When one passenger misses the flight and turns back at the last minute, that change is flagged separately, because an incomplete journey has its own reporting window. A second example the same day: two foreign nationals’ passport numbers are already on file from an earlier transfer, so operations only selects which trip they are on this time rather than re-typing their identity details — the passenger card persists, so this stops being repeat work.
How this works in Rotenta
- The trip is created in the sefer (trip) module with driver, vehicle, route and passenger details; with the D2 profile switched on, province/district fields for departure and arrival also appear.
- Before the trip moves to “on the way,” the system checks the fields D2 requires (driver identity number, plate format, province/district codes, passenger identity/passport); if anything is missing it blocks the transition and states which field is missing.
- Once the required fields are complete, the uetds module maps the trip data onto the official system’s fields and submits it within the reporting window.
- If a passenger fails to travel at the last minute, that is flagged on the trip record; the uetds module handles it as a separate report.
- Driver and vehicle documents are kept current in the filo (fleet) module; an expired document would already have blocked the trip assignment at an earlier step.
Frequently asked questions
Who is required to submit U-ETDS reports?
Firms holding an A1, A2, B2 or D2 authorisation certificate for non-scheduled passenger transport are required to report; most transfer companies operate under a D2 certificate (source: U-ETDS — Passengers).
Do I need to report every trip separately?
Yes, each trip produces its own report; but since the trip record already exists, no extra data entry is needed — the system prepares the report from the existing record.
What happens if passenger information is missing?
A trip cannot move to “on the way” while a passenger’s identity or passport information is missing; this is the same assignment gate we describe in vehicle and driver assignment.
Can I correct a report after the fact?
If the trip record changes after completion — say the passenger count is corrected later — how that change reaches the report shows up as a separate trace on the record, so it is never unclear what changed and when.
Who can we reach with questions?
For help connecting your existing trip data to U-ETDS, reach our team on the contact page.
More in this category
- Airport transfer day: booking to completed trip
How a single airport transfer travels from booking to a draft trip, driver/vehicle assignment, and a completed trip, with every state explained.
- Agency accounts, statements and multi-currency receivables
How agency accounts, monthly statements and multi-currency receivables come together in one panel for a transfer business.
- Vehicle and driver assignment without clashes
How transfer trips check time clashes, seat capacity and document validity when a driver and vehicle are assigned.
- Choosing transfer software: what to look for
Compare transfer software on whether booking, trip dispatch, driver/vehicle assignment, agency accounts and reporting live in one panel.