The truck leaves at three. The person preparing the paperwork is at a screen, the vehicle is not at the gate yet and nobody knows the plate. Two hours later a truck pulls in — but not the one anyone expected. There is a printed document on the desk with a different plate on it. What happens now: do you reach for a pen?
The argument of this article fits in one sentence: the plate on the document is not a formality, it is the identity of the shipment — and that line closes before the goods move. If the vehicle changes at the dock, writing the new plate on the paper by hand does not amend anything. A document that has not closed yet gets completed; one that has closed is no longer a paper problem but a problem for the system that issued it.
There is a practical consequence, and it is also one sentence: the carrier details have to come from a record, not from the memory of whoever is typing the document — because at the moment of loading you have a few minutes to fill that line in.
Why are the vehicle and the driver on the document at all?
The line looks like bookkeeping, but on its own it answers one question: which goods, in which vehicle, and when did they leave? Nowhere else are those three parts of a shipment written down together. The order says what was sold and the invoice says what it costs; only the despatch document describes the movement itself. A document that describes a movement but does not name the vehicle making it is a sentence with the subject left blank.
The second reason shows up on the road. When a vehicle is stopped, whoever stopped it has two things in front of them: the vehicle and the document. Those two have to describe the same lorry. If the plate on the paper does not belong to the vehicle at the gate, the question of which document covers this load has no answer — and answering it is the job of the party that shipped the goods. The same logic holds in a delivery dispute: "the goods were sent" is a claim, while "they left at this time, with this plate and this driver" is a record.
The third reason gets less attention but costs the most: this line marks where responsibility starts. If it is clear who carried the goods, then the question of where the goods went missing has a starting point. If it is not clear, the argument gets stuck between "it left us" and "it never arrived", and neither side is holding a record with a time on it.
Those three reasons are the same everywhere; what changes is the form the information travels in. In Türkiye the document is issued electronically. In Spain the paper control document is going digital: the eighth transitional provision of Ley 9/2025 provides that the control document for road freight becomes obligatorily digital ten months after the law enters into force, and the law entered into force on 5 December 2025. Its name there is the DeCA.
Which of the two: plate and driver, or the carrier firm?
This is the question people actually ask, and the answer is easier than it looks. The line describes the transport that is happening, so the first thing to settle is who is doing the carrying. If the goods go out on your own vehicle, the document describes that vehicle and the person driving it. If they go out with a carrier or parcel company, the document describes that company, because the vehicle is theirs and may not even be assigned yet when you issue the paperwork.
So it is not a formatting decision, it is a decision about facts. In Türkiye, for example, the tax administration's e-despatch guide lists this item as the plate and driver details of the vehicle carrying the goods or the details of the cargo and logistics firm doing the carriage — one or the other, depending on who moves the load. The practical failure mode is not that people misunderstand the choice; it is that they copy the carrier from the previous shipment because "it is nearly always the same truck".
One detail is worth reporting exactly as it stands, because two documents look different at this point. The Turkish guide's "mandatory fields" section reproduces the list from the underlying general communiqué, and that list does not carry a plate-and-driver item. Immediately after it, however, the same section's table of technical fields marks ShipmentStage as mandatory and describes its content as carrier detail such as plate and driver, and the guide adds that a document missing mandatory fields cannot pass the schema checks. We are not drawing a conclusion from that; we are only reporting what the two documents say.
Rules of this kind are set country by country and change; whether one applies to you, and in what form, is a question for your accountant.
The driver's identity: can you leave it blank or fill it with a placeholder?
A field with a placeholder in it is the same as an empty field, only harder to notice. If nobody can name the person taking the goods out of the yard, then the honest description of the situation is that you do not know who is carrying your load — and that is a warehouse problem before it is a paperwork problem. In Türkiye the tax administration went as far as giving this its own heading in the e-despatch guide and answering it plainly: the driver's full name and national identity number, or the passport number for a foreign driver, must be entered correctly.
The practical rule is the same everywhere: if you cannot name the driver, do not invent one. Write the shipment down as what it is — an unassigned load — and close the document when the person is known. A made-up identity is not an incomplete record; it is a false one written with more confidence.
What if the plate is not known when the document is written?
Here is the reality on the dock: when the document is being written, the vehicle is usually not there yet. The discipline that solves this is simple and it is worth writing down as a rule for your own operation: open the document, leave the unknown fields unfinished, and do not close it. The missing details go in at the moment loading starts, and only then does the document get finalised and sent wherever it has to go.
The critical part is the order, not the tooling: printing is not the same as issuing. A printout of an unfinished document is a piece of paper that looks like a document; it does not become one because it came out of a printer. If your process allows a driver to leave with a printout that was produced before the document was finalised, then your process has a hole in it that no software setting will close.
This "draft" is not the draft record in your warehouse software
Two things get confused here. A draft loading record in warehouse software is an internal working record: nobody outside sees it, you can change it freely and you can delete it. An unfinished document is not that — it is a stage of the document itself, not a separate record. The dock sequence around it is covered separately: how a load is verified by scanning.
When the document closes: before the goods actually leave
Whatever your local rules say — and you should check them rather than take a blog's word for it — the operational rule is the one worth building your process on: the document closes before the goods move, not after. Everything else in this article follows from that single ordering. A document finalised after departure describes a shipment that has already happened, which is a report, not a despatch document.
The field that carries the moment of departure is a subject of its own, and we are not opening it here — the rest of the document's fields, the order they are filled in and the copies it travels in are covered separately: how a delivery note is written.
The truck changed at the dock: what to do and what not to do
This is the backbone of the article. There are three situations and they are not remotely alike.
1) The document has not closed yet. This is the easy case, and the discipline in the previous section exists precisely for it: the correct plate and driver go into the unfinished document, and then it is finalised. A change of vehicle is not even an event here — it is just an empty field getting its correct value. Which is why "do not close the document early" is not laziness, it is a design decision.
2) The document has closed. This is where we would rather be honest than confident. A quick search will tell you to "update the note, or cancel it and issue a new one". Before you act on that, check whether the procedure actually exists in your jurisdiction's own source, because a confident answer is not the same as a sourced one, and a wrong correction is worse than an acknowledged gap. The receiver's side of this — responses, rejections, partial acceptance — is a separate article: the receiver's side.
The right move is to ask your accountant and your document provider what the supported flow is in your case, because providers differ and what binds you is your own obligation, not a guess in an article.
3) What not to do. Write the new plate on the printout with a pen. That does not change the document; it gives you a printout with something crossed out on it. The truth of a document lives in the system that issued it, and the paper is a rendering of that truth. Writing on a rendering does not change the source. One country has put exactly this in writing, which is the subject of the next section.
One side note, in a single sentence: a loading photo that shows the plate does not amend the document, but it does record which vehicle actually left — when a photo counts as a record is covered separately: when a loading photo counts.
The same question in Spain: how a control document is amended
Spain has written this procedure down, and what it says is worth reading as a piece of system design even if you never ship there. One sentence of it is the point: under the Spanish electronic control document rules, a change during the service is made either by amending the existing PDF with the new data and the reason for the change — keeping the old data visibly marked as no longer valid, so the URL and QR stay the same — or by generating a new file with a new URL and QR while keeping the original for traceability, and in both cases the amended or new document has to reach the driver.
That last clause is the one that travels: the amended document has to reach the driver. A correction that stays in the office is not a correction, because the copy in the cab still describes a shipment that is no longer happening. Wherever you operate, the test is the same — after the fix, does the paper or screen in the vehicle match the record in the system?
This section reports what Spain's electronic control document resolution (BOE-A-2026-12784) says, and nothing beyond it.
What travels in the vehicle: a screen or a sheet of paper?
Both work. The determining word is not the format but the state: what travels has to be the finalised document. A screen showing an unfinished document and a printout of an unfinished document are equally useless; a screen showing the closed one and a sheet of paper carrying the closed one are equally fine.
One practical detail is worth adding: whatever the vehicle carries has to contain everything the document contains, and it has to be readable. A cropped print, a faded thermal roll or a screenshot missing half the fields is not a copy of the document, it is a picture of part of it. Copies and the rest of the fields are covered separately: the rest of the delivery note.
No connection, system down: does the shipment stop?
This is the part where local rules differ most, so check yours rather than copying anyone's. The operational principle that survives everywhere is narrower and still useful: a fallback is something you agree on before you need it. Decide in advance what paper gets used, what has to be written on it by hand, and by when that paper must be reconciled into the system. A fallback improvised at the gate on a Friday evening is how shipments end up with no document at all.
There is also a lesson hiding in how the fallbacks that do exist are written: the details that get preserved when everything else fails tend to be exactly the ones this article is about — which vehicle, which driver, what time. When a process is stripped down to its minimum, what remains is what it was actually for.
Fallback procedures of this kind are set by local rules and change; whether one applies to you is a question for your accountant.
Does this get typed in on every single shipment?
The real problem on the dock is not that people do not know the information; it is that they retype it on every document. A plate gets a digit wrong, a surname is left half-finished, an identity number is skipped because someone will look it up later, and later never comes. The fix is structural: the carrier, the vehicle and the driver are recorded once, and the document selects them. Making a field a record instead of a free text box moves its correctness to one place; we made that argument at length elsewhere: why document fields are not free text.
What we have. Smartifie Logistic keeps a separate carrier record with its own management screen: carrier code and name, the carrier's tax or identity number, vehicle plate, driver name, driver identity number, phone and notes. On the despatch note screen the carrier is picked from a dropdown, and the option text shows the plate in brackets — so "which carrier was it" is a question you read rather than remember. The actual despatch date and the actual despatch time are separate fields, because the moment a document is written and the moment a vehicle leaves are not the same moment. From the same record a UBL-TR despatch XML file can be produced and downloaded; in that file the carrier section carries the plate and the driver's name.
What we do not have — and we would rather write it out. The application does not send anything to a tax administration. The XML file is produced, but it is not signed, not validated against the administration's schema and not transmitted to any authority or provider; the code's own comment describes this stage as a phase-one skeleton. So we make no claim that we produce compliant electronic despatch documents, and we show no sample of the XML. Two concrete gaps beyond that: the driver's identity number is not written into the XML — it lives on the carrier record and does not reach the file — and the carrier firm's name and tax number are not written either, so the "or the carrier company" branch has no counterpart in the output. There is no draft-approve-send lifecycle, no despatch response and no Spanish control document PDF with a QR code.
One setup warning to finish with, because it bears directly on this article's subject. Carrier details are not copied and frozen onto the document; they are linked from the record. The practical consequence: if you edit the plate on a carrier record after the shipment is done, the plate shown on past documents changes too. The right practice is to create a new carrier record rather than edit the existing one. Two records with similar names look untidy; a record that rewrites history is worse.
In short: the document carries the vehicle's name
Six lines. One: the carrier line is the only written answer to who took the goods. Two: your own vehicle means the vehicle and its driver; a carrier company means the company. Three: the driver field does not accept placeholders; if nobody can name the driver, the document does not close. Four: if the details are unknown when the paperwork is written, leave the document open, complete it as loading starts and close it then — a printout of an unfinished document is not a document. Five: if the vehicle changes, the moment to act is before the document closes; afterwards it is a systems question, not a paper one. Six: writing on the printout with a pen is not a correction anywhere.
To close on the opening argument: the plate on the document is not a formality, it is the identity of the shipment. Getting that line right is not a matter of being more careful; it is a matter of turning it from something to remember into something to select. When you have five minutes at the dock, relying on memory is not a failure of memory, it is a failure of design.