U-ETDS Record Rejected: Causes and How to Fix It

Having sent a U-ETDS record does not mean you have declared the trip. U-ETDS (Ulaştırma Elektronik Takip ve Denetim Sistemi) is the electronic tracking and inspection system run by the Turkish Ministry of Transport and Infrastructure: every carrier working under a Turkish authorisation certificate has to file each carriage in it before the vehicle sets off. When the system rejects a record, that trip counts as undeclared — and most carriers do not notice for months. A warning flashes on a screen, nobody reads it, the truck rolls on. The gap surfaces at an inspection, by then as an accumulated backlog rather than one trip. This article splits the rejection reasons into categories: why each happens, how you recognise it, and how you fix it.

Does a rejected record still count as declared?

No — a rejected record counts as undeclared, and it leaves you in exactly the same position as never having filed at all. This is the most critical and least understood point of the whole subject.

The logic is simple: your obligation is not to send a record, it is to have a valid trip record standing in the system. A submission is an attempt; until it is accepted it has no legal weight. What an inspector looks at is not your effort to file, but the record actually there.

The practical consequence: the success measure of your declaration process is not how many records you sent, it is how many were accepted. A carrier that has never measured the gap between those numbers does not know its own exposure.

The obligation covers holders of the K1, K3, C2, C3, L1, L2, N1, N2 and R1 authorisation certificates (yetki belgesi) — the licence classes the Ministry issues for domestic and international road haulage, forwarding and logistics — and it follows the certificate, not the vehicle. Whether the carriage runs on your own fleet or a subcontracted truck, if the trip is performed under your certificate, holding a valid record is your responsibility. A rejected record does not discharge it.

Why does a rejection disappear so quietly?

Because the response appears for a few seconds on the screen of whoever pressed submit, and that is where it stays. In manual filing a rejection does not behave like a notification: it opens no task and sends no reminder.

The typical scenario runs like this. At the end of the day an operations clerk enters that day's trips into the portal in one batch. One record is rejected over a single field. The clerk carries on so as not to break the sequence, moves to other work the next morning, and nobody remembers the warning. The trip is completed, the invoice issued, the file closed — and in the system that trip was never recorded.

The loop breaks in the same place at every carrier: submission and verification happen at different moments, usually by different people. Whoever submits treats the job as done the moment the record leaves; whoever should check has no list to look at. The rejection in between becomes work nobody owns.

In the field we call this a silent rejection. It is silent because nothing looks incomplete anywhere: your trip list is full, your transport waybill (taşıma irsaliyesi) was issued, the vehicle finished the run. The only thing missing is on the side you cannot see.

Which errors actually get a record rejected?

Almost every rejection falls into one of seven categories. The table below summarises why each happens and how it is fixed; the sections that follow open each one in turn.

None of these reasons comes from not knowing the regulation. They all come from inconsistent data entry. The same information written two different ways in two places is, on its own, enough to get a record rejected.

How do you fix rejections caused by inconsistent data?

This group is fixed by pinning your source data to a single place. Four of the seven categories sit here, all of them faces of the same illness.

An identity or tax number mismatch happens when the identity or tax number you send does not match the registered company name. How you recognise it: if trips for the same customer keep coming back rejected, the problem is not the individual trip, it is the customer card. That is where the fix belongs too — verify the number against the official record, correct the card once, resubmit. Correct it trip by trip and the same error returns every month.

A plate format error happens when the plate is written with spaces, hyphens, lower case letters or missing characters. How you recognise it: rejections cluster on particular vehicles, and those vehicles almost always have their plate entered as free text. The fix is to settle on one plate format and make users select from the vehicle card. As long as plates are typed by hand, this error will not stop.

A mandatory field left empty happens when a field that looks optional on your own screen is compulsory in the declaration. How you recognise it: rejections gather around a particular type of trip — usually ones opened in a hurry and saved with incomplete information. The fix is to make that field mandatory when the trip is opened; if an incomplete trip is never saved, an incomplete declaration is never sent.

A missing consignor or consignee address happens when the province, district or address field is left blank or filled in as free text. How you recognise it: it becomes obvious with new customers and one-off jobs, because the customer card is not yet complete. The fix is to carry the address from the customer card and make province and district selectable from a list rather than typed.

Why are scope and timing rejections different?

This group is not a data error but a design error, and correcting a field will not make it go away. Three categories sit here, all of them arising from how the operation is organised.

Carriage outside the certificate scope happens when the trip does not fall within the carriage type the authorisation certificate permits. How you recognise it: the rejection repeats on a particular route or job type while other trips go through cleanly. The fix is to open the trip under the correct certificate. Where a carrier holds more than one authorisation certificate this cannot be maintained by hand; which trip belongs to which certificate must be defined in the system. We explained in detail why the obligation attaches to the authorisation certificate rather than to who owns the vehicle in how to file a U-ETDS freight declaration.

