Audit trails explained: what a completion certificate proves

A signed PDF on its own tells you very little: an image of a signature could have come from anywhere. What makes an electronically signed document worth having is the record of how it came to be signed, the audit trail, and the certificate that summarises it. This guide explains every item on a completion certificate, what each is evidence of, what the trail cannot prove, and how to read one when something is disputed.

What an audit trail is

An audit trail is a time-ordered log of everything that happened to a document from the moment it was created to the moment it completed: who it was sent to, when each person opened it, when they agreed to sign electronically, when they signed, whether anyone declined, when reminders went out, and when the final file was produced. Each entry carries the time, the person's email address and technical details about the connection used.

When the last signature arrives, AiresDocs prints the trail on a completion certificate appended as the last page of the PDF, so the document and the evidence travel together. The same trail is visible in the sender's dashboard while the document is in progress.

Each item on the certificate, and what it proves

Document ID

A unique identifier for the document. It links the paper you hold to the record in the system, so a dispute over "which version" can be settled by looking it up. Anyone can enter it on the verification page to confirm the record exists and see the recorded hash.

Title and page count

What the document was called when sent and how long the original was. Useful when several similar documents went to the same people.

SHA-256 of the original

The fingerprint of the PDF exactly as the sender uploaded it, before any fields were added. It proves what the signers were shown. If the sender later claims a clause was in the document, or a signer claims it was not, the original hash settles whether a given file is that document.

SHA-256 of the final file

The fingerprint of the completed PDF, fields flattened and certificate attached. Recompute it on any copy; a match means the copy is byte-for-byte identical to what the system produced at completion. This is the integrity proof.

Recipients

Every signer and CC recipient with name, email address, role and (for signers) the time they signed or declined. It shows the parties the sender intended and the addresses used for attribution.

Sent

When the invitations went out and from which account. The start of the clock for expiry and reminders.

Viewed

When a signer first opened their unique link, with their IP address and browser. It evidences that the document was available to them and from where they accessed it.

Consented

When the signer ticked the consent box, with the wording they agreed to. It is the evidence that they chose to sign electronically and understood that their details would be recorded.

Field completed / Signed

The moment each signature or initials field was completed and the method used (drawn, typed, uploaded), plus the connection details. The signing act itself.

Declined

If a signer declined, when and the reason they gave. This stops the document and is itself useful evidence of a party's position.

Reminded

Each manual or automatic reminder sent. It shows the sender's efforts to obtain a signature and explains gaps in the timeline.

Voided

If the sender cancelled the document before completion, when. A voided document never completes and has no final hash.

Access code required

Noted where the sender set a per-signer code. It shows a second factor was used for attribution.

Completed

When the last signature arrived and the final file was generated and hashed. This is the document's completion time.

The event types in order

A typical two-signer document produces this sequence. Times are recorded in UTC so documents signed across time zones have one unambiguous order.

Why "append-only" matters

A log is only evidence if it could not have been tidied up afterwards. In AiresDocs the events table accepts inserts only: a database trigger rejects every UPDATE and DELETE, and only the server-side API (never the browser app, and never the sender's account) can insert. The sender can read and export the log but cannot alter it; nor can our support staff through the application. The printed certificate is produced from that log at completion and the final file's hash then fixes the certificate too. Any later tampering with the PDF would change the hash; any claim that the log was edited runs into the database rule.

This is what eIDAS Article 26 is getting at when it asks that an advanced signature be "linked to the data signed therewith in such a way that any subsequent change in the data is detectable": the detection mechanism is the hash, and the record of the signing is kept in a store that does not allow rewriting history.

What an audit trail cannot prove

Be honest about the limits; a court will be.

• It does not prove who was physically at the keyboard. It proves that someone with access to the invited email address (and the access code, if set) opened the link and signed. Attribution is an inference from that plus the surrounding facts.
• IP addresses locate connections, not people. VPNs, mobile networks and office gateways all blur them. Treat an unexpected location as a question, not an answer.
• Timestamps are the server's clock, accurate to the second in UTC, but they say when the server received the action, not when the signer first read the document on paper, for example.
• It does not prove the signer understood the document or had capacity, or that the contract is fair. Those are matters of contract law.
• It does not substitute for a witness where a deed or will requires one.

Reading a certificate in a dispute

Suppose a signer says "I never signed that." Work through the trail:

1. Check the file. Verify the final hash of the copy in dispute. If it matches, the document is unaltered since completion. If not, find a copy that does (the completion email attachment, the sender's export).
2. Check the address. Was the invitation sent to an address the signer uses? Earlier correspondence from that address supports attribution.
3. Check the sequence. Viewed, consented, signed within a plausible window, from a consistent IP and browser. A view from a phone in the signer's city followed by a signature twenty minutes later is a coherent story; a signature with no view event would be impossible in a well-designed system and would need explanation.
4. Check the second factor. If an access code was required, how was it delivered, and to whom?
5. Check conduct. Did the signer act on the agreement afterwards: paid, moved in, started work, replied acknowledging it?

Most disputes dissolve at step 3 or 5. The trail's value is less in winning an argument than in making the argument unattractive to start.

Keeping the trail usable

• Keep the completion email and its attachment; the attachment is the sealed file.
• Export your documents and audit JSON periodically from settings, and store the export with your records. It is the same data as the certificate, in a machine-readable form.
• Do not "clean up" PDFs by re-saving them. Keep the sealed original and work on copies.
• Note the document ID in your contract register so anyone can verify the file later.

Related: how to verify a signed contract and what makes an electronic signature legally binding. The product details are on the features page.

This guide explains how electronic signature law works in general terms and links to the primary sources. It is not legal advice: rules differ by country and document type and they change. For a specific transaction, ask a qualified lawyer in the relevant jurisdiction. Spotted something out of date? Email support@airesdocs.com and we will check it against the source.