What makes a one-click signature provable

A customer says they never agreed to the cancellation fee. You know they did, because your booking form has a required checkbox next to the terms, and the booking exists, so the box was ticked. You open the submission to show them. What you find is a row: a name they typed, an email they typed, a timestamp, and the word "yes" in a column headed "Terms".

Under the federal definition, that row can be a signature. It may also be almost impossible to use as one, and the reason lives in the difference between what the law says about electronic agreements and what it declines to say.

I am not a lawyer, none of this is advice about your contracts, and the statute below is federal law of the United States only. Other jurisdictions have their own rules and their own definitions. What follows is the text of the Act, read on 7 September 2026 from the two official publications of the US Code, and the documentation of eleven products that people actually use to collect an agreement, read on 8 September 2026.

The law says one thing, and it is a negative

The Electronic Signatures in Global and National Commerce Act, 15 U.S.C. § 7001, opens like this:

"Notwithstanding any statute, regulation, or other rule of law (other than this subchapter and subchapter II), with respect to any transaction in or affecting interstate or foreign commerce—

(1) a signature, contract, or other record relating to such transaction may not be denied legal effect, validity, or enforceability solely because it is in electronic form; and

(2) a contract relating to such transaction may not be denied legal effect, validity, or enforceability solely because an electronic signature or electronic record was used in its formation."

15 U.S.C. § 7001(a), text in effect on 7 September 2026

Read the verbs. "May not be denied ... solely because." The section forbids one specific bad reason for refusing to honour an agreement, which is that it was made electronically. It does not say an electronic signature is valid, or anything about how you show who made it, what they were shown, or whether they meant to sign. All of that is left exactly where it was before the Act existed, and the next subsection says so:

"This subchapter does not—

(1) limit, alter, or otherwise affect any requirement imposed by a statute, regulation, or rule of law relating to the rights and obligations of persons under such statute, regulation, or rule of law other than a requirement that contracts or other records be written, signed, or in nonelectronic form"

15 U.S.C. § 7001(b)(1)

One requirement is displaced: that a thing be on paper, or signed in ink. Every other requirement stands. Which means the weight the paper used to carry, the weight of being evidence, has to be carried by something else.

A tick in a box can be a signature

The definitions section settles the question people argue about most, and it settles it generously:

"The term 'electronic signature' means an electronic sound, symbol, or process, attached to or logically associated with a contract or other record and executed or adopted by a person with the intent to sign the record."

15 U.S.C. § 7006(5)

"Sound, symbol, or process" is deliberately enormous. A typed name fits, so does a drawn squiggle, and so does a click or a tick in a box. Anyone who tells you a checkbox is not a real signature is arguing with the definition.

The constraint sits in the tail of the sentence, and it has two halves: "executed or adopted by a person", and "with the intent to sign the record". Both halves are facts about a moment in the past rather than properties of the checkbox, and if the agreement is ever disputed, both are facts you will be asked to establish. Who was the person? How do you know it was them? What did they see when they ticked, and does it show they meant that tick as signing?

When a checkbox fails as a signature, it fails because it left nothing behind that answers those questions.

The same section defines a record as information that "is retrievable in perceivable form". Retrievable is in the definition. A record you cannot get back is, in the statute's own terms, not quite a record.

One letter apart, opposite in effect

Subsection (a) says an electronic record "may not be denied" effect for being electronic. Four subsections later the Act uses almost the same words to say the opposite thing about a different defect:

"Notwithstanding subsection (a), if a statute, regulation, or other rule of law requires that a contract or other record relating to a transaction in or affecting interstate or foreign commerce be in writing, the legal effect, validity, or enforceability of an electronic record of such contract or other record may be denied if such electronic record is not in a form that is capable of being retained and accurately reproduced for later reference by all parties or persons who are entitled to retain the contract or other record."

15 U.S.C. § 7001(e)

"May not be denied" and "may be denied", one letter apart. The Act rules out one defect, being electronic, and admits another: a record that cannot be retained and reproduced later, where some other law wanted the thing in writing in the first place.

The retention subsection says what "kept" means when a law requires a record to be kept: an electronic copy that "accurately reflects the information" and

"remains accessible to all persons who are entitled to access by statute, regulation, or rule of law, for the period required by such statute, regulation, or rule of law, in a form that is capable of being accurately reproduced for later reference, whether by transmission, printing, or otherwise."

15 U.S.C. § 7001(d)(1)(B)