Date and time inconsistency happens when the arrival time appears before the departure time, or when the declaration is sent after the carriage has already started. How you recognise it: rejections cluster in end-of-day batch entries and are absent from trips opened in the morning. The fix is to take the times from operations and to send the declaration before the vehicle leaves. That second point is not merely a cause of rejection — it is an explicit requirement of the regulation.

Duplicate records happen when the same trip is sent twice, usually for one of two reasons: the first submission was assumed to have failed and was retried, or two users entered the same trip. How you recognise it: the rejection appears on trips where the first attempt was in fact accepted — so there is no real gap at all. The fix is to keep one reference per trip and store the submission status on the record. If the status is not held there, nobody can tell whether they already sent it.

Carriers using subcontracted vehicles see these three categories far more often. There is no vehicle card, so the plate is typed by hand; driver and vehicle details arrive late; and the trip is often recorded after departure. The discipline built for an own fleet breaks when a subcontracted truck enters it, and rejections gather exactly there.

How do you catch a rejection when you file manually?

With manual filing a rejection is caught only by the person looking at the screen at that moment; with an integration it is written onto the record and stays. The difference decides how long a trip sits unregistered.

To put those rows into one sentence: with manual filing the submission happens after the trip, usually as an end-of-day batch; the rejection appears on screen for a moment and is lost when the page closes; only the person logged in at that moment sees it; if nobody looks it goes unnoticed until an inspection; correcting it means retyping the details in the portal from scratch; and afterwards there is no trace that an attempt was ever made.

With a web service integration, by contrast, the submission is automatic the moment the trip is opened; the response is written onto the trip record as a status and stays there; everyone who opens trips or watches operations sees it; the problem is spotted the same day from the record list; correcting it means updating only the faulty field and repeating the submission; and the submission and response history can be traced later. The Ministry permits this integration over a web service, so automatic submission is possible without logging into e-Devlet at all.

What should you do once you find a rejected record?

First correct that record and resubmit it, then build the routine that stops the same rejection recurring. Skip the second part and the first repeats every month.

We suggest three steps.

1. Correct the faulty field at its source. Not on the trip record, but where the information comes from: the customer card, the vehicle card or the certificate definition. A trip-level fix brings the same error back tomorrow.
2. Check whether other records share the same category. A plate format error never stays with one trip; it affects every run made with that vehicle. Rejections arrive as categories, not one by one.
3. Track the number of accepted records. If the difference between trips dispatched and records accepted is anything other than zero, that difference is your open exposure.

A short monthly reconciliation covers the third step. At month end, put the number of trips you dispatched next to the number of records the system accepted. If the two match, the period is clean; if not, the difference is the number of trips never declared. Finding out which ones during the month is far easier than learning it at an inspection.

The permanent answer to all three is to stop treating the declaration as a separate job. When filing is tied to the opening of the trip, both the timing inconsistency and the empty mandatory field end at source; and because the rejection appears on the trip's own record, it cannot stay silent. See how that flow is built into an operation on the how Seferi works page, and which module covers which step on the features page.

One closing reminder: correcting a rejection does not bring the past back. Because the declaration must be made before the carriage starts, the vehicle appears unregistered for the whole stretch between the rejection and the correction. The goal is not to fix rejections quickly, but to see them the moment the trip is opened.

Does a rejected U-ETDS record still count as declared?

No. A rejected record counts as undeclared and leaves you in exactly the same position as never having filed at all. Submitting a record does not mean the system accepted it. What an inspector looks at is not your attempt to file, but the valid trip record standing in the system. So the success measure of your declaration process is not how many records you sent, but how many were accepted.

How do I find out that my record was rejected?

Only by checking the response that comes back after submission. When you file manually through the portal, the warning appears on screen at that moment and disappears when the page is closed, so if nobody is looking, the rejection passes in silence. With a web service integration the response is written onto the trip record as a status and stays there. The only reliable check is to compare the list of trips you dispatched against the records the system actually accepted.

What are the most common reasons for rejection?

Almost all rejections fall into seven groups: identity or tax number mismatch, plate format, carriage outside the scope of the authorisation certificate, a mandatory field left empty, date and time inconsistency, duplicate records, and missing consignor or consignee address. Most of them come from inconsistent data entry rather than from not knowing the regulation. The same information written two different ways in two different places is reason enough on its own.

Can I correct a rejected record and resubmit it?

Yes, you can fix the faulty field and send the record again. But because the declaration has to be made before the carriage starts, a correction does not recover the time already spent on the road. Between the rejection and the correction the vehicle appears unregistered in the system, and an inspection carried out in that window can find the declaration missing. That is why the rejection needs to be seen when the trip is opened, not hours later.

Does a single rejected record affect my warning point balance?

Yes. Carriers that close a three-month period completely, on time and without errors have points removed from their warning balance. One rejected record breaks two of those three conditions at once: the period is neither complete nor error-free. So a silent rejection does not only create risk for that one trip, it also costs you the point deduction that consistent declaration would have earned you for the whole period.