What Counts as Proof That a Client Approved Your Work?

If a client says six months later that they never approved this version, the argument is rarely about honesty. It is about what each of you can still show. Two people can remember a call accurately and remember two different calls.

So the useful question is not did they approve it. It is: what would help establish who accepted what, and when?

This article is general information about evidence and record-keeping. It is not legal advice, and Stria is not a law firm. Requirements vary by jurisdiction, transaction type, contract terms and the facts of a situation. For anything with real money or real risk attached, ask a lawyer in the relevant jurisdiction.

The short answer

A useful approval record connects four things to each other, in one artifact, at one moment.

Miss one and the others weaken. A perfectly timestamped, fingerprinted approval from someone, we are not sure who settles very little. So does a signature from a named client on the design, version unspecified.

What that record then means legally is a separate question, and it depends on the jurisdiction, the contract, the transaction type and the facts. No tool can answer it for you, and any vendor that offers to is answering a question it is not qualified to answer.

Approval is not one thing

Most approval arguments are really vocabulary arguments. Six different events get called approval, and they have different consequences.

Feedback. The client reacted. "This is coming together" is a mood, not a decision, and treating it as one is how a project ends up delivered against a comment thread.

Acceptance. The client agrees the work meets what was asked for. This is the one most freelance disputes actually turn on, and the one most often left implicit.

Authorisation to proceed. The client is telling you to spend time or money on the next step. It is forward-looking, and it says nothing about whether the previous step was accepted.

Final sign-off. The client accepts this version as done, which normally means later changes are new work. This is the event worth building a record around.

An electronic signature. A legal concept, not a UI element. Under the US ESIGN Act and the state-level UETA, an electronic signature is defined functionally: an electronic sound, symbol or process attached to or logically associated with a record and executed or adopted by a person with the intent to sign it. The EU's eIDAS Regulation is likewise technology-neutral. None of them prescribe a mechanism, which is why a click, a typed name and a drawn squiggle are all capable of being signatures and none of them automatically is one.

A contract amendment. Changing what the parties owe each other. An approval of a deliverable is usually not this. A signed change order usually is. Conflating them is how people end up believing an approved mockup silently repriced a project.

Five things that get treated as interchangeable

This is the distinction that does the most work in a dispute, and it is almost always collapsed. These are separate questions with separate answers.

1. Did an event occur? Somebody did something at a time. This is a factual question about records.
2. Was a contract formed or varied? A question about offer, acceptance, consideration and the terms you already have.
3. Was there a valid electronic signature? A question about intent to sign, consent to transact electronically, and any statutory requirements that apply.
4. How confident can anyone be about identity? A spectrum, from an anonymous session at one end to a checked government document at the other.
5. How much weight will the record carry, and will the obligation be upheld? Questions for a tribunal, on the facts, under the applicable law.

Strong evidence on question one does not settle questions two through five. A great record makes questions two and five easier to argue. It does not decide them.

It is also worth knowing that whole categories sit outside the general electronic-signature regimes. ESIGN's own exceptions include wills, codicils and testamentary trusts, state family-law matters such as adoption and divorce, most of the Uniform Commercial Code, court orders and official court filings, certain notices about utilities and about a primary residence, cancellation of health or life insurance benefits, product recalls affecting health or safety, and documents accompanying hazardous materials. If your transaction is near any of those, a general article is the wrong tool.

Where the rules come from depends on where you are

None of this is one global regime, and the differences are not cosmetic. In the United States, ESIGN operates alongside UETA, which has been adopted by every state except New York — and New York has its own Electronic Signatures and Records Act instead, which its own bar association describes as out of step with both federal law and the model act. In the EU, eIDAS applies directly and was amended in 2024 by the European Digital Identity Framework, in force since 20 May 2024. In Canada, Part 2 of PIPEDA sets out characteristics for a "secure electronic signature" and amends the Canada Evidence Act, and the federal government publishes its own guidance on assurance levels for different kinds of business. Internationally, the UNCITRAL Model Law on Electronic Signatures frames the question as reliability appropriate to the purpose, which is a useful way to think even where it is not the law.

