Signing & E-Signature Audit

ClientCove's E-Signature system is built in: signers verify their identity with a one-time code, complete their fields and draw their signature in the browser, and ClientCove rebuilds the signed PDF on the server, seals it, and stores it privately with a complete audit trail. No external e-sign account needed.

The Signing Flow

A recipient's path from email to signed contract:

1. Receive the notification email with a "View Contract" link
2. Click the link — clients and invitees are signed in by the one-time link and land on the contract
3. Status flips from Pending → Viewed and the first view is recorded
4. Review the PDF in the embedded viewer
5. Click Sign Contract
6. Code request — choose Email or SMS (if both are enabled) and receive a one-time code at the email or phone on file for their account
7. Enter the code on screen — verification is logged with timestamp + IP
8. Complete the fields — draw the signature and initials, type the name, answer any text fields, tick any checkboxes. Required fields must all be done before continuing
9. Confirm — ClientCove rebuilds the signed PDF on the server from your original PDF and seals the signing
10. Status flips to Signed, the signing date is recorded, and the sender is notified by email, in the portal, and in Slack if connected
11. Signer sees a confirmation with a download link to the signed PDF

The whole flow takes 60–90 seconds for most signers.

One-Time Code Verification

A one-time code confirms the signer is the person the contract was sent to — not someone who happened to get the email forwarded.

The code is required by default on every contract. It is checked again when the signature is submitted, so a signing can't skip it.

How it works

1. Signer clicks Sign Contract
2. ClientCove generates a one-time code (6 digits by default) with a short expiry (5 minutes by default)
3. The code is sent to the signer's own email address or phone number on file — never to an address typed in on the signing page
4. Signer enters the code on the contract page
5. ClientCove checks it — a match that hasn't expired lets them sign, and each code can be used only once
6. The verification is logged in the audit trail with timestamp, IP, and browser

Limits

• Requests are rate-limited — a signer can request a new code once a minute, and up to five times an hour per contract
• Wrong codes lock verification — after five wrong codes, verification is locked for one hour for that signer and contract
• Every code request and every failed attempt is recorded in the audit trail

What if the code expires?

The signer can request a new code from the code entry screen (subject to the limits above). The new code replaces the old one.

What if the code never arrives?

Check that the signer's account has the right email address (or phone number, for SMS) — codes only go to the contact details on file. If the signer has no email or phone on file for the chosen method, they're told so instead of being sent nothing. Also confirm your email and SMS delivery are working in Settings → Email and Settings → SMS before going live.

Code Delivery: Email vs SMS

The delivery method is set per contract:

When Both is enabled, the signing page shows a method picker:

• Email — code sent to the email address on the signer's account
• SMS — code sent to the phone number on the signer's account

For SMS, the signer needs a phone number on their portal profile.

Completing the Fields

After verification, the signer completes each field placed for them:

The signature pad

• A blank canvas sized to roughly match a real signature
• Clear button — wipe the canvas if you make a mistake
• Cancel — leave the signing flow without saving

The same signature is reused across every signature field for this signer in this contract — they only draw it once, no matter how many places need it.

Required fields

Signature, initial, and name fields are always required. Text and checkbox fields are required unless the contract's author marked them optional. The signing page counts required fields as they're completed and won't continue until all are done, and ClientCove refuses any signing that's missing a required field.

Multi-Signer Contracts

When a contract has multiple signers, each signer signs independently in their own session.

Per-signer state

The contract page shows different content based on who's viewing:

For template sends, each recipient has their own copy — so signing one recipient's copy doesn't affect another's.

A template itself is never marked Signed — it stays open so you can keep sending it. When staff open a sent template, its status reads Template with how many people have signed, are still awaiting, or declined, the same counts as on the Templates tab. Each signer still sees their own status.

Order of signing

Multi-signer contracts don't enforce a signing order — any signer can sign first, second, or last. The contract status only flips to Signed when all signers complete.

If you need ordered signing (signer 2 only sees the contract after signer 1 finishes), use separate contracts: send contract A to signer 1, and configure a content access grant on signing that unlocks contract B for signer 2.

Declining a Contract

