Sending a Document for Signature: the Workflow, Not the Law

What you send is an envelope, not a document

The unit an electronic signature service works with is not the file. It is an envelope: one or more documents, a list of recipients, a role for each of them, a set of fields tied to particular recipients on particular pages, an order of asking, and a lifecycle — created, sent, delivered, viewed, partially signed, completed, declined, voided or expired. Almost every problem people describe as "the signature did not work" is an envelope that stopped in one of those states, and knowing which state it stopped in tells you what to do far faster than reopening the document.

The consequence for how you prepare is immediate: assemble everything first. Merge the annexes, fix the page order, check that nothing is upside down, then create the envelope. Every change after that point costs you a full restart, because a signature is bound to the document as it was at the moment of signing and a new version is a new document. The habit worth building is the reverse of the one most teams have — instead of sending a draft and patching it, spend the extra ten minutes assembling and send once.

Routing order is a business decision, not a setting

Sequential routing asks one recipient at a time and only releases the document to the next when the previous one has finished. Use it when a signature genuinely depends on another — an internal approver who must see the final terms before the counterparty is asked, a guarantor who signs only if the borrower has, a countersignature that closes the deal. Its cost is that the whole chain waits on whoever is slowest, and a single person on holiday stops everything with no visible error.

Parallel routing asks everyone at once and completes when the last one is done. It is faster and it is the right default for a document several people sign in the same capacity — a board resolution, a policy acknowledgement, a multi-party framework where nobody's terms depend on anybody else's. Its failure mode is different and worse to manage: partial completion. Three of four signatures with the fourth silent leaves you holding a document that is not an agreement, that some signatories believe is done, and that will need all four again if the terms move. Set an expiry, set reminders, and know before you send who is likely to be the fourth.

One consequence of ordering is often missed: in most systems of contract law the agreement is formed when the last party accepts, so whoever signs last controls the date on which the contract exists. If a start date, a notice period or a financial year depends on it, put the party you can chase last, and never leave the closing signature with the person hardest to reach. And do not let signatories type a date by hand next to their mark. The audit trail already holds an authoritative time; a hand-typed date that disagrees with it creates a contradiction in your own evidence for no benefit at all.

The audit trail is the evidence, not the mark

A drawn or typed signature is an image. Anyone can produce one that looks like anyone else's, which means the image proves nothing by itself, and the value of an electronic signature service is not that it draws prettier squiggles but that it records how the squiggle came to be there. That record — the completion certificate, the audit trail, the event log, the names differ — typically holds the envelope identifier, each recipient's address, the time the request was sent, the time it was delivered, the time it was opened, the address it was opened from, the authentication used, the consent given to transact electronically, the moment each field was completed, and a fingerprint of the document at the moment of sealing.

That is not an engineering luxury, it is exactly what the law asks about. Article 1366 of the French Civil Code makes an electronic writing equal in probative force to paper on two conditions: that the person it emanates from can be duly identified, and that it is established and kept in conditions guaranteeing its integrity. Identification and integrity are properties of the process, not of the drawing. At European level the same logic appears in the presumptions attached to qualified services: under the eIDAS Regulation, a qualified electronic time stamp enjoys a presumption as to the accuracy of the date and time and the integrity of the data bound to it, and a qualified electronic registered delivery service enjoys a presumption as to the integrity of the data, the sending by the identified sender and the receipt by the identified addressee. Each of those is a fact about a workflow.

Practically, this means three things. Keep the certificate, not just the signed file: a sealed document without its trail is a picture of an agreement. Keep a fingerprint of the file you can recompute — a hash you store separately lets you show years later that the copy in your archive is the copy that was signed. And prefer authentication that leaves a trace someone else controls: a code sent to a phone, an identity check, a login to an account, anything stronger than a link that arrived by email. The link alone proves that whoever had access to that mailbox signed, which is a weaker statement than it sounds and is the one a dispute will attack.

When the signatory is not the party: companies and delegation

A company cannot sign anything. A natural person signs on its behalf, and whether the company is bound depends on that person's power of representation, which is a matter of company law and of the register — never something the signing platform verifies. The platform will happily let anyone with a mailbox sign as anyone, and will record faithfully that they did.

German law makes the trap concrete. Under paragraph 35 of the limited liability companies act, the company is represented judicially and extrajudicially by its managing directors, and if several are appointed they are only authorised to represent the company jointly unless the articles of association provide otherwise. An envelope built with a single signature block for a German company with two managers and no sole-representation clause produces a document that is signed and does not bind. In the other direction, paragraph 49 of the commercial code gives a Prokurist authority for all judicial and extrajudicial transactions that the operation of a commercial business entails, and paragraph 50 makes internal limitations on that authority ineffective against third parties: your internal approval matrix does not exist for the counterparty. Check the register extract before you build the recipient list, and record the capacity in the signature block itself.

Delegation deserves its own handling. Most services let a recipient reassign the request to someone else, and used properly this is a feature: the trail records who was invited, who reassigned, when, and who eventually signed, which keeps the chain visible. Used carelessly it becomes the most common way an audit trail is destroyed — the recipient simply forwards the email, and someone else signs through a link addressed to a person who never touched the document. Turn reassignment on so that people use the mechanism that records itself, and turn off, if your service allows it, the ability to sign from a link opened by an address other than the one invited.

When the document changes after someone has signed

