picpeak/docs/crm-disclaimers.md

CRM disclaimers — important reading for every picpeak operator

The CRM module ships defaults that touch two regulated areas: legally binding contracts and payment instruments (QR-bills, IBAN/BIC). The text and data picpeak renders are mechanically correct, but the substance is the operator's responsibility.

Important

Whatever picpeak ships in these two areas is an EXAMPLE ONLY. It is every operator's own duty to have the content reviewed by their lawyer (for contracts) and verified with their bank (for QR-bills / SEPA EPC payloads) before sending it to a customer. Picpeak does not provide legal advice and cannot validate banking data — only the operator can.

1. Contract block library

The contract feature (feat/crm, migration 130_add_contracts.js) seeds twelve "system" blocks across six sections:

• Basics — contract subject / scope-of-work header
• Scope — image-rights clauses (private + commercial variants)
• Privacy — model-release clauses (private / commercial / minors), DSGVO notice
• Commercial — payment-terms reference, tiered cancellation schedule
• NDA — mutual confidentiality
• Closing — jurisdiction (CH + DE variants)

All bodies are hand-written by the picpeak maintainer (DE first, EN translated). None of them have been reviewed by a lawyer. They are intended as starting points — every operator must:

1. Read each system block they intend to send.
2. Adjust the body text to match their own jurisdiction, business structure, and risk profile, in consultation with their lawyer.
3. Where appropriate, replace a system block entirely with admin-authored blocks under their lawyer's guidance.

The admin UI surfaces this disclaimer:

• as a persistent banner on the Block Library page,
• as a persistent banner on the Contract Editor,
• as a "system block" badge plus an "Examples only — have your lawyer review" line on every seeded block's description.

System blocks cannot be deleted (the seed migration would re-create them on re-run); operators who reject a seeded block toggle is_active=false on it so it stops appearing in new contracts. The body text of a system block is fully editable — when an operator's lawyer delivers a reviewed version, the operator pastes it into the system block and the new body is what gets snapshotted onto every subsequent contract.

2. QR-bill / SEPA EPC payment payloads

Picpeak is an open-source project. The invoice feature renders Swiss QR-bills and SEPA EPC QR codes from the data you typed (IBAN, BIC, account holder, amount, reference) — that's it. We don't have a way to tell whether the code actually scans correctly in your bank's app, so please test that yourself before sending real invoices.

Before going live:

1. Print one test invoice with the QR code.
2. Scan it with the e-banking app of your own bank.
3. If you expect customers on other banks (UBS, PostFinance, Raiffeisen, Migros Bank for Swiss QR; any major SEPA bank for EPC QR), scan with those too.
4. If it doesn't scan or the prefilled fields look wrong, fix your bank-account data in picpeak and try again.

We are not responsible for any mistakes in the rendered QR codes, payment data, or anything that flows from sending an invoice with bad data on it. That's why picpeak is MIT-licensed — use it freely, but the verification is on you.

The admin UI surfaces this same note as a banner on the Business Profile → Bank Accounts and QR-format settings pages.

3. Signature type — picpeak provides SES, not QES

The contract signing flow (typed name + acceptance checkbox + canvas signature image + IP address + timestamp + SHA-256 audit page) is a Simple Electronic Signature (SES) under the EU eIDAS regulation and the Swiss ZertES. SES is the same legal tier as DocuSign's basic plan, HelloSign's free tier, or Adobe Acrobat Sign without a qualified-certificate add-on.

What SES is legally sufficient for

In DACH (CH, DE, AT, FL), SES is valid and routinely upheld in civil court for contracts that don't legally require a specific form:

• Photography service agreements
• Image-rights / model-release clauses
• Cancellation policies
• NDAs between private parties
• Most commercial service contracts
• Most B2B agreements

For these, picpeak's evidence chain (frozen block bodies + signature images + names + IPs + timestamps + content hashes + immutable audit-log timeline) is comparable to what an SES provider charging €10–30/month delivers. The audit page appended to the signed PDF makes the evidence self-contained — the customer can re-hash their copy and prove integrity without trusting picpeak's database.

What SES is NOT sufficient for

Certain documents legally require Schriftform (handwritten signature on paper) OR a Qualified Electronic Signature (QES) backed by a certificate from an accredited Trust Service Provider (Swisscom Sign, D-Trust, A-Trust, Bundesdruckerei, etc.). The most common categories in DACH:

Jurisdiction	Document type	Statute
DE	Bürgschaft (guaranty)	§ 766 BGB
DE	Verbraucherdarlehensvertrag (consumer loan)	§ 492 BGB
DE	Befristete Arbeitsverträge (fixed-term employment)	§ 14 Abs. 4 TzBfG
DE	Kündigung Arbeitsverhältnis (employment termination)	§ 623 BGB
DE	Aufhebungsvertrag (employment cancellation agreement)	§ 623 BGB
CH	Bürgschaft above CHF 2'000	Art. 493 OR
CH	Eheverträge (matrimonial property agreements)	Art. 184 ZGB
AT	Bürgschaftserklärung (guaranty declaration)	§ 1346 ABGB

If you send any of these via picpeak's signing flow, the signature is legally invalid and the contract may be unenforceable. Use a QES provider for these documents.

If you're unsure which category your contract falls into, ask your lawyer. The cost of asking is hours; the cost of getting it wrong is years.

What picpeak does NOT provide

• Identity verification. Anyone who receives the signing email can sign. There's no second factor (SMS, video ident, ID upload).
• Qualified-certificate-based signatures (QES). Requires a separate service.
• External / third-party timestamp. All timestamps are server-side; an RFC 3161 Trust Service Provider timestamp would close the clock-manipulation defence but isn't currently part of the audit page.
• WORM / immutable storage. Signed PDFs live on the regular filesystem path under storage/business-docs/contract/<year>/. Hardening this for high-stakes contracts is an infrastructure- level decision (S3 Object Lock, etc.) outside picpeak's code.

The signing flow is fine for routine photographer-customer contracts. For anything with significant economic value or Schriftform-bound documents, layer a QES provider on top of picpeak's contract management.

Why this matters

• Liability. Sending an unreviewed contract or a malformed QR-bill is the operator's liability — not picpeak's. The MIT licence explicitly disclaims warranty.
• Jurisdictional variance. Even the most carefully drafted clause is wrong somewhere. The CH-jurisdiction closing block won't help a photographer in Bavaria. The cancellation schedule that's standard in Zurich would be challenged in Berlin.

If you are unsure: don't send. Pause, read this file again, and run your seeded contract content past your lawyer (or scan one test QR-bill yourself) before turning the feature on for live customers.