E-signatures

E-signature for freelancers

A freelance contract is the simplest signing case there is: one document, one signer, one deadline. The craft is in what you initial, what you write in the covering message, and what you do on day four when nothing has happened.

· Co-founder

6 min read · Published

The gap between a client saying yes and a client signing is where freelance work goes to die. Not because anybody changed their mind, but because the contract went out as an attachment, the client meant to print it, and then it was Thursday.

Closing that gap is mostly logistics, and the logistics are worth getting right once. This is general information rather than legal advice, and contract law differs by country, so check your own position before relying on any of it.

One signer, one document, one day

Freelance work is the easy case. One PDF, one other person, no approval chain, no legal department. Everything that makes signing complicated for a company is absent.

The laws support that shape without ceremony. The US ESIGN Act provides that a signature, contract or record may not be denied legal effect, validity or enforceability solely because it is in electronic form. In the UK, section 7 of the Electronic Communications Act makes an electronic signature admissible in evidence on questions of the authenticity or integrity of the data. Article 25 of the eIDAS Regulation says a signature is not denied legal effect or admissibility merely because it is electronic or is not a qualified one. Australia’s Electronic Transactions Act asks instead whether the method identified the person, showed their intention, and was as reliable as appropriate for the purpose.

None of that is a promise about your particular contract, and small contracts still fall over on things that have nothing to do with signing. But the format itself is not the obstacle people assume.

Prepare: signature, initials on payment terms, date signed

Three field types carry a freelance contract, and a fourth is a trap.

Signature. One per signer, on the execution block. The default box is 200 by 60 points, which is roughly a comfortable ink signature at reading size.

Initials on the payment clause, and only there. Initials say a particular clause was read. On a freelance agreement the clause worth that claim is the one about money: rate, schedule, late payment, and what happens if the scope grows. Initialling all six pages adds five clicks and no evidence, because the certification already covers the whole file against later changes.

Date signed. Place the field, do not ask for a typed date. It is stamped from the recorded signing time and cannot be typed, and it prints in the form Aug 22, 2026. A typed date is whatever the client felt like entering.

The trap is the checkbox. There is no tick control in the signer’s view: a placed checkbox falls through to a plain input the signer types into, and the stamper prints the letter X whenever the field holds any value. Useful as a mark, useless as a yes or no you can query later. The freelance contract example shows a document written to be signed in this shape.

The message that gets it signed

The covering message is a field on the request, capped at 2000 characters, and it appears in the invitation email above the button. Almost nobody uses it well.

Three lines is the right length. What the document is, what it commits them to in one sentence, and when you need it back. “Here is the agreement for the five weeks starting 14 September, at the rate we discussed. It covers scope, payment terms and what happens if the brief grows. If you can sign by Friday I can hold the dates.”

What not to do is put anything sensitive in the title. The request title is returned before any identity check passes, so whoever holds the link sees it whether or not they can open the document.

What the client sees

An email with a document panel, who they are signing as, when it expires, your message, and a button. No account, no download.

If you set an identity check they see the challenge card first, showing the title, their own name and which check is needed, and nothing about the document. Once through, the contract opens with only their fields highlighted, consent sits as a hard gate at the bottom, and the signature pad offers drawing or typing. Which one they chose is recorded in the audit trail as part of the signed event.

On a phone the whole layout changes to the compact mode, which is worth knowing about because most clients are on a phone.

When they stall: resend, void, expiry

The table below is the whole lifecycle: every step, the events written to the audit trail, and what you can still do at that point.

The one thing worth internalising is that resending rotates the link. The old URL stops working, the viewed state resets, any lockout clears, and a resent event is appended. So a resend is not a nudge with a duplicate; it is a replacement, and it is also how you rescue a client who locked themselves out with a wrong code. It is refused once they have signed or declined, which is correct. Resending a signing invitation covers the mechanics.

Voiding is the other lever. It takes an optional reason of up to 500 characters, moves outstanding recipients to expired, and emails everyone who was still holding a live link. Use it when the job is off, rather than leaving a live contract in someone’s inbox for a month.

And every request expires thirty days after it was created, whatever you do. Nothing in the application changes that date.

After: certificate, copies, storing it