This is the situation every signing workflow eventually meets, and the wrong answer is tempting: swap the file and let the existing signature stand. Do not. A signature answers a question about a particular document, and the person who signed answered it about the version they read. If the signature was cryptographic, replacing the bytes breaks it and everyone will see that it is broken. If it was only a drawn image — the ordinary case — nothing breaks, nothing looks wrong, and you have quietly produced a document that appears signed by someone who never agreed to it. Our article on the three eIDAS tiers covers what that image legally is; here it is enough that it is not evidence of agreement to text the signer never saw.

There are two clean routes and you choose between them on effort, not on principle. Void the envelope and reissue: mark the old one void so the trail shows a deliberate cancellation rather than an abandoned document, create a new envelope from the corrected file, and collect every signature again — including the ones you already had, because they were given to a different text. Or leave the signed document standing and sign an amendment that identifies the original by name and date and states what changes. The second is faster and is what people actually do when one clause moves after eleven of twelve parties have signed. The first is what to do when the change touches the terms the earlier signatories relied on.

Six failure modes, and what fixes each

Fields placed by coordinates. A signature block dropped at a fixed point on page seven stays at that point when the contract is regenerated with a longer recital, and lands in the middle of a paragraph or on the wrong page entirely. Use text anchors — an invisible marker string in the document that the field attaches to — so the block follows its clause. The same problem arrives through merging: append a two-page annex before the signature page and every coordinate after it is wrong. Assemble first, place fields second.

The request that never arrives. Sent is not delivered: filters quarantine mail with links, corporate gateways rewrite them, a shared or role address drops it into a queue nobody owns, an out-of-office bounces it. Watch the delivered event, not the sent one, and if it does not appear within a day, resend to a second address rather than waiting. Avoid role addresses entirely for signatories — you cannot identify a person from a mailbox that ten people read. Expiring links are the same family: envelopes and links have lifetimes, and a signer coming back after a holiday finds a dead page and often concludes the whole thing was cancelled. Set the expiry to the real deadline plus a margin, and send a reminder before it, not after.

The envelope stuck at viewed. Somebody opened it, signed the page they saw, and never reached the initial box on page four or the last required field below the fold on a phone. The status stays at viewed or in progress, everyone assumes it is done, and the document surfaces unsigned three weeks later. Reduce required fields to the minimum the document actually needs, preview the envelope on a small screen before sending, and treat a recipient who has viewed but not completed within a day as needing a phone call rather than a third reminder. And check time zones once: audit trails are usually kept in a single reference time, so an event stamped at 23:40 may be the following morning where the signer was — a discrepancy that looks like fraud in a dispute and is nothing but a display convention.

Frequently asked questions

Sequential or parallel routing — which should I use by default?

Parallel by default, sequential when there is a real dependency. Ask one question: does anyone in the list need to see what someone else did before deciding? An internal approver who must check the final price does; a guarantor who signs only after the borrower does; a counterparty who insists on signing last. Everyone else can be asked at once, and asking them at once removes days from the cycle. The hybrid that works well in practice is a two-stage flow: everyone internal in parallel, then the counterparty, then the countersignature — three stages instead of six, with only the dependencies that are real.

Someone tells me they signed but the envelope is still open. What happened?

Almost always an unfinished field or an unpressed final button. The signer drew their signature, believed that was the act, and never scrolled to an initial box on a later page or never pressed finish — on a phone the confirmation is frequently below the fold. Open the envelope's detail view rather than the summary: it lists each recipient's required fields and which are still empty, and that tells you exactly what to ask for. Two other explanations account for most of the rest: the person signed a different envelope, usually an earlier version you thought you had voided; or they signed a copy of the file that reached them another way, by email attachment, which produces a signed document that your workflow will never see. Ask them to send you what they signed before assuming the tool failed.

Can I add a page after one party has already signed?

Not to the signed document, no. Whatever the page contains, adding it produces a document that differs from the one the first party agreed to, and the fact that the signature still looks fine is a property of images rather than a licence. Two legitimate routes: void the envelope, rebuild it with the extra page and collect every signature again; or leave the signed document alone and sign a separate addendum that names the original by title and date, states what it adds, and is signed by everyone. Use the second when the addition is genuinely additional — a schedule of prices, a list of contacts — and the first when it changes anything the earlier signatory relied on. Whichever you choose, keep the voided envelope: a trail that shows a deliberate cancellation and a clean reissue is far better evidence than a gap.

A recipient forwarded their link and a colleague signed. Is that a problem?

Yes, and the problem is evidential rather than moral. The whole trail now says that the person you invited did everything — opened, authenticated, signed — while a different person did. The one thing the record was there to establish, that this signature came from this individual, is exactly the thing that is now false, and the counterparty has no way of knowing it. Fix it forward: void the envelope and reissue it to the person who actually signs, using the reassignment feature if the service has one, because that leaves a delegation event in the trail instead of a silent substitution. Fix it structurally by never inviting shared mailboxes and by turning on an authentication step the mailbox holder cannot pass on, such as a code sent to a phone number you hold.

What do I keep once the document is signed?

Three artefacts, in the same place, named so that they are obviously one set. The sealed final document. The completion certificate or audit trail, which is the evidence that the document is what it claims to be. And a fingerprint of the file — a hash you compute yourself and store separately, so that years later you can show the copy in the archive is byte-for-byte the copy that was signed rather than a re-saved, re-compressed or annotated descendant of it. That third item costs a minute and is the one nobody has when it matters. As for how long, retention follows the underlying obligation rather than the signature: a commercial contract, an employment file and a tax-relevant document have different periods, and the safe default is to keep the whole set as long as any claim under it could still be brought.