The practical upshot: a record that would satisfy one of these can be inadequate under another, and none of them is decided by which software produced it.

How an electronic record gets treated as what it claims to be

Worth separating from validity, because it is the question that actually arises first. Before a record can help, someone has to establish it is genuine.

In US federal practice that is authentication, and two provisions matter for records a tool produces. Federal Rule of Evidence 901(b)(9) allows authentication by evidence describing a process or system and showing that it produces an accurate result — which is why how your tool works can matter as much as what it recorded. And Rules 902(13) and 902(14), added in 2017, let certain records generated by an electronic process, and copies taken from an electronic device, be self-authenticating on a written certification by a qualified person rather than live testimony (Federal Judicial Center summary).

Two things follow, and they cut in opposite directions. A well-documented, consistent process is worth something in its own right, separately from the artifact. And none of this is automatic: a certification still has to be made by someone who can speak to the system, and the rules above are one jurisdiction's, not a universal standard.

A framework for reading your own approval record

Nine properties. No scores, because a score would imply a legal weighting nobody here is qualified to assign. Read it as a list of gaps to close in whatever order is cheapest for you.

The order matters less than the honesty about which ones you actually have. Two of them — exact version and clear affirmative language — need no software at all, which makes them the sensible place to start whatever else you do.

If you would rather work through it interactively, the Approval Record Check asks these nine questions and returns a plain description of what your current workflow does and does not capture. It runs entirely in your browser and asks for nothing about your clients or your projects.

What the common approval methods actually carry

Three of these deserve more than a table row.

Email is better than its reputation and worse than people assume

Email is genuinely useful evidence: two independent copies, a date, and the client's own phrasing rather than yours. Its weakness is almost never authenticity. It is attachment — the message says "approved" and the thing approved is a link to a file that has been edited eleven times since.

The cheap fix costs one sentence. Quote the version and the filename in your own message, so their reply lands on top of it.

A click is an act, and an act needs a subject

A button press is a perfectly good affirmative act. The question is what it was attached to and who did it. A share link forwarded to a marketing manager, two colleagues and a contract copywriter produces a click from the team, which is not a person.

Two mechanisms narrow that: send a one-time code to an email address and require it back before the approval is written, and record the exact wording the person agreed to. Neither establishes who someone is. Both change the record from an anonymous session to a specific mailbox and a specific sentence.

"Resolved" is not "accepted"

Project tools resolve comments to clear a queue. That is a workflow state, chosen for tidiness, often by you rather than by the client. Reading it later as acceptance is a reconstruction, and the other side will say so.

What a content hash does and does not prove

Hashes get oversold, so here is the plain version.

A hash function such as SHA-256 takes an input of any length and produces a short fixed-length digest. NIST, which publishes the standard, describes the purpose directly: the digests are used to detect whether messages have been changed since the digests were generated.

That gives you one specific thing. Store the digest at the moment of approval; recompute it later from the content as it stands. If the two match, that supports a conclusion that the content is unchanged. If they differ, something moved, and that is visible rather than arguable.

What a hash does not do:

• It does not identify anyone. A digest is a function of content, and content has no author attached.
• It does not establish authority, intent, or consent.
• It does not prove when the content existed. Only a timestamp from something trustworthy does that, and a hash sitting next to a timestamp does not upgrade the timestamp.
• It is not encryption. Nothing is concealed and nothing is recoverable; there is no key and no decryption step. "Encrypted hash" is a contradiction, and a vendor using the phrase is telling you something about their engineering.
• It only covers what went into it. A digest computed over a title, a version number and a link does not cover the pixels on the other end of the link. Ask any vendor exactly which bytes are hashed, and treat a vague answer as a no.