Hold on to "for the period required by such statute". The period is set by whatever law governs your document, and the vendor whose server the document sits on has no say in it.

The consent clause people get backwards

Subsection (c) is the long one, about consumers, and one clause in it is quoted online more than any other part of the Act. Where a law requires information to be given to a consumer in writing, an electronic record satisfies that requirement only if, among other conditions, the consumer

"consents electronically, or confirms his or her consent electronically, in a manner that reasonably demonstrates that the consumer can access information in the electronic form that will be used to provide the information that is the subject of the consent"

15 U.S.C. § 7001(c)(1)(C)(ii)

The popular reading is that if you skip this step, your contract is void. Two paragraphs further down, the Act says otherwise:

"The legal effectiveness, validity, or enforceability of any contract executed by a consumer shall not be denied solely because of the failure to obtain electronic consent or confirmation of consent by that consumer in accordance with paragraph (1)(C)(ii)."

15 U.S.C. § 7001(c)(3)

So the contract survives. What you lose by skipping the demonstration is narrower and more specific: the electronic record stops counting as the "writing" that some other law required you to give the consumer. A safe harbour closes, and the deal stays standing.

Read the clause as three conditions rather than one: the consumer affirmatively consents to receive the information electronically, the business clearly and conspicuously discloses the specified information before obtaining that consent, and the consent is conveyed in a manner that reasonably demonstrates the consumer can access information in the form that will be used. The third is the one that automation skips, because a checkbox on a web form demonstrates nothing about the inbox the documents will later go to.

What the Act leaves out

Section 7003 keeps six categories of record outside the Act, and the list is short enough to give in full. It says the provisions "shall not apply to a contract or other record to the extent it is governed by" three bodies of law: rules "governing the creation and execution of wills, codicils, or testamentary trusts"; state rules "governing adoption, divorce, or other matters of family law"; and the Uniform Commercial Code, "as in effect in any State, other than sections 1–107 and 1–206 and Articles 2 and 2A".

It then lists three more categories: court orders, notices and official court documents; four kinds of notice, covering the cancellation of utility services, default or foreclosure or eviction under a credit or rental agreement for someone's primary residence, the cancellation of health or life insurance benefits, and product recalls that risk health or safety; and documents that must accompany hazardous materials.

Three things about that list. The words are "shall not apply": for those records the Act stops supplying a rule, and whether they can be signed electronically is left to other law. The insurance exception covers notices of cancellation or termination only, and the Act states elsewhere that it is Congress's "specific intent" that it "apply to the business of insurance". And there is no exception for employment documents, health consent forms or ordinary commercial leases, all of which turn up on lists of things you supposedly cannot e-sign. If a category is not in the text above, the Act does not exclude it, which says nothing about what other federal or state law asks of that document.

Which documents in your business are signed by a click, and where does each click's record live? For most companies that runs to a longer list than they expect, and drawing it up is part of what a process audit does.

What a signing tool writes down

The Act asks three things of you when an agreement is disputed: who signed, what they saw, and whether the record can be reproduced. Products built for signing exist to answer those three, and their documentation describes the answers in detail.

DocuSign attaches a Certificate of Completion to every envelope. Its help page, last updated 2 July 2026, describes the signer section:

"Provides details about each signer on the document. This information includes the signer's IP address and other identifying information, signature image, and key event timestamps. Also listed is the executed legal disclosure, recorded as the Electronic Record and Signature Disclosure."

DocuSign, Certificate of Completion, last updated 2 July 2026

Two details on that page matter more than the field list. The first is that the record distinguishes between opening a document and seeing it. DocuSign's event history records "Opened" for the moment "The recipient clicked the link to view the documents", and separately "Viewed" for when "The recipient opened the documents all the way to a viewable state", past the disclosure and into the pages themselves. A form builder has no such distinction, because it never knows what the page showed.

The second is that failures are written down. The same history records events named "AccessCode Failed", "IDCheck Failed", "SMS Authentication Failed" and "Phone Authentication Failed", each alongside its passing twin. A checkbox records two states, ticked or blank, and nothing about the attempts in between.

And the certificate is honest about its own gaps. If the account's settings did not require the signer to accept the legal disclosure, the certificate says so: the disclosure "is listed as 'Not Offered via Docusign' and is not attached to the CoC." The absence is recorded as an absence, in words.

Dropbox Sign publishes the most granular field list of any vendor I read, in its developer documentation. Two rows of it are the ones to remember:

Document uploaded | Document hash (SHA-256)