A signer who doesn't want to sign can decline:

1. On the contract page, click Decline
2. Enter a reason. It's required, and the sender sees it
3. Submit
4. The decline is logged: who, when, reason
5. The sender is notified by email, in the portal, and in Slack if connected

What happens next depends on how the contract was sent:

• A template sent to several people: only that signer's copy is closed. They see Declined on the contract and in their list, and can't sign it later. Everyone else it was sent to can still sign, and the template stays open, so you can keep sending it. Staff see the signer marked Declined in the template's recipients, with their reason.
• A one-to-one contract: the contract's status changes to Void and nobody can sign it. The contract page shows the reason. To try again, Duplicate it and send the copy.

The Signed PDF

ClientCove builds the signed PDF on the server after each signer completes:

1. Start from your original PDF — not a copy from the signer's browser
2. Place each completed field — signature, initials, name, date, text answers, checkbox ticks and variable values — exactly where you positioned it
3. Print the signer's verification line under every signature (see below)
4. Flatten everything into a single signed PDF
5. Seal the signing (see Sealing & Integrity)
6. Store the signed PDF privately (see Private Signed PDFs)

The verification line

Under every signature, the signed PDF prints who signed and how they proved it:

Verified by jo@acme.com, Jo Smith on October 14, 2026 11:38 am
Acting as an agent of Acme Co

• "Verified by" means the signer entered the one-time code sent to their email (or phone — then the phone number is shown, with their email in brackets). The code is required by default on every contract, so this is what you'll normally see.
• "Signed by" is printed instead only when no code was confirmed — for example on a contract where the code was explicitly switched off and the signer didn't verify.
• "Acting as an agent of" names the client company the signer signed for. It's left off when there is none.

Signed PDFs from before version 4.173.0 aren't changed, but their signing certificate shows the same lines, built from the audit trail.

Because the browser only reports what the signer filled in, the wording a signer sees can't be changed in their browser before they sign. The signed PDF is what recipients download — your original is preserved separately.

Browser-Signed PDFs

A small number of PDFs can't be rebuilt on the server — usually because of how the file was produced. When that happens, ClientCove keeps the signed copy exactly as the signer's browser produced it, so the signature is never lost, and flags the contract.

In the Contracts list (Manage Mode), these contracts show a Browser-signed PDF badge. To fix it for future signings:

1. Open the original PDF and re-save it — for example, Print → Save as PDF
2. Replace the contract's PDF with the re-saved file

New signings on the replaced PDF are rebuilt on the server as normal.

Private Signed PDFs

Signed PDFs (and the signature images that go into them) are private. They're never served from a public link — they download only through the portal, and only for people allowed to see the contract:

• Staff
• The signers of that contract or copy
• Company owners of the contract's client, unless the contract is private (see Managing & Permissions)

Every Download PDF button and link in the portal goes through this check.

Sealing & Integrity

Every signing is sealed. At signing time ClientCove records a fingerprint (SHA-256 hash) of the signed PDF and the signing record.

This seal:

• Is taken once, at signing time
• Is stored alongside the signature record and in the audit trail
• Lets ClientCove detect if the signed file or its record is ever changed afterwards

If you ever need to defend the contract in a dispute, the seal shows that the PDF on file is byte-for-byte identical to what was signed.

A contract is signed only by signing it — there's no shortcut that marks a contract as signed without a signature.

The Audit Trail

ClientCove records every change to a contract and every signing event, each with who did it, when, and from which IP address:

The audit trail is append-only — entries are never edited. It's visible to staff only, because it contains signers' IP addresses.

Signing Certificate

After signing, the contract page displays a Signing Certificate showing the signing record in human-readable form.

For each signer, the certificate shows:

• Signer name and email
• Date and time of signature
• The verification line — "Verified by" (or "Signed by") and the company they acted for, as printed on the PDF
• IP address
• A signing ID unique to this signing
• What the signer entered — their text answers and ticked acknowledgments
• A list of audit events with timestamps

The certificate is included with the signed PDF when the recipient downloads — they get both the signed document and the proof of signing.

For template sends, each copy has its own certificate showing only that recipient's events.