What Is a Certificate of Completion in E-Signature? What It Records — and What It Proves

When a document finishes signing, most platforms hand back two things: the signed document, and a second file — or a link — that most people glance at once and never open again. That second artefact is the certificate of completion, and it is the part you will be glad you kept on the one day anyone questions the signature. This page covers what it contains, what it does and does not prove, why serious platforms deliver it as a separate file, and what to do with it.

What a certificate of completion is

A certificate of completion is the packaged evidence record of a signing transaction. The signed document shows what was agreed; the certificate shows how the agreement was executed — the sequence of events, the people, the timestamps, and the state of the file when everyone finished.

The name comes from DocuSign, which attaches a Certificate of Completion to every completed envelope, and it has become close to a generic term for the category. Other tools call the same artefact an audit certificate, a signing certificate, or an evidence summary. Signatura delivers one with every completed document. Whatever the label, the job is identical: a portable, readable summary of the audit trail, fit to hand to a lawyer, an auditor, or a counterparty who asks “prove it.”

One thing it is not: the contract. Nothing in the certificate changes what was agreed. It exists entirely to support the signature, not to restate the terms.

What it records

The contents vary by platform, but a competent certificate carries the same core record — the one we set out in are electronic signatures legally binding? as the difference between a valid signature and a provable one:

• Who signed — each signer’s name and email, and how they were authenticated (email link, access code, stronger identity checks where used).
• When, and from where — timestamps for each event, and the IP address and device context each action came from.
• What happened, in order — the transaction’s chain of events: sent, delivered, viewed, signed, completed. A signature with a visible history is far harder to dispute than a floating image of a name.
• What was signed — a cryptographic fingerprint (a hash) of the final document, so the exact file the record refers to can be identified later, and any altered copy exposed.

What it proves — and what it doesn’t

Here is the distinction that matters, and the one vendors tend to blur: a certificate records; the record is evidence; evidence is not a verdict.

What it genuinely strengthens is attribution and integrity — the two places electronic signatures actually get challenged. US law bars rejecting a signature merely for being electronic (ESIGN § 7001(a)), and eIDAS does the same in the EU, but neither guarantees any particular signature will hold up: that turns on whether you can show who signed and that the document hasn’t changed. A certificate of completion is precisely that showing, and ESIGN’s record-retention rule at § 7001(d) — a record that “accurately reflects the information set forth in the contract” and “remains accessible” — is the standard it helps you meet.

What it cannot do:

• It cannot make an invalid agreement valid. Intent, consent and the underlying contract law still do their own work — the certificate is silent on all of it.
• It cannot prove who was at the keyboard beyond the authentication actually used. A certificate that says “signed from this email, this IP, at this time” proves exactly that; if the signing link was forwarded, stronger authentication — not a longer certificate — is what would have caught it.
• It is only as good as what was captured. A certificate generated from a thin audit trail inherits the thinness. The certificate is the packaging; the trail is the substance.

Certificate, audit trail, seal, digital signature — untangling the terms

Four terms that travel together and get conflated constantly:

• The audit trail is the running record the platform keeps while the transaction happens.
• The certificate of completion is that record packaged into a durable, human-readable artefact when the transaction finishes.
• The tamper-evident seal is the cryptographic fingerprint (Signatura uses a SHA-256 hash) that binds the record to one exact version of the file.
• A digital signature is a cryptographic technique, not a legal category — and not a requirement for validity, as we unpack in electronic signature vs digital signature.

The short version: the trail is what happened, the certificate is how you show it, the seal is how you prove the file is the file — a typed name can be legally binding, and it is exactly this record that makes it provable.

Why the certificate is a separate file

There is a technical reason the certificate travels alongside the signed document rather than inside it, and it is worth understanding because it explains a design choice you will see on serious platforms.

A file cannot contain its own fingerprint. The moment you write a document’s hash into the document, you have changed the document — and the hash no longer matches. So a verifiable seal has to live outside the file it describes. Merge the certificate and the signed document into one PDF and the combined file’s fingerprint matches nothing; keep them separate and anyone can recompute the document’s hash and check it against the certificate, forever.

That is how Signatura ships every completed document: the signed file and its certificate of completion as two files, with the SHA-256 seal re-verifiable by anyone holding the document — no account, no login, and no need to trust us on the day it matters. The mechanics are on our security page.

How to prove a signed PDF has not been tampered with

The certificate hands you a fingerprint; proving the file is unchanged means recomputing that fingerprint and comparing the two. It takes about a minute and needs no special software.