The honest word for what a hash gives a record is tamper-evident: interference shows. Not tamper-proof, which would claim interference is impossible.

The wording that turns a reply into an approval

This is the highest-leverage change on the page, and it is free.

Wording that leaves the question open:

• "Looks good"
• "I think we're done here"
• "Fine by me"
• "No notes!"
• "Happy with this, thanks"

Every one of them is warm, sincere, and silent on three things: which deliverable, which version, and whether the sender is accepting the work or cheering you on.

Explicit language does four jobs. It names the deliverable and the version. It states acceptance rather than pleasure. Where it matters, it says the acceptance is final and what follows from that. And it makes the consequence visible, so nobody is surprised later.

A workable shape, to adapt to your own contract and voice:

I approve Homepage Design v3, delivered 12 March, as final.
I understand that further changes will be quoted as new work
under the change process in our agreement.

Two cautions. This is not model legal language and it is not universal: what makes acceptance effective depends on your contract and your jurisdiction. And you should not send it yourself and treat silence as agreement — the point is to make it easy for the client to say plainly, not to manufacture their words. Asking "can you confirm you're approving v3 as final?" gets you there without putting a script in their mouth.

If your project has a defined acceptance step, say so in the agreement rather than inventing one per project. Contract clauses that prevent scope creep covers the wording that makes an acceptance step exist, and how to tell a client something is out of scope covers the conversation on the other side of it.

An approval workflow you can run this week

Nine steps, none of which require buying anything.

1. Confirm who approves. One named person, agreed at kickoff, written down.
2. Confirm they can. Ask whether anyone else needs to agree before this counts. Ask early, not at the end.
3. Present an exact version. A version number and a date, on the thing itself.
4. Ask for a stated action. "Please reply approving v3 as final" beats "let me know what you think" when what you need is a decision.
5. Record the date and how they were reached. Which address, which channel, which step.
6. Keep the sequence. Every version and every reply, in order, not just the last one.
7. Export the record. Out of the tool, into somewhere you will still have access to in three years.
8. Decide now what happens if it is contested. A window, a route, and an outcome that gets written down.
9. Do not overwrite anything. Corrections are new entries. A record you can edit is a record that argues against itself.

Step eight is the easy one to leave until it is needed, which is the worst moment to design it. An approval that can be reopened forever settles nothing; an approval that cannot be questioned at all is not credible either. A stated window that opens and then closes is fairer to both sides than either extreme.

Steps one and two are much easier if the boundary was agreed before the work started — how to set project scope with clients covers the kickoff conversation that names the approver and the acceptance step in the first place.

How Stria approaches this, and where it stops

Stria is a delivery and record-keeping tool for freelancers and small studios. It is not a law firm, not a substitute for legal advice, and not a qualified trust service provider. What it can do is make the commercial record more complete than an email thread, and be specific about what that record contains.

When a client approves a deliverable, Stria records:

• The name and email address the approver entered, after a single-use six-digit code sent to that address has been typed back. The code expires in ten minutes, works once, and is stored only as a keyed hash rather than in recoverable form. What this establishes is control of that mailbox at that moment, plus possession of the review link. It is not a check against a government document, and Stria does not describe it as one.
• The exact wording the approver agreed to, stored verbatim on the approval so the disclosure can be reproduced with the record rather than reconstructed from a template.
• A timestamp taken from the database server, not from the approver's browser. It is a server clock, not a qualified electronic timestamp from a qualified trust service provider, which some regulated processes require.
• The network address the server observed, and the browser string reported. An IP address indicates a network path, not a person; it can be shared, proxied or reassigned. It is printed on the certificate, which is emailed to the approver as well as to you.
• A SHA-256 fingerprint of the approved version, computed in the database over the deliverable's identifier, version number, title, embed link and stored asset path. That covers the version record and the pointer to an uploaded file. It does not hash the bytes of a file hosted on someone else's service.
• The version history, as append-only snapshots, each carrying its own fingerprint and a link to the previous one. Integrity is recomputed from the current contents when someone asks, so a deliverable altered after signing reports as changed even though the approval still carries its original fingerprint.

