Proposals & Invoices ยท Article 5.5
B2C cooling-off: when the CRD Art. 16(a) waiver appears
When you increase scope on a contract with a consumer (B2C) client, EU consumer law gives that client a fresh 14-day right to withdraw from the added portion. Clozo presents a mandatory waiver checkbox so the client knows the right exists and explicitly waives it.
EU consumer law gives consumers (B2C clients) a default 14-day cooling-off period on services contracted at a distance. The clock runs from the day the contract is concluded โ and a signed amendment that adds new scope arguably starts a new clock for that added scope. To proceed without that 14-day delay (most freelancers and clients want to start immediately), the client must expressly request immediate execution AND acknowledge they're forfeiting the withdrawal right that comes with it. CRD Art. 16(a) codifies this two-part waiver. Clozo enforces it as two checkboxes the B2C client must tick before the Sign button enables.
Step by step
Wizard auto-detects.
When you build a ฮ+ amendment in Step 1, the backend computes
requires_b2c_waiver = (client.is_b2c AND amendment.is_increase)โ visible in the wizard's deposit-context banner on Step 3 as a small warning.Client sees the waiver block.
On the public amendment page, two checkboxes render immediately above the Sign button: - "I expressly request that the freelancer begin performance of the added scope before the 14-day withdrawal period expires." - "I acknowledge that, by requesting immediate performance, I will lose my right of withdrawal once the added scope is fully performed."
Sign button stays disabled until both are ticked.
The frontend (
AmendmentSignClient.tsx) gates the button onwaiverRequest && waiverWithdrawforrequires_b2c_waiveramendments. The backend (PublicAmendmentSignView) re-validates server-side: if the body lacksb2c_waiver_acknowledged: truefor an amendment withrequires_b2c_waiver, the request returns 400 withdetails: {"requires_b2c_waiver": true}.On signing, the waiver is captured.
b2c_waiver_acknowledgedandb2c_waiver_acknowledged_atare stored on theProposalAmendmentrow alongside the rest of the eIDAS evidence. The signed addendum PDF (rendered server-side, immutable in R2) prints the waiver text and the acknowledgement timestamp inline above the signature block โ so the legal artefact carries the waiver self-evidently.
When drafting a ฮ+ amendment on a B2C client, the wizard's Step 3 preview shows the waiver block as it will appear to the client. After signing, the signed addendum PDF in your Documents dropdown carries the waiver text + timestamp + signer name as part of the legal record.
Why this works this way
The legal mechanics: under Directive 2011/83/EU Art. 9, a consumer has 14 days from contract conclusion to withdraw from a distance services contract without giving any reason. Art. 16(a) says the right is lost "after the service has been fully performed if the performance has begun with the consumer's prior express consent, and with the acknowledgement that he will lose his right of withdrawal once the contract has been fully performed by the trader." The two-part requirement (express consent + acknowledgement) is what Clozo's two checkboxes implement.
National implementations carry the same structure: BGB ยง356(4) (Germany), Code de la consommation Art. L221-25 (France), Wet OB / Burgerlijk Wetboek Boek 6 ยง230o (Netherlands), Art. 102 LGDCU (Spain), Ustawa o prawach konsumenta Art. 36 (Poland), Codice del Consumo Art. 59 (Italy), KSchG ยง18 (Austria). Failing to capture the waiver doesn't void the contract, but it leaves the consumer's withdrawal right intact for 14 days after full performance โ meaning the client could theoretically withdraw and demand a refund of the added scope's cost weeks after you delivered. The waiver locks that door at the moment of signing.
Why only ฮ+ B2C? The other branches don't add new scope. ฮโ and ฮ_REFUND reduce scope โ the consumer's protection is already satisfied (they're getting their money back, not committing to more). ฮ=0 keeps the scope identical at the financial level; even though descriptions might change, no new performance is being requested. And B2B contracts have no consumer-protection cooling-off at all (B2B is presumed to be between informed parties under Art. 2(1) of the Directive).
Troubleshooting
Keep reading
Proposals & Invoices
The 4 delta branches: ฮ+, ฮโ, ฮ=0, ฮ_REFUND
Every signed amendment falls into one of four branches based on (a) the sign of the cost change and (b) whether the proposal was already paid. Each branch fires a different document chain. This is the central conceptual map for the entire amendment system.
Proposals & Invoices
What your client sees when an amendment lands
The client receives an email with a fresh PIN, lands on a PIN-gated page, sees a side-by-side diff of old vs new with totals and a reason, and signs (or declines) โ exactly like the original proposal flow but with the diff baked in.
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.