1. Start from the file as it was delivered, not from a copy you have re-saved. If you are unsure which you have, download the original again — the next section explains why this is the step people get wrong.
2. Find the hash on the certificate. A competent certificate prints the document’s fingerprint as a long hexadecimal string, usually labelled SHA-256.
3. Recompute the hash of the PDF you hold. On macOS or Linux: shasum -a 256 your-document.pdf. On Windows: certutil -hashfile your-document.pdf SHA256. Both ship with the operating system, nothing needs installing, and the file never leaves your machine.
4. Compare the two strings. They match exactly or they do not. There is no partial match — changing a single character anywhere in the file changes the entire value.

If the document also carries an embedded digital signature, a PDF reader can run its own version of this check: Acrobat and most modern readers show a signature panel reporting whether the file has been modified since it was signed. That panel is reading a certificate stored inside the file, while the hash check above compares against a record held by the platform, so the two are complementary rather than alternatives — and if the panel says something puzzling, the terminology is worth five minutes.

For documents signed on Signatura, the verify page does steps 2 to 4 for you: upload the PDF and it re-hashes the file in your browser, then tells you whether the value matches our completion record. No account and no login, and it keeps working long after any subscription ends.

Does tamper evidence survive exporting a signed PDF?

Yes — but only because moving a file and re-saving a file are different things, and this is where people most often destroy their own evidence by accident.

Copying the PDF, emailing it, putting it in Drive or Dropbox, downloading it again, or filing it in a contract system all leave the bytes identical: the hash still matches and an embedded signature still validates. What breaks the match is anything that writes a new PDF:

• Print to PDF or “Export as PDF”, which rebuilds the file from scratch.
• Flatten, “reduce file size” or “optimise”, which rewrite the internal structure.
• Annotating, commenting or adding a page in an editor, then saving.
• Some preview-then-download round trips in document management tools, which quietly re-encode what they hand back.

None of those is tampering — but the evidence cannot tell the difference, and it should not be able to. A seal that survived re-saving would be a seal that survived editing, which would make it worth nothing. So the practical rule is simply: keep the file exactly as it arrived as your archive copy, stored with its certificate, and do your reading, annotating and sharing on duplicates.

A hash that no longer matches does not void the agreement and does not by itself accuse anyone — validity comes from the statutes, not from the seal. What a mismatch costs you is the easy proof, which is exactly why the original is worth keeping.

Do you need to keep it?

Yes — both files, together, for as long as the agreement matters plus your retention window. The signed document without its certificate is an agreement with weaker evidence; the certificate without the document is evidence about a file you no longer hold. Store them as a pair, wherever your contracts live. If a dispute ever surfaces, the pair is what your lawyer will ask for — and § 7001(d)‘s “remains accessible” is the bar a court will expect you to have cleared.

Frequently asked questions

Is the certificate of completion the same as the signed contract?

No. The signed document is the agreement; the certificate is the evidence record of how it was signed — parties, timestamps, IP addresses, event sequence, and the file’s fingerprint. You keep both; only one of them is the contract.

Is a certificate of completion legally required?

No. Validity comes from the ESIGN Act, UETA and eIDAS, none of which require a certificate. What the law’s retention rule does require is an accurate, accessible record — which is exactly the job the certificate does for you when a signature is questioned.

Can someone verify a certificate years later?

If the platform sealed the document with a hash, yes: recompute the document’s fingerprint and compare it to the certificate’s. Signatura exposes this as a public verify page that works for anyone holding the file, without an account.

What if I only saved the signed PDF?

The agreement stands — losing the certificate does not void anything. You have simply given up your best evidence of who signed and when. Check the platform: most, ours included, let you re-download the certificate for a completed document.

Does exporting or re-saving a signed PDF break the tamper-evident seal?

Re-saving does; moving does not. Copying, emailing or re-downloading the file leaves the bytes untouched, so the hash still matches. Print-to-PDF, “export as PDF”, flattening, optimising and annotating all write a new file whose hash will not match the certificate — not because anyone tampered with it, but because a seal that tolerated re-saving would tolerate editing too. Keep the original delivery as your archive copy.

What should I do if the hash does not match?

Establish which copy you are holding before concluding anything, because a re-saved or re-exported file is a far more common explanation than an altered agreement. Retrieve the original download — or ask the platform to re-issue it — and check that instead. If the original itself does not match the hash on its certificate, that is the point at which to raise it with the sender and take advice.

Where Signatura stands

Every document completed on Signatura carries a full audit trail, delivered as a certificate of completion alongside the signed file — never merged into it, for the verification reason above — and sealed with a SHA-256 hash that anyone can re-verify at any time. Evidence is the half of e-signing you cannot bolt on after a dispute starts, which is why it ships on every plan, not a tier above you — see how we secure documents.

---

Sources: 15 U.S.C. § 7001 — the ESIGN Act’s validity rule at (a) and record-retention standard at (d). Regulation (EU) No 910/2014 (eIDAS) — Article 25’s non-discrimination rule for electronic signatures. Product statements about Signatura’s certificate, SHA-256 seal and public verification describe our own shipped behaviour — see security and the verify page.