A client of ours had a supplier dispute last spring. The supplier said the agreed price was £42 per unit. Our client said £38. Both sides had the signed contract: a PDF with the supplier director's typed name on it. The price line read £38. The supplier maintained the file had been altered after signing. With no audit trail to prove otherwise, the dispute ran for four months before being settled at £40 per unit. Neither side ever proved their case. They just got tired.
This is the quiet cost of a signature without an audit trail. The document does not lose its legal status. It loses the ability to defend itself.
We saw this pattern often enough across our consulting work that we built Reeve Sign: a UK-hosted e-signature product where every envelope produces a forensic audit trail by default. This guide walks through what such a trail actually captures, why each event matters, and what to look for when comparing tools.
What an audit trail actually is
An audit trail is the structured log of every event that happened to a document from the moment it left your hands to the moment it was completed. It is the answer to the question a judge or a counterparty will ask you in any dispute: show me what happened, and prove it happened that way.
A signed PDF on its own answers none of that. The PDF can show a name. It cannot show how the name got there, when, from where, by whom, or whether the rest of the file has been touched since. Those are the questions that decide whether a contract holds up.
The seven events every audit trail must capture
If you only look for one thing in an e-signature tool, look for these seven entries in the audit log. They map directly to the four challenges a court can raise against a signature (identity, intent, integrity, authority).
1. Envelope created
Who composed the document, what file was attached (with its hash), what fields were placed where, who the recipients are, and when the envelope was sent. This entry establishes the starting state. Every later event references it.
2. Document delivered
When the signing-request email was dispatched, what address it went to, and whether the email service confirmed delivery. The delivery confirmation matters because it is the first piece of evidence that the right person had access to the document.
3. Document opened
When the signing link was first followed, the IP address it was opened from, the user-agent of the browser, and the geolocation derived from the IP. The signer is now demonstrably looking at the document.
4. Consent given
The signer's explicit agreement to sign electronically. eIDAS and UK case law treat consent to electronic signing as a separate act from the signature itself. A box must be ticked, a notice acknowledged, and that acknowledgement timestamped. Without consent, an Advanced Electronic Signature is incomplete.
5. Signature applied
The moment the signer drew, typed, or selected their signature, the exact value entered, and the field on the document it was bound to. Captured server-side with the platform's clock, not the signer's clock.
6. Envelope completed
The final state. All signatures collected, all fields filled, the document sealed, and the final document hash recorded. From this point forward the document is closed; any change would be detectable.
7. Notifications dispatched
The completion email to all parties, with the timestamp of dispatch and a link to the public verify URL. Closes the loop and provides a contemporaneous record that everyone was notified.
Each of those seven entries should carry: a UTC timestamp from the server, the IP address of the actor, the user-agent string, and a hash that chains it to the previous entry. Anything less and the log is not tamper-evident.
Website Audit Checklist
A 60-point checklist to grade your site before a redesign.
Why server-side timestamps matter
If the platform takes the time from the signer's computer, the signer can change their clock and sign documents "in the past" or "in the future". Server-side clocks, synchronised to a trusted time source, remove that attack. It is a small detail. It is also the difference between an audit trail that survives cross-examination and one that does not.
Document hashing, in plain English
A cryptographic hash is a fingerprint. You feed in a file of any size; you get back a fixed-length string of characters. Same file, same fingerprint. Change one character in the file and the fingerprint changes completely. The fingerprint is one-way: you cannot reverse it to recover the file.
Reeve Sign uses SHA-256, the same algorithm Bitcoin uses, the same algorithm UK government departments use for document integrity. A SHA-256 hash looks like this: 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08. Sixty-four characters of hexadecimal. It uniquely identifies the document it was generated from.
When the audit trail records the document hash at the moment of signing, anyone can later take the signed document, run the same hash function on it, and compare. If the hashes match, the document has not changed since signing. If they do not match, something has been altered.
Lead Follow-up Automation Playbook
Sequences that turn enquiries into bookings while you sleep.
Tamper-evident logs and the hash chain
An audit log that someone with admin access can edit after the fact is not an audit log. It is a notepad. The question to ask a vendor is not "is your audit log secure?" but "how would I detect if it had been edited?"
The right answer involves a hash chain. Each new log entry includes a hash of the previous entry. To change entry number five without detection, you would have to recompute the hash for entry five, then entry six (because it includes entry five's hash), then entry seven, and so on, all the way to the present. On a properly built platform that chain is anchored to immutable storage, so even an internal actor cannot rewrite history quietly.
Reeve Sign implements exactly this pattern. Every audit entry references the SHA-256 of the prior entry. Re-deriving the chain from any point produces the same final state as the stored one, or the chain is broken. There is no third option.
How identity gets captured
Identity verification operates as a stack, not a binary. The right level depends on the value and risk of the document.
Email link. Baseline. The signing link is sent to a verified email address. Following the link from that inbox proves access to the address. Sufficient for low-risk documents and most internal use.
SMS one-time-passcode. Layer two. A code is sent to a phone number associated with the signer; signing requires entering the code. Proves access to a second channel.
Knowledge-based authentication. The signer answers questions only they should know (often drawn from public records). Cheap and quick but a weaker proof than the alternatives.
Photo ID upload. Signer submits a photograph of their passport or driving licence, optionally with a selfie for liveness comparison. Strong, but introduces friction.
Qualified Trust Service Provider check. Live video call with an accredited officer who verifies a government-issued ID. The top tier, required for Qualified Electronic Signatures, and the most expensive in terms of cost per signature and time per signer.
The audit trail should record which identity check was used for each signer on each envelope, alongside the timestamp and outcome. That detail becomes important when a dispute hinges on identity strength.
The public verify URL
Most e-signature platforms produce a signed PDF with a completion certificate stapled to the back. To verify it, the recipient has to trust that the certificate has not been faked along with the document. That trust is unearned.
A public verification URL solves the problem. Every completed Reeve Sign envelope generates a URL on app.reevesign.com/verify/<envelope-id>. Anyone with the URL can re-derive the document hash, compare it to the stored hash, and see the completion timestamp. The page deliberately shows only what is needed to verify: envelope ID, document title, completion time, content hash. Signer names, email addresses, and IP addresses are not exposed publicly.
This is the difference between asking the counterparty to trust the document and letting them check the document. The first is a request. The second is proof.
A checklist for evaluating tools
If you are comparing platforms, here is what to look for in the audit trail specifically. The marketing pages of most vendors will not lead with these. Their docs will tell you if they are there.
- Identity capture at signing time, not just at signup
- SHA-256 (or stronger) document hash, recorded at the moment of signature
- Server-side timestamps, synchronised to a trusted time source
- IP address and user-agent recorded for every event
- Append-only, tamper-evident log (ask: how is it tamper-evident?)
- A public verification URL the counterparty can use without an account
- An exportable audit pack (PDF or ZIP) including the document, the hash, and the full event log
Any tool that ticks all seven will produce signatures with a strong evidential trail. Any tool that does not, will not.
Reeve Sign was built to tick all seven by default. Free to try, no card required.
Frequently asked questions
What is an e-signature audit trail?
Why is a typed name on a PDF not enough?
What is document hashing and why does it matter?
How does identity verification work in an e-signature?
What happens if the audit trail is lost?
How is an audit trail different from a signature certificate?
Can audit trail entries be edited after the fact?
Does the signer see the audit trail?
How long should I keep the audit trail for?
What should I look for when evaluating an e-signature platform's audit trail?
See seven events in your own audit trail
Send your first envelope on Reeve Sign and look at the log it produces: server-side timestamps, SHA-256 document hash, append-only hash chain, public verify URL. UK-hosted, no card required.
Try Reeve Sign free