Request completed | Final timestamp, document hash

Dropbox Sign, Security and Compliance

A hash before anyone signed and a hash after everyone did. That pair is what lets a vendor say, of a document produced in a dispute, whether it is the same document. The page describes the whole trail as "Automatically generated and cannot be modified", and the help centre adds the operative sentence:

"The audit trail is an important part of how Dropbox Sign identifies that your signer is who they say they are, and it's part of what makes Dropbox Sign legal. For this reason, it can't be turned off altogether."

Dropbox Sign, separate audit trail, updated 13 August 2026

DocuSign states the property that all of this adds up to, in a sentence about why it keeps transaction data at all:

"Transaction data provides an audit trail of the transaction, allowing Docusign to function as a neutral third party in the event a customer's transaction is challenged—even if it's related to the transaction's very existence."

DocuSign, Use of Transaction Data

That is the whole difference in one phrase. The record of the signing is kept by somebody who has no stake in the dispute, in a shape the sender did not design and cannot edit, and it records what went wrong as well as what went right. That arrangement does the work, and every field on the certificate is a consequence of it.

The tool does not settle it either

It would be convenient if the story ended with "use a proper signing product". The vendors' own pages say it does not.

Adobe Acrobat Sign produces an audit report for every agreement. Its page on IP addresses, last updated 4 July 2025, opens:

"By default, the Acrobat Sign audit report does not record the IP addresses of the events recorded by the various parties."

Adobe, Request IP addresses of signers

The same page gives the history, and it is unusually candid. The default "changed on June 16, 2021", from recording IP addresses to not recording them. Users created before 17 June 2021 kept the old default; users created after kept the new one. Adobe describes the result as "an inconsistent experience when reviewing audit reports from different users in the same group", and says the behaviour was only aligned to the account's creation date "On April 26, 2024". For nearly three years, two colleagues in the same company, on the same paid product, could produce audit reports that differed in whether an IP address appeared, depending on which side of a date in June 2021 their user accounts were created.

PandaDoc splits its record across two artefacts, and only one of them has a documented off switch. Its signature certificate lists "Signers' IP addresses and location" and timestamps for sent, viewed and completed. Its audit trail, the step-by-step history, carries this line:

"This feature is enabled by default on Starter, Business, and Enterprise plans. To disable/enable back, go to the Extension > select Workspaces > uncheck/check workspaces where you'd like to disable/enable this feature, and select Save changes."

PandaDoc, Review audit trail for sent documents

One vendor says its trail cannot be turned off at all. Another documents the menu path for turning it off, per workspace. Both are purpose-built signing products, and a business that has bought one of them has not, by that fact alone, kept the record.

Then there is how long the record lasts. DocuSign's retention page, last updated 14 October 2025:

"By default, Docusign securely retains all customer documents on the service for as long as the account is active. When an account is closed, Docusign may retain all sent, signed, and voided envelopes for a period of approximately two years from the date of account closure to meet legal, compliance, auditing, or security obligations."

DocuSign, Envelope purging

"For as long as the account is active." Then "may retain", for "approximately two years". Put that beside § 7001(d)(1)(B), which wants the record accessible "for the period required by such statute", and the two clocks are visibly different clocks. The law's period depends on what the document is. The vendor's depends on whether you are still paying. PandaDoc's version of the same fact is shorter: "A completed document is public (available for a recipient/signer) for 6 months after completion."

There is one subtle and useful thing on DocuSign's data-management page: if you purge envelopes, "we provide an option to retain the audit log data (which includes the Certificate of Completion and history)". The evidence that a document was signed and the document itself are separable. You can keep the proof and let the content go.

What a form writes down

A small business usually collects agreement through whatever form was already there: the booking page, the intake questionnaire, the checkout. This is what those forms keep.

Google Forms exposes the complete shape of a stored response through its API. The object has seven fields: a form id, a response id, a creation timestamp, a last-submitted timestamp, an email address that the documentation itself qualifies as "(if collected)", the answers, and a score. There is no field for an IP address, a device, or the text of the form as it stood when the response was submitted. And Google's help centre says, of forms restricted to signed-in users:

"Tip: To access and fill out the form, users must sign in to their Google Account. Their usernames won't be recorded unless you turn on the "Responses" setting to collect email addresses."

Google, Edit your form

Read that beside "executed or adopted by a person". An authenticated human completes your form, and by default the system does not write down who they were.

Typeform records a start time and a submit time, and explains its identity field:

"We don't store respondent IP addresses, although we use the IP address to generate this ID. If several respondents connect through the same network or WiFi, they'll have the same generated Network ID."

Typeform, Working with your responses

Tally, on the same question, puts the whole problem into one sentence of its own documentation. Asked whether it collects IP addresses: "No, currently we don't collect IP addresses." And on the email field people rely on instead:

"Respondents can bypass this check by entering any type of content they want. For example, a respondent can enter an email address that is not theirs."

Tally, Prevent duplicate submissions

A typed email address is content. The vendor says so.

Jotform is the interesting middle case, because it does capture an IP address and then hides it: "The Submission IP is a built-in column in Jotform Tables but is hidden by default." The evidence exists and the person relying on it has usually never seen the column.

Calendly's guidance for collecting consent through a booking form is to add a custom question with a single checkbox, put the consent text in the question, and, for the link to what is being agreed: "If the link is too long, shorten it using a link-shortening service." A shortened link can be repointed after the fact. The record keeps the tick and a URL, and the page behind that URL is whatever it says on the day somebody looks.

The sharpest example is Stripe, because Stripe documents both sides of the same act. When you ask Checkout to require a terms-of-service checkbox from your customer, the record it keeps is the field consent.terms_of_service, whose documented value on success is one word: "accepted". The API reference for the session object has no consent date, no consent IP and no record of which version of your terms was shown.

When Stripe collects agreement to its own terms from you, the account representative, the fields it documents are these:

tos_acceptance.date ... The Unix timestamp marking when the account representative accepted their service agreement.

tos_acceptance.ip ... The IP address from which the account representative accepted their service agreement.

tos_acceptance.user_agent ... The user agent of the browser from which the account representative accepted their service agreement.

Stripe, Create an account

Same company, same gesture, a box ticked to accept terms. When the party who may one day need to prove it is Stripe, the record is a timestamp, an address and a browser. When that party is you, the record is "accepted".

	Signing product	Form builder or checkout
Timestamps	Per event: sent, opened, viewed, signed, declined	One or two: submitted, sometimes started
Who signed	Email plus optional access code, SMS, phone or ID check, with failures recorded	A typed string, or nothing by default
What they saw	Disclosure text carried in the certificate (DocuSign, Zoho); the sending email preserved (PandaDoc)	Not kept; a link to a page that can change
Document integrity	Hash before and after signing (Dropbox Sign)	Nothing
IP address	Recorded (DocuSign, Dropbox Sign, PandaDoc's certificate); off by default (Adobe)	Not stored (Typeform, Tally); no field (Google); hidden column (Jotform)
Can the record be switched off	No (Dropbox Sign); yes, per workspace (PandaDoc)	Nothing to switch off
After you stop paying	"May retain" for "approximately two years" (DocuSign)	Not stated on the pages read

Every cell in that table is from a page cited below. Vendors change their pages, and none of it is contract text.

Where this leaves you

The law took one objection off the table, and only one. Everything that used to be proved by a piece of paper with ink on it still has to be proved, by something. Three questions cover it.

Who ticked the box, and how do you know? If the answer is "they typed their email", Tally has told you what that is worth. If the answer is "the tool authenticated them", check whether your tool records the attempts, and whether the setting that records them is on.

What were they shown? A form keeps the answer and a link. A signing product keeps the disclosure text, and PandaDoc keeps the covering email. If your terms have changed since the tick, ask which version the record points at, because Google's response object does not know.

Can you produce it later, and from where? The statute's word is "retrievable", the retention period is set by the law that governs your document, and the vendor's default is set by your subscription. If the account that holds the record is the one you cancel when you switch tools, the record goes with it, on the vendor's schedule rather than yours.

Answering those questions takes one person and an afternoon with the current tool, looking at what it actually keeps. It is the same discipline as agreeing what "done" means before you pay for software, applied to the customer's side of the agreement: the expensive requirement is the obvious one nobody wrote down. It is also a close cousin of how long your automation keeps its history, where the record you assume exists sits on somebody else's retention schedule, and of which system owns a field, because a consent flag synced between two systems has the same problem as any other field: one copy is the record, and nobody said which.

If you would rather have that written down than discover it during a dispute, listing every place your business collects an agreement, what each one records, and where that record lives is part of the process audit. $299, three business days, and a written map you keep whether or not you hire us.

Nothing here is legal advice, and the law described is United States federal law only.

Related: the order was cancelled after the invoice went out is what happens to the paperwork on the other side of an agreement that changed.