When the client signs, the file is certified and the completion email goes to both of you with the certified PDF attached. Neither of you has to log in to get a copy, and the client keeps theirs without being your customer.

The certificate of completion is written as its own PDF and lists the identity check, the signing time, the IP address, the consent timestamp and version, the hash of the document that client actually saw, and the full event log. Store it beside the contract. A signed PDF on its own answers whether the file changed; the certificate answers everything a person would ask. If you want to know what a reader will make of the file later, how to check if a PDF is signed walks through it.

The example

The worked example below is an independent contractor agreement, the document where the interesting clause is not the price but the table setting out who controls the work. That is the page worth initialling, and the reason to send the thing for signature rather than trusting a reply that says “looks good to me”.

From send to signed: what the audit trail records at each step, and what you can still do
What is happeningEvents writtenWhat you can do at this point
You send the requestcreated, document_attached, sentNothing further. A sent request cannot be edited at all
The invitation goes outinvited, or delivery_failed if it bouncesA bounce means the address is wrong, and a wrong address needs a new request
The client opens the linkopenedWait. This is not the same as reading it
A code is requested and enteredauth_challenged, then authenticated or auth_failedFive wrong attempts lock them out for fifteen minutes
The client reads the documentviewedWait
The client signssigned, with the signature type, its hash and the document hashNothing to do
Four days of silenceNothing is writtenResend, which rotates the link, kills the old one and clears any lockout
They want changesdeclined, carrying their reasonEdit the document and send a fresh request. There is no amend in place
You change your mindvoidedVoid with an optional reason. Everyone still holding a live link is emailed
Thirty days passexpiredA nightly sweep expires it, and the link then says so instead of opening
The last signature landscertified, then completedThe certified PDF and the certificate are emailed to both of you

A finished example

A builder engages a carpentry business for one house. The interesting clause is not the price, it is the table that writes down who controls the work, because that is what decides whether this is a contract at all.

Read the independent contractor agreement

Questions people ask

Does the client need an account?

No. They get an email, open a link, verify themselves if you asked for a check, sign and close the tab. Nothing they do requires a login, a download or a password, and nothing about their side of it costs them anything. That matters more than it sounds, because a sign-up wall is where same-day turnaround usually dies.

Can they sign on a phone?

Yes, and many will do it standing up. Below 560 pixels the portal switches to a compact layout: the document goes read-only, every typed field moves into a panel above it, and a counter walks them from one signature spot to the next. One drawn mark fills every signature and initials position at once, so a five page contract is still one gesture.

What if they want changes?

They decline with a reason, which reaches you by email, and the request closes. A sent request cannot be edited, so you change the document and send a new one. That sounds clumsy and is actually the right behaviour: it means nobody can alter a document that somebody is in the middle of reading, and the version they saw is the version on record.

How long is the link valid?

Thirty days from when the request was created, and that is fixed. The application offers no way to set a different date, so every request you send runs on the same clock. If a contract goes quiet for a month, it will expire on its own, and you send a fresh one rather than reviving the old link.

Can I sign first?

Yes. Put yourself in as a recipient, first in order, and turn sign in order on. Your signature is stamped into the working copy before the client is invited, so what they open already carries it. Watch the switch though: a new request stores order enforcement as on while the screen shows it off, so set it deliberately.

What do I keep as proof?

Two files, and both arrive by email. The certified PDF, which carries a signature that any change would invalidate, and the certificate of completion, which lists the identity check, the signing time, the IP address, the consent version and the document hash at signing. Keep them together, because each one answers a question the other does not.

Can a form response be sent for signing instead?

Yes. A submitted form response can be rendered and handed to signing as its own request, one per response, with a recipient for each e-signature component on the form. It suits a short engagement where the brief and the agreement are the same piece of paper, and it saves writing a contract from scratch for a two day job.

Written by

Nuwan Madhusanka · Co-founder

Works across the builders and the export paths: how a form becomes a PDF, how a flyer canvas becomes a print file, and how a signed document carries its audit trail.

LinkedIn profile

Sources

Written and checked by the OneCraft team. Last checked .

Make your own signing flow

Describe what you need and the generator writes and designs it, then you edit anything you like.

See what it can make

Read next

For the steps inside the builder, read the guideon this topic.