It is 11:58 and the tender closes at noon. A bid manager at a small IT-services firm watches the portal upload bar crawl toward the end on a large response. It finishes at 12:01. The portal's confirmation email is stamped 12:03. She opens a search box and types "proof of submission tender deadline timestamp", because she can already imagine the question coming from the buyer: when exactly did this file go in, and was it final?
The short answer
A trusted timestamp on your final bid file can prove that this exact file existed, unchanged, at a specific moment. It cannot prove that the portal received it, and it does not decide whether the buyer accepts it. Receipt is decided by the tender's own rules, and usually that means the portal's clock. Use the timestamp as supporting evidence next to the portal receipt, never instead of it.
Two clocks, and only one of them decides
Every tender has an official clock, usually the one on the submission portal or the contracting authority's system. Your tender documents say which one counts, and what happens to a response that arrives a minute late. Read that clause before deadline week, not during it, and ask the contracting authority in writing if it is unclear. Nothing you hold on your side overrides it.
The second clock is yours: the time you can demonstrate that the final file was complete. That clock matters when something goes wrong in between, such as a slow upload, a portal error, a disputed version or a claim that you changed the document after the deadline.
What a timestamp on your file shows
A time stamp under RFC 3161 is a service, run by a Time Stamping Authority, that supports assertions of proof that a datum existed before a particular time. Only a fingerprint of your file, a hash, goes to the authority. That hash is bound to a date and time and signed by that third party, so the time does not rest on your own computer's clock.
In the EU, Article 41(2) of the eIDAS Regulation says that a qualified electronic time stamp enjoys the presumption of the accuracy of the date and the time it indicates and the integrity of the data to which they are bound. That sentence covers the date, the time and the data. It does not mention receipt, delivery or acceptance.
On Swiss Trust Layer, the how it works page describes the same ingredients in a sealed document: a cryptographic hash of the file, an RFC 3161 timestamp, and a certificate chain that traces to Swisscom Trust Services. The original file is never altered, and the hash is what goes out for sealing. Anyone can open the public verification link without an account, and the validator checks an uploaded signed PDF for signature, certificate and timestamp integrity.
What it does not show
It does not show that the portal received your file. It does not show that you were inside the deadline by the buyer's measure. It does not show that the bid is compliant, or who wrote it. If you change one byte after sealing, the hash no longer matches, so the sealed version and the uploaded version have to be the same file.
It also says nothing about the minutes before the stamp. The stamp fixes the file from the moment it was made; it does not say anything about how the file looked earlier.
A routine for the last hour
Treat the sealing as one step between "final" and "upload".
- Lock the package. Export the final PDF or ZIP and stop editing.
- Seal that exact file and save the sealed copy and its verification link.
- Upload the same file, not a re-exported one.
- Save the portal's receipt, a screenshot of the confirmation page and the confirmation email with its headers.
- Write down the portal time and your local time, with the difference between them.
If a dispute starts, you hold two independent records: the portal's receipt for when it arrived, and a third-party timestamp for what the file was and that it was ready. For a late-upload complaint, the second record lets you show that the document was complete well before noon and that the delay was in transfer. Whether the buyer accepts that argument is still up to the tender rules.
Back to 11:58
Our bid manager would have sealed the final file at 09:30, as soon as the package was locked rather than in the last minutes. At 12:03, with the confirmation email in hand and a buyer asking about the three-minute gap, she could point to a verification link showing that the file she uploaded matched a file timestamped at 09:30. It would not make the upload on time. It would show that the response was finished, unchanged and ready, and that the slow minutes were the connection. That is a firmer position than a screenshot alone.
Before your next deadline, seal your final bid file on Swiss Trust Layer and keep the verification link with the portal receipt.
