PicPeak DocumentationCRM 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:
- Read each system block they intend to send.
- Adjust the body text to match their own jurisdiction, business
structure, and risk profile, in consultation with their lawyer.
- 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:
- Print one test invoice with the QR code.
- Scan it with the e-banking app of your own bank.
- 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.
- 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.