What a quote signing flow records: the version, a file fingerprint, the address the link went to, timestamps, an event log - and what each does not prove.
Key takeaways
- An approved quote is measured by reconstructability: what exactly was shown, to whom, when, and what changed afterwards.
- The quote number is not a sufficient identifier. The version is what determines what was approved, so it belongs in the key.
- Every evidence item proves something narrow. An IP address evidences a network path, not a person's identity, and it pays to know in advance what each field does not say.
- An append-only event log is worth more than a single status field that only ever reflects the latest state.
A quote signing flow produces an evidence record: which version was displayed, which address the link was sent to, when it was opened, what was filled in, and the fingerprint of the file that was signed. An "I approve" button without those items is convenient to use and lets you reconstruct nothing three months later.
The five questions an approved quote has to answer later
Every commercial dispute returns to the same five questions, and each needs a different field in the system:
- What exactly was approved. Not "the quote", but a specific file with a line list, prices and caveats.
- Who approved it. The person who opened the link, the address it was sent to, and the name typed into the form.
- When. A timestamp on every event, not only on the moment of signature.
- Through which channel. Email, WhatsApp, or a link the recipient forwarded onwards.
- What changed afterwards. Whether a further version was created, and whether it was sent.
The fifth is the one that fails most often. A business that sends a revised quote by updating the same record loses the ability to say what was in front of the client at the moment of approval.
What a signing flow actually records, and what each item does not prove
| Evidence item | Where it comes from | What it does not prove |
|---|---|---|
| A hash fingerprint of the PDF | Computed over the file bytes at send time | Does not identify who signed, only that the file is unchanged |
| A stored final copy of the signed file | Written at completion, not editable afterwards | Says nothing about what was agreed on the phone |
| The email address or phone number it was sent to | The send record itself | Does not prove the mailbox owner opened it |
| A unique link token per recipient | Generated at send, one per signer | A forwarded link looks identical |
| Timestamps for open, view and sign | The server clock at each event | Does not prove the document was read |
| IP address and user agent string | The request that reached the server | Evidences a network path and a device, not a person |
| The drawn signature image | Browser input from the user | A drawing is not identity verification |
| The values entered in the fields | The submitted form | Does not evidence understanding of any specific clause |
The right-hand column is the point: a pile of weak items does not become strong evidence through sheer quantity. What it does give you is a consistent story - the same address, the same token, three events within one minute, and one file fingerprint holding from the start of the process to the end. A general overview of electronic signatures and the tools around them is in electronic signatures for business; this article is only about the record they leave behind.
Why does the version, not the quote number, decide what was approved?
Because the quote number identifies a negotiation and the version identifies a document. Quote Q-2026-00184 goes through three versions in eleven days:
| Version | Date | Change | Amount | What happened to it |
|---|---|---|---|---|
| v1 | 12 Apr | First offer | 46,000 | Sent, opened, not signed |
| v2 | 18 Apr | Training phase removed | 39,500 | Sent, then withdrawn by us |
| v3 | 23 Apr | Reduced training restored | 42,800 | Sent and signed |
When the client asks in September why they were charged for training, the answer has to point at v3 and at the fingerprint of the file that was signed - not at "the quote". Three implementation rules are enough to make this hold:
- A new version is a new record. Same
quote_number, incrementedversion, a separate file stored separately. - Sending a new version invalidates the previous one. The old token stops working, so two versions can never both be signed.
- A file that has been sent is never edited. Fixing a comma produces v4, even when the price does not move.
How the resulting order and invoice stay attached to the same identifier is covered in the quote-to-order-to-invoice chain under a single ID.
The event log: rows that are only ever added
The common mistake is a single status field on the quote. A status shows the latest state and erases the path to it. What is needed is an append-only event list where each row is written once:
| Time | Event | Who or what | Detail |
|---|---|---|---|
| 23 Apr 09:14 | Sent | Dana, from the system | Sent to a.cohen@example.co.il |
| 23 Apr 09:31 | Opened | Signer token | Mobile browser |
| 23 Apr 09:33 | Viewed to the end | Signer token | 4 pages |
| 24 Apr 11:02 | Opened again | Signer token | Desktop browser |
| 24 Apr 11:08 | Signed | Ori Cohen | 3 fields completed |
| 24 Apr 11:08 | Completed | The system | Signed file produced and sent to both sides |
Three properties make this a useful record: rows are never edited, every row has an identified source, and a failed event is written exactly like a successful one. A flow that discards failed attempts produces a log that looks too clean, which is precisely why it is harder to rely on.
What do you do when the price changes after the link has gone out?
- Explicitly invalidate the live token. Do not rely on the client ignoring the old email.
- Send a notice that is written into the log. What was sent, when, and to which address.
- Create a new version with an incremented number, even for a small change.
- Show the difference in the body of the message, rather than only attaching an updated file.
- Keep the withdrawn version, including its open events. It is part of the story.
The step people drop is the first. A token left alive after a new version has been sent creates the worst possible outcome: two signed versions of one quote at two prices, neither of which can be withdrawn without an argument. Where the quote is generated automatically from a call or a meeting, this step belongs inside the flow rather than bolted on afterwards - see turning a call into a quote.
What weakens the record
- One link for every recipient. You cannot say which of three people at the client opened and signed.
- A file regenerated on every view. If the PDF is rendered live from data, the fingerprint differs between views and the evidence loses its meaning.
- An unsynchronised server clock. Timestamps that disagree with the emails around them create a question instead of an answer.
- Deleting old versions. Tidying that looks orderly removes the context that explains the signature.
- Pre-filled fields the signer cannot change. It is hard to argue the signer supplied a detail the system filled in for them.
- A log that lives only in the server log file. Log files rotate and are deleted; an evidence record belongs in the database.
Sources
Frequently asked questions
Do we store the file or its fingerprint?
Both. The signed file is stored as a copy that cannot be edited, and the fingerprint is stored as a separate field on the record. The fingerprint alone lets you show that a given file is unchanged, but it does not let you produce the document if the copy is lost.
Does an IP address identify the signer?
No. It records the path the request took to reach the server, and it may belong to an office network, a mobile carrier or an intermediary service. It is useful as one item inside a consistent sequence of events, and misleading whenever it is treated as identification of a person.
How long should we keep the event log of a quote that was never signed?
That is a business decision rather than a technical one, but it is worth remembering that unsigned quotes are exactly the ones that come back as questions. If the log is deleted with the quote, you cannot later answer what was sent to the client and what they saw.
Can a WhatsApp confirmation replace a signature?
A message records a statement but does not bind it to a specific file and a specific version. If you use that channel, have the message point at a unique link, and keep the evidence chain in the system rather than on a salesperson's phone.
Keep reading
Related service
Business Automation
I build custom automations that remove repetitive work end to end.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.