How to Void a Signature Request (and When To)
Voiding a signature request ends it on purpose and keeps the record that it existed. That distinction decides when voiding is the right move, and when you should delete a draft or send a corrected copy instead.
A signature request is a live object: it has a recipient, a document version, and a status. Voiding is the action that ends it deliberately. One vendor help page reviewed for this post describes voiding as canceling the signature request and preventing further actions on it. A separate community answer points to canceling the transaction as the way to stop an unwanted request from sending reminders. Naming differs by platform (void, cancel, withdraw), but the intent is the same: the request stops, and the signer can no longer act on it.
Void, delete, resend: three different intents. These get confused because each makes a problem go away from the sender's side. They do different jobs.
- Void ends a request that is already out. The request existed, and the record should say so.
- Delete removes something from view. It fits a draft that was never sent, where no signer ever saw anything.
- Resend delivers the same request again, with the same document and the same terms. It fits a signer who missed the first message.
Choosing by intent avoids the common errors. Resending a request whose terms have changed puts an outdated document in front of the signer a second time. Deleting a sent request raises a different question: whether the signer's link still works afterward depends on the platform, which is a good reason to check before relying on delete as a substitute for void.
When voiding is the correct move. Three situations account for most cases.
- Wrong document version. You sent the draft with the old price, or the file from before the last round of edits. The signer should not be able to sign it, and you should not be left explaining why a signed copy of the wrong version exists. Void it, fix the document, send a new request.
- Changed terms. The buyer negotiated after the link went out: a different price, a swapped item, a new shipping arrangement. Editing the live request is not the answer, because the signer may already have opened the earlier terms. Void the original and issue a new one that reflects the deal as it now stands.
- Duplicate request. Two requests for the same deal are in flight, often because a message looked undelivered and the sender started over. Void one so there is exactly one valid request, and the signer is not choosing between two documents.
A fourth case is related: the request went to the wrong person. Void it first, then send the corrected request to the right recipient.
When voiding is the wrong move. If the signer simply has not responded, void is too blunt; a reminder or a resend is the right tool. If the only problem is a typo in an accompanying message and the document itself is correct, there is nothing to void. And once both parties have signed, no pending request remains to cancel. A change at that point is a new document, not a voided one.
What voiding does to the audit trail. This is the strongest argument for voiding over deleting. A clean record of a corrected deal reads as: request sent, request voided with a reason, new request sent, new request signed. Each step is visible, and nobody has to reconstruct what happened from memory. One vendor help page notes that the reason you enter when voiding is logged in the audit trail, though it describes the reason as optional. Treat it as required in practice: a short, specific reason such as 'price updated after revised offer' is more useful later than a blank field.
For lockd, the site describes every action, from drafted to sent to signed to finalized, as timestamped with an IP address. The pages reviewed for this post do not describe how a void appears in that record, so confirm that in the product before you build a habit around it. The general principle holds either way: the trail should show that the first request ended before the second began.
What the signer experiences. This is the part senders underestimate. According to one vendor page, voiding notifies all participants. A customer feedback thread for another e-signature product shows how that lands from the sender's side: one user described being forced to explain a mistake in a notice that went to every party, and found it embarrassing. Another community post comes from a sender whose recipient kept getting reminders for a request that was no longer needed, and who found them irritating.
Both complaints point to the same practice. Void promptly, so reminders stop, and write the reason as a neutral, factual line, not an apology. If your counterparty receives requests as a link in a chat app or by SMS, tell them directly before the automated notice arrives: 'Pulling that link, new one coming in a minute, price is updated.' Then send the replacement immediately, so the signer sees one dead request followed by one live one, not a gap.
A short checklist before you void.
- Confirm the request is still pending and has not been signed.
- Know what the replacement will be: corrected document, updated terms, or correct recipient.
- Enter a specific reason that you would be comfortable having the signer read.
- Message the signer yourself so the system notice is not a surprise.
- Send the new request and confirm the record shows the void and the replacement in order.
Voiding is a small action with a precise job: it retires a request without pretending it never happened. Use delete for drafts nobody saw, resend for requests that were missed, and void for everything that went out and should no longer be signed.