Lifecycle · Article 2.5
Status: Signed — legally binding, audit trail captured
The client clicked Sign. Clozo records a Simple Electronic Signature (SES) under eIDAS Art. 3(10), generates the signed Service Agreement PDF, fires confirmation emails to both parties, and queues the deposit invoice. The proposal is now a contract, defended by the SignatureAudit row.
Where this fits in the lifecycle
Draft
Only you can see this. Edit anything.
Sent
Email landed in the client's inbox.
Viewed
Client opened the link — awaiting decision.
Signed
Legally binding. Audit trail captured.
Deposit paid
Money in escrow. You can start work.
In work
Project running. Final invoice ready when you're done.
Paid
Final invoice settled. Just one click left.
Completed
Closed. Archived. You did the thing.
The signing event is the legal pivot. Up to this moment, the proposal was an offer; the client could decline or ignore it without consequence. Now it's a binding agreement under EU contract law. The signature itself is a Simple Electronic Signature (SES) under eIDAS Regulation (EU) No 910/2014 Art. 3(10) — not an Advanced Electronic Signature (AES), and not a Qualified Electronic Signature (QES). What makes it enforceable is the audit trail Clozo writes alongside it, plus Art. 25(1)'s rule that a signature cannot be denied legal effect or admissibility solely because it is electronic.
Step by step
The client clicks Sign.
A modal asks them to type their full name and confirm consent ("I confirm I am authorised to sign this contract on behalf of [client name] / for myself.").
Server-side: the SignatureAudit row is written.
Within ~200ms: SignatureAudit row created (signed_at, ip_address, user_agent, signer_name, signer_email, consent, raw_event JSONB), signed Service Agreement PDF rendered with both names and the timestamp embedded.
Status flips to
Signed.Timeline gets a
Signed at HH:MM UTCevent with the audit summary.Service Agreement PDF generated.
AGR-2026-NNNN appears in the Documents dropdown (a separate document from the proposal — the proposal is the offer, the agreement is the contract).
Confirmation emails fire.
You and the client each receive an email with the signed Service Agreement attached. Subject line: "Signed: [proposal title]". The client's email also includes the deposit invoice and a "Pay now" button if Stripe is connected.
Deposit invoice generated.
DEP-2026-NNNN is created within 5 seconds and attached to the client's confirmation email.
Green Signed badge replacing indigo Viewed. Timeline event "Signed at HH:MM by [client name]" with IP and User-Agent expandable. The Documents dropdown gains two new entries: signed Service Agreement (AGR), deposit invoice (DEP). Confirmation email arrives in your inbox with the AGR attached. Action buttons change: Withdraw is gone (you can't unwind a signed contract — only an Amendment can change scope now); new buttons appear: Mark deposit as paid manually, Resend deposit invoice, Issue final invoice (greyed until deposit arrives).
Why this works this way
What we capture at the moment of signing, in one atomic database transaction: (1) Identity assertion: client's typed name and email, matching the client record on file (signer_name, signer_email in the SignatureAudit row); (2) Possession proof: 4-digit PIN entry, proving access to the email inbox where it was sent — per the running code (HIGH-BE-002 hardening, audit 2026-04-28), 5 wrong PIN attempts within a sliding 1-hour window lock the proposal slug for 24 hours, with a separate 10/min per-IP rate limit on the same endpoint; (3) Technical context: ip_address (GenericIPAddressField), user_agent string, full request headers in raw_event JSONB, signed_at timestamp; (4) Consent record: the consent field captures the affirmative confirmation that the signer is authorised to bind the named party. This is the SES + audit trail stack defined in [A-007] (DECISIONS.md): "e-Signature: eIDAS SES (Simple Electronic Signature) — click-to-sign + email confirmation. Store IP + timestamp + email chain for 10 years."
The signing path does not compute a SHA-256 hash of the rendered PDF and does not cryptographically bind the signature to document content in the way Art. 26(d) requires for an Advanced Electronic Signature. RFC 3161 trusted timestamping is on the [D-111] roadmap (Phase 4) but is not part of the v1 signing path. What we have is integrity at the storage layer: the rendered PDF is written to Cloudflare R2 (EU region) with the legal_hold flag enabled, which prevents overwriting or deletion within the retention window — necessary but distinct from a cryptographic seal. For Qualified Electronic Signatures (QES) under Art. 3(12) you'd need a hardware token from a Trust Service Provider (e.g., Bundesdruckerei in Germany, FNMT in Spain). QES is required for some specific contract types (real-estate notarised acts, certain financial-services products, court submissions in some Member States, and public-sector contracts under eIDAS Art. 27 where the receiving body explicitly demands it); for the vast majority of freelancer work — design, development, consulting, photography, copywriting — SES backed by Clozo's 10-year SignatureAudit row is sufficient and enforceable.
The ten-year retention is enforced by GoBD §147 AO (Germany), Wet OB Art. 52 (Netherlands), CGI Art. L102 B (France), Codice Civile Art. 2220 (Italy), and parallel rules in other EU countries: tax-relevant documents must be available for inspection for a decade. Clozo stores the signed PDF on Cloudflare R2 with legal_hold so it cannot be deleted even by you or by an admin until the retention window expires. Right-to-erasure requests under GDPR Art. 17 are honoured within the bounds of Art. 17(3)(b), which allows retention where required by a legal obligation.
Troubleshooting
Keep reading
Lifecycle
Status: Sent — the proposal is in your client's inbox
You've clicked `Send`. The PDF is rendered, the email is on its way, the proposal number is assigned, and the audit trail starts here. Now you wait — until the client opens it (`Viewed`) or signs (`Signed`).
Lifecycle
Status: Deposit paid — work can start
The deposit landed (Stripe webhook or manual confirmation). Clozo flips the status, queues the deposit receipt PDF, and starts a behind-the-scenes job to pre-render the final invoice. You can begin the work.
Proposals & Invoices
The three documents: Proposal, Service Agreement, and the signed PDF
A signed Clozo proposal produces three legal artefacts: the Proposal PDF (the offer), the Service Agreement (the binding contract), and a stored audit trail. Each plays a different legal role under EU contract law and eIDAS Reg. 910/2014.
Compliance
eIDAS: what makes a Clozo signature legally binding in the EU
EU Regulation 910/2014 (eIDAS) defines three signature levels and gives each a clear legal weight. Clozo issues an Advanced Electronic Signature (AES) under Art. 3(11) — equivalent to a handwritten signature for almost all freelancer contracts.
Proposals & Invoices
Creating an amendment (the 4-step wizard)
The amendment wizard at `/proposals/{id}/amend` walks you through line items, reason, preview, and email — in that order. Five minutes for a simple change, ten minutes for a complex one. The client doesn't see anything until you click Send on Step 4.