You send a 40-page PDF to a client on Friday at 5:42 pm. Two months later, they say they received a different version, or later, or without the annex. With Sealway in BCC of the handover email, the message, its attachment and the moment of its transmission are received as it is sent and timestamped. Sealway does not prove that the client received or opened the deliverable, nor that the deliverable is compliant.
Built for
An agency has to hand over a file before Friday, 6 pm. At 5:42 pm it sends its client “here is the final version of the file”, with final-deliverable.pdf attached. Six weeks later, the client disputes it.
They say the document arrived late, or that the file received was not that version, or that an annex was missing. Each of these claims is about a precise fact: which message, with which attachment, was transmitted, and when. The email found in the agency’s “Sent” folder answers it poorly: it comes from the party relying on it, and nothing prevents its content or its date from being disputed.
Sealway email evidence brings something else: a copy of the message received by Sealway as it is sent, with the attachment and the recipients shown, bound to a qualified electronic timestamp. The question “what left, and when?” gets an answer that no longer depends on the agency’s word.
The contract, the quote or the terms of business set how a deliverable is handed over and accepted: by email, on a platform, by an acceptance report, with or without acknowledgement of receipt, within which validation period. Sealway documents the handover email; it does not change those rules. Before sending:
The contract says what must be delivered, when and how. The handover email is the concrete act: it announces the deliverable, carries it and fixes, through its content, what the provider considers delivered. Its weakness, in a disagreement, is that it is produced by the party relying on it.
Sealway adds a copy received by a third party as the email is sent, timestamped, with the attachment given its own fingerprint. The content of the message and of the file, and the date of their transmission to Sealway, then enjoy a presumption of integrity and accuracy (eIDAS Regulation, art. 41(2)): disputing them means bringing evidence to the contrary.
Three layers, three roles: the contract decides, the email hands over, Sealway dates.
Handing over a deliverable is the performance of a contractual obligation. Under French law, it is for the party claiming to have performed to prove it, by any means where a fact is concerned, and an email is admissible for that. Its strength depends on what comes with it. Other jurisdictions have their own rules, but most admit emails and weigh them.
In our translation: “Whoever claims performance of an obligation must prove it. Conversely, whoever claims to be released must prove the payment or the fact that extinguished the obligation.” A provider who claims to have delivered on time must be able to show it.
Lawfully formed contracts are binding on those who made them (art. 1103): the agreed mode of handover and acceptance prevails. The parties may also agree on how performance will be proven, agreements on evidence being valid where they concern rights the parties freely dispose of (art. 1356).
Unless the law provides otherwise, proof may be brought by any means (art. 1358). Electronic writing has the same evidential weight as paper, provided the person it originates from can be duly identified and it is created and kept in conditions that guarantee its integrity (art. 1366).
An email produced to prove a fact, such as the sending of a deliverable, is admissible by any means and assessed by the trial judges in their discretion. What carries weight is what makes it possible to establish its content, its date and its transmission.
The court sets aside a photocopy of an email “devoid of evidential weight as to the actual sending”: the party producing it proves neither the sending nor the receipt. An email displayed from one’s own “Sent” folder meets the same objection.
A qualified electronic timestamp enjoys a presumption of the accuracy of the date and time it indicates and of the integrity of the data to which they are bound. That is what dates the copy received by Sealway and fixes the message and its attachment, across the European Union.
The same email as usual, one more address in the BCC field. What the message contains becomes what the proof fixes: take care with it.
A file name that carries the version: final-deliverable-v7.pdf. The certificate will list that name with the file’s fingerprint; a different version will have a different fingerprint.
What is delivered, in which version, what remains expected, the request for validation. The text of the message is part of the proof.
The deliverable as an attachment. If the file is too large for email, create a proof of the file from the app in parallel and state its fingerprint in the email: a sharing link alone does not bring the file into the proof.
As usual, from your mail client: the client in the To field, the address of the “Client X” collection in the BCC field. The email leaves as usual; the client does not see Sealway.
The message received and the attachment get their fingerprint, bound to a qualified electronic timestamp. The certificate states the sender, the To and Cc recipients, the subject, the declared date and the name of each attachment.
Ask for the acknowledgement or validation provided by the contract; forward the client’s reply to the collection’s address to date it. Keep the evidence file with the contract and the invoice.
What the proof establishes exactly, and what it leaves to the acknowledgement, is detailed in the email evidence guide.
What a handover by email leaves as traces, with and without Sealway.
final-deliverable-v7.pdf exported, proofread, named.
Message to the client, file attached, address of the “Client X” collection in BCC.
Message and attachment received by Sealway, fingerprints computed, qualified timestamp.
The client confirms receipt.
“That is not the version.” The collection holds the message, the attachment, their fingerprints and their dates.
Without Sealway, what is left is the email in the “Sent” folder and, with some luck, the client’s acknowledgement. With Sealway, a copy of the message and the file received by a third party at 5:42 pm and timestamped is added, whose content and date enjoy a presumption of integrity and accuracy.
What the proof lets you produce against the three most frequent claims.
The qualified timestamp establishes that the message and its attachment, as received by Sealway, existed no later than the time it states; when the proof is finalised on receipt, that time follows the sending by a few minutes. The time of arrival at the client’s is a matter for their acknowledgement.
The attachment received by Sealway has its SHA-512 fingerprint on the certificate. The file the client produces, or the one you keep, is compared with that fingerprint: the comparison of the fingerprints shows whether the file is identical or not.
The certificate lists each attachment received with the message, by name and fingerprint. If the annex is there, it was transmitted with the message; if it is not, the proof shows that too.
That is the limit: Sealway sees neither the delivery to the client’s server nor the arrival in an inbox. The proof establishes the transmission to Sealway; receipt is proven by the acknowledgement, the client’s platform or an electronic registered delivery.
If the deliverable is shared through a link (file transfer, online workspace), Sealway receives the link, not the file. The proof will fix the message and the link; not the content behind the link, which can change.
For a deliverable too large for email, create a proof of the file from the app, then state in the handover email the file name and its fingerprint. Two proofs, tied by the fingerprint, document the file and its announcement.
An upload to the client’s platform leaves traces on their side, which you do not control. The handover email with Sealway in BCC, announcing the upload and attaching the file or its fingerprint, gives you one on yours.
Each version sent is a separate proof, in the client’s collection: v5, v6, v7. The chronology of the versions transmitted reads in the collection.
Sealway documents the handover; the contract decides what counts as handover. A few clauses avoid the argument.
By email to a given address, on a given platform, in a given format. A handover made otherwise than agreed can be disputed, even if proven.
Who confirms receipt, within what period, and what happens with silence: tacit validation, reservations, new version.
Date of sending or date of receipt? If the contract relies on sending, the email evidence fixes it; if it relies on receipt, provide for the means to prove it.
The parties may agree on how performance will be proven (French Code civil, art. 1356). A clause recognising the handover email with a timestamped copy as the mode of proof of sending removes the ambiguity in advance.
Recall in the email the validation period provided and what happens with silence. The proof fixes that request and its date.
Forward the reservations received to the collection’s address: their content is fixed and the forward dated. The date of sending by the client remains a statement in their message.
Where the contract provides for one, it remains the document of acceptance. Sent by email with Sealway in BCC, its transmission is dated; its signature by the client belongs to another mechanism.
The invoicing email, with the invoice attached and Sealway in BCC, is documented the same way.
The studio sends at 5:42 pm “Site v7, final version for go-live”, with the site archive, the deployment guide and the list of fixes, Sealway in BCC. Three attachments, three fingerprints.
The client confirms receipt on Monday morning and announces feedback within five days. The studio forwards their reply to the collection’s address.
The client rejects the invoice: the version delivered was not the right one and the guide was missing. The studio produces the proof of 3 October: message, three attachments, fingerprints, timestamp, and the confirmation of 6 October.
The proof establishes what the studio transmitted on 3 October at 5:42 pm, file by file, and the client’s confirmation as the studio forwarded it. It does not say whether version 7 complied with the specification, nor whether any delay gives rise to a penalty: those questions remain the contract’s and, failing agreement, the court’s, which weighs the material freely.
Four ways of handing over the same deliverable, and what is left six weeks later.
| Approach | What it brings | Its limits |
|---|---|---|
| Plain email, found in “Sent” | The message and the attachment, as your mail client keeps them. | Produced by the party relying on it: content and date open to dispute, like the photocopy set aside by the Paris court of appeal. |
| Email with Sealway in BCC | The same email, plus a copy received by a third party as it is sent and timestamped: message, attachment, recipients shown and transmission fixed. €1.99 per proof up to 9 attachments; beyond that, one credit per batch of 10 items, message included. | Proves neither receipt nor opening by the client; amounts neither to acceptance nor to compliance. |
| Upload to the client’s platform | Traces of the upload, timestamped by the platform, often with a notification to the client. | Traces on the client’s side, under their rules and their retention; to be paired with a documented handover email on yours. |
| Qualified electronic registered delivery | Presumption of sending by the identified sender, of receipt by the identified addressee and of accuracy of the dates (eIDAS Regulation, art. 43 and 44). | A distinct, more formal service, suited when receipt is at stake; can be combined with the email with Sealway to fix the attachment. |
For most handovers, the email with Sealway in BCC fixes what is most often missing: the exact attachment and the time of transmission. When receipt is at stake, it is added to a sending method that proves it.
The contract and, failing agreement, the court decide what counts as handover and what is owed. Email evidence gives them the message, the attachment and the date of transmission, without depending on the party producing them.
The handover email received in BCC is placed in a Sealway proof as it is sent. Six weeks later, it is possible to verify that the message and the attachment produced are the ones bound to the timestamp created that day.
What providers ask before sending, and after the dispute.
Texts and decisions cited on this page; the French sources are in French.
Sealway does not provide legal advice. What counts as handover, acceptance or delay depends on the contract and, in a disagreement, on the court’s assessment. The French provisions and decisions cited illustrate French law; the eIDAS Regulation applies across the European Union.
An alert sent to a distributor, a creation to date before sharing it: what was transmitted, and when, is documented the same way.
Contaminated batch, withdrawal, recall: keep evidence of the alert email sent to the distributor, with its attachments and its date.
Learn more →Archive a version of your source code or a release so you can establish that it already existed on that date.
Learn more →Demo, master, beat, lyrics or stems: document a version before sending it to a label, a producer or a collaborator.
Learn more →The message, the attachment and the recipient shown, received as it is sent and timestamped by a qualified third party. Join the waitlist to be notified at launch.
Thank you! Your registration is recorded. We will reach out shortly.