Two structural properties are worth more than any single field. Approvals are append-only: database triggers reject updates and deletions, and a signed deliverable cannot be deleted while an approval depends on it. And a dispute is a new entry, never an edit — either side can contest an approval inside a window your workspace sets, from a fixed list of grounds, and upholding it reopens the deliverable without touching the original record. A rejected objection is kept too, because "this was challenged and the challenge did not stand" is a stronger position than an approval nobody ever tested.

The record leaves the building. Every approval produces a PDF certificate, and the fingerprint on it can be checked by anyone on a public verification page with no Stria account, which returns the subject, version, workspace, signatory names and timestamps and an integrity result — and never the signer's email address or IP.

What Stria does not claim

Stated here rather than in a footer, because these are the limits that matter to the person deciding whether to rely on the record.

• It is a simple electronic signature. Under eIDAS terminology that is the standard tier, and the European Commission's own material sets out the three. It is not an advanced electronic signature, because Stria does not issue signature-creation data held solely by the signer, and it is not a qualified electronic signature, because Stria is not a qualified trust service provider. Only the qualified tier carries equivalent legal effect to a handwritten signature under eIDAS. The full element-by-element mapping, and the list of what is not claimed, is on the e-signature alignment page.
• No legal conclusion. Stria does not tell you an agreement will hold up, and no external legal review of its signing model has been obtained. That is recorded internally rather than glossed over.
• No identity proofing. Attribution rests on mailbox control. That is proportionate for deliverable and scope approval, and insufficient wherever a counterparty or a statute wants documentary identity.
• Multiple signers on documents, one on a deliverable. A contract, statement of work or change order can require several signers, in a fixed sequence or without one. A deliverable approval is a single approver by design.
• Silence is recorded as silence. If you configure a review window after which an unanswered deliverable is treated as approved, that is recorded as what it is — a policy you set, with the clause and the deadline stored alongside it — rather than dressed up as an affirmative act.
• SOC 2 readiness, not certification. No independent auditor has issued a report on Stria, and it will not be described as certified until one does. The current position and timeline are on the Trust Center, and the concrete controls are on the Security page.

How to operate any of this is documented separately, so this article does not have to double as a manual: getting a verified sign-off, checking a certificate without an account, and contesting an approval after it is signed. What data is held and for how long is in the privacy policy, and the contractual position is in the terms.

If you would rather see it than read about it, the interactive demo walks the client's side of an approval in your browser. It is a simulation and saves nothing, which is exactly why it is safe to click through.

When to get legal advice

A record-keeping article is the wrong instrument for these. Talk to a lawyer in the relevant jurisdiction when:

• The amount at stake is material to your business.
• The transaction is regulated, or the counterparty is in a regulated sector.
• The parties are in different countries, or the contract names a law you have not read.
• Intellectual property is being assigned rather than licensed.
• The matter is an employment or a consumer one, where extra disclosure duties often attach.
• The document type may sit outside the general electronic-signature regimes — the ESIGN exceptions above are a starting point, not a complete map.
• A dispute is already live. At that point the question is not how to improve your workflow.

Questions people ask

Is an email enough to prove client approval?

An email can be useful evidence. It carries a date, a named sender, words in that person's own phrasing, and it exists in two places rather than one. What it usually cannot do alone is fix which version was in front of the sender. Whether a particular email is sufficient depends on the jurisdiction, the contract and the facts.

Does "looks good" count as approval?

It records that someone was pleased with something on a day. It does not identify the deliverable or the version, and it does not distinguish accepting the work as final from encouraging you mid-draft. The fix is not suspicion, it is a closing question asked plainly.

Is clicking an approval button an electronic signature?

