Proposals & Invoices ยท Article 5.5
The e-signature flow โ what happens when your client clicks Sign
A single click writes a SignatureAudit row (typed name, PIN-gated email-possession check, IP, User-Agent, consent record), generates the Service Agreement PDF, fires confirmation emails, and queues the deposit invoice. The result is an eIDAS Simple Electronic Signature (SES) under Art. 3(10), backed by a 10-year audit trail.
The signing event is the moment your proposal stops being an offer and becomes a binding contract. Behind the single Sign button is a sequence of audit captures that, taken together, produce a Simple Electronic Signature (SES) under eIDAS Art. 3(10). It is not an Advanced Electronic Signature (AES) โ Clozo's signing path does not cryptographically bind the signature to document content the way Art. 26(d) requires, and there is no pdf_hash field in the SignatureAudit row. What makes a Clozo signature defensible is the audit trail, not the signature classification: Art. 25(1) gives the SES its non-discrimination floor, and the rich audit row (typed name, PIN-gated email possession, IP, User-Agent, full request headers, consent record, retained 10 years) is what carries the evidentiary weight in any specific dispute under national civil law.
Step by step
Client opens the email and clicks
Review and sign.They land on the public proposal page at
app.useclozo.com/p/{slug}, gated by the 4-digit PIN.They enter the PIN.
5 wrong attempts within a sliding 1-hour window lock the proposal slug for 24 hours (per-slug lockout); a separate 10 requests/minute per-IP rate limit also applies. Successful entry resets the counter.
They review the line items and totals.
The Sign button is at the bottom of the page; a Decline button sits beside it.
They click Sign.
A modal asks for their typed full name and a consent checkbox: "I confirm I am authorised to sign this contract on behalf of [client name] / for myself."
Server writes the SignatureAudit row (under 200ms).
Identity asserted, PIN-gated possession verified upstream, IP/UA/raw_event logged, consent recorded, signed PDF rendered with timestamp embedded.
Status flips, documents appear, emails fire.
Proposal status โ
Signed; AGR-2026-NNNN appears in your Documents dropdown; both parties get a confirmation email; deposit invoice (DEP-) generates within ~5 seconds.
green Signed badge replaces the indigo Viewed. Timeline gains a "Signed at HH:MM UTC by [client name]" event, expandable to show IP, User-Agent, country, and the SignatureAudit row reference. Documents dropdown gains AGR- and DEP-. A confirmation email lands in your inbox with the AGR attached. Action buttons change: Withdraw is gone (signed contracts cannot be unwound โ only Amendments can change scope); Mark deposit as paid manually, Resend deposit invoice, and Issue final invoice (greyed until deposit lands) appear.
Why this works this way
eIDAS levels at a glance (from EU Regulation 910/2014):
| Level | Article | What it requires | Where Clozo fits |
|---|---|---|---|
| Simple Electronic Signature (SES) | Art. 3(10) | "Data in electronic form which is attached to or logically associated with other electronic data and which is used by the signatory to sign" โ typed name, click-to-sign, ticked checkbox | What Clozo issues, backed by the audit trail described below |
| Advanced Electronic Signature (AES) | Art. 3(11), Art. 26 | Four cumulative conditions: uniquely linked, capable of identifying the signatory, under sole control with high confidence, and tamper-evident (Art. 26(d) requires a cryptographic seal binding signature to document) | Above Clozo's level โ would require the [D-111] Phase 4 RFC 3161 trusted timestamping work |
| Qualified Electronic Signature (QES) | Art. 3(12), Art. 28 | AES + qualified certificate from a Trust Service Provider on the EU Trust List + qualified signature creation device (hardware token) | Requires Bundesdruckerei (DE), FNMT (ES), Certinomis or Universign (FR), ARSS (IT), etc. โ not what Clozo issues |
Under Art. 25(1), a Clozo SES "shall not be denied legal effect and admissibility as evidence in legal proceedings solely on the grounds that it is in electronic form or that it does not meet the requirements for qualified electronic signatures." The strict equivalence under Art. 25(2) ("shall have the equivalent legal effect of a handwritten signature") applies only to QES, not to SES or AES alone. For everyday freelance commercial work โ software development, design, consulting, photography, copywriting, training, translation โ courts in DE / FR / ES / NL / PL / IT routinely accept SES + audit trail as sufficient evidence of consensus under national contract law. The narrow carve-outs (notarised real-estate transfers, certain regulated financial-services products, court submissions in some Member States, public-sector contracts under Art. 27 where the receiving body explicitly demands AES or QES) require the formal channels.
The four-part SignatureAudit row, captured in an atomic database transaction at the moment of signing (apps/proposals/models.py::SignatureAudit):
1. Identity assertion: the typed signer name and the email address that received the proposal must match the client record on file (signer_name, signer_email). Mismatch blocks the sign.
2. Possession proof: the 4-digit access code (PIN) was correctly entered before the signing surface unlocked, demonstrating access to the email inbox where it was delivered. Per the running code (HIGH-BE-002 hardening, audit 2026-04-28): the public proposal endpoint applies a per-slug lockout โ 5 incorrect PIN attempts within a sliding 1-hour window lock the proposal slug for 24 hours โ alongside a separate 10 requests/minute per-IP rate limit on the same endpoint. Successful PIN entry resets the failure counter. The amendment-PIN gate uses the same 5-fails-โ-24h-block pattern on its own slug key.
3. Technical context: ip_address (GenericIPAddressField), user_agent string, full request headers in raw_event (JSONB), and the signed_at timestamp โ all written in one transaction.
4. Consent record: the consent field captures the affirmative confirmation that the signer is authorised to bind the named party ("I confirm I am authorised to sign this contract on behalf of [client name] / for myself.").
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." Note what is not in the SignatureAudit fields: there is no pdf_hash, no hashlib.sha256 call in the signing code path, no qualified-trust-service-provider integration, no smart-card or hardware-token flow. These are the elements that would distinguish AES (Art. 26(d) tamper-evidence) and QES (Art. 28 qualified certificate). Storage-level integrity is provided separately: the rendered Service Agreement PDF is written to Cloudflare R2 (EU region) with the legal_hold flag, which prevents overwriting or deletion within the retention window โ necessary but distinct from a cryptographic signature-to-document binding.
What's QES and when do you need it? QES requires a qualified certificate from a Trust Service Provider on the EU Trust List โ practically, you obtain a USB token or smart card from your national TSP, install their middleware, and the signing happens through that hardware. It's ~โฌ50โ200/year per signatory and slow to set up. Use cases: real-estate notarised acts (BGB ยง311b in DE alongside the notarial deed; comparable rules in other Member States), corporate-formation documents in DE/AT/FR, certain regulated financial products, court submissions in IT/ES/PT, and Art. 27 public-sector procurement where the receiving body demands AES or QES. Clozo does not issue QES. If you genuinely need QES, the recommended pattern is to use Clozo as the commercial scoping layer (line items, deposit, payment terms, audit trail of negotiation) and have the formal act executed via your national TSP using their qualified signature device.
10-year retention: the signed agreement, the SignatureAudit row, and the original PDF render are stored on Cloudflare R2 with the legal_hold flag. Even you cannot delete them within the retention window. This is required 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 states. Right-to-erasure requests under GDPR Art. 17 are honoured within the bounds of Art. 17(3)(b), which preserves retention required for compliance with a legal obligation.
Troubleshooting
Keep reading
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.
Lifecycle
Status: Signed โ legally binding, audit trail captured
The client clicked Sign. Clozo collects an eIDAS-compliant evidence stack, generates the signed Service Agreement PDF, fires confirmation emails to both parties, and queues the deposit invoice. The proposal is now a contract.
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.