It can be. ESIGN and UETA both define an electronic signature functionally — a sound, symbol or process attached to or logically associated with a record and adopted with intent to sign — and eIDAS is technology-neutral too. So the click is not disqualified for being a click. What matters is whether intent is evidenced, what the click attached to, and what the record kept.

What does a content hash prove?

That content has or has not changed since the digest was taken. Nothing about identity, authority or intent. And a digest only covers the bytes that went into it, so ask which ones those are.

Can a client revoke an approval after giving it?

They can certainly try, and whether it succeeds is a contract-and-jurisdiction question. What you control is the record: a stated window, a fixed set of grounds, and an outcome written as a new entry rather than as an edit.

How long should approval records be kept?

Longer than the project. The period is driven by your contract, your tax and accounting duties, the limitation period where you are, and any sector rules — so no software company can give you a number. The practical test is whether you could still read the record after you stopped paying for the tool that made it.

Where this leaves you

The strongest thing in your favour six months from now is rarely a clever mechanism. It is that the version was named, the acceptance was worded plainly, the time came from something other than a phone, and nobody could quietly change any of it afterwards.

Stria exists to produce that artifact rather than a status field, and to be precise about its limits while doing it. The free plan carries three clients and six deliverables a month, which is enough to put one real approval through it before paying anyone: start a 14-day trial. Or work through the Approval Record Check first and see which of the nine properties your current process already has.

Sources

Primary and authoritative sources for the legal and technical statements above. All accessed 29 August 2026.

• 15 U.S.C. §7001, General rule of validity — US Government Publishing Office, 2024 edition. The Electronic Signatures in Global and National Commerce Act, and the definition of an electronic signature it shares with UETA.
• 15 U.S.C. §7003, Specific exceptions — US Government Publishing Office, 2024 edition. The excluded categories quoted above.
• Uniform Electronic Transactions Act (1999) — Uniform Law Commission. Source of the functional definition of an electronic signature adopted across the states.
• Why New York must modernize its electronic transactions law — New York City Bar Association, for the current adoption position and New York's separate statute.
• Regulation (EU) No 910/2014 (eIDAS) — EUR-Lex. Definitions of the signature tiers and the legal effect provisions in Article 25.
• Regulation (EU) 2024/1183 establishing the European Digital Identity Framework — EUR-Lex. The amending regulation, in force since 20 May 2024.
• Security guidelines on the appropriate use of qualified electronic signatures — ENISA, the EU Agency for Cybersecurity, on the equivalent legal effect reserved to the qualified tier.
• eSignature: what is the legislation — European Commission, on the three tiers and the role of qualified trust service providers.
• FIPS 180-4, Secure Hash Standard and the SHA-256 glossary entry — NIST. The purpose of a digest is to detect change.
• Federal Rules of Evidence, Rule 901 and Rule 902 — Legal Information Institute, Cornell Law School. Rule 901(b)(9) on evidence describing a process or system, and Rule 902(13) and (14) on certified electronic records.
• Amendments to the Federal Rules of Practice and Procedure: self-authenticating electronic evidence — Federal Judicial Center, on the 2017 additions to Rule 902.
• How PIPEDA applies to the creation and use of electronic documents — Office of the Privacy Commissioner of Canada, on Part 2 of PIPEDA and the amendments to the Canada Evidence Act.
• Government of Canada guidance on using electronic signatures — Treasury Board of Canada Secretariat.
• UNCITRAL Model Law on Electronic Signatures (2001) — United Nations Commission on International Trade Law, on reliability criteria and functional equivalence.

Content from these sources was summarised and paraphrased rather than reproduced.

Related reading

• The e-signature change order workflow
• 6 contract clauses that stop scope creep
• How to tell a client it's out of scope
• How to set project scope with clients
• Client won't pay? Freelance escalation
• Freelance change order template

Start your 14-day trial · Try a free scope check · All articles