Proposals & Invoices · Article 5.9
Why a signed amendment issues two new documents (Storno + new INV)
Every signed amendment that touches the financial side of the contract generates at minimum two new documents: a Stornorechnung (cancellation invoice) for the old final invoice, and a fresh active FinalInvoice with revised numbers. This is required by GoBD §147 AO and parallel EU rules — never an arbitrary Clozo choice.
EU invoicing law treats issued invoices as legal records that cannot be edited or deleted — they can only be cancelled (with a Stornorechnung) and replaced (with a fresh invoice). This is enforced under GoBD §147 AO in Germany (10-year retention with immutability), with parallel rules across the EU: BTW Art. 35a (Netherlands), CGI Art. 289 (France), Art. 6 Reglamento de Facturación (Spain), Ustawa VAT Art. 106 (Poland). When an amendment changes the financial scope, Clozo produces the right paper trail automatically — but it's worth understanding what gets created and why, because your accountant will see it.
Step by step
Sign event triggers the pipeline.
Client clicks Sign on the amendment page; backend captures the eIDAS evidence stack and runs
process_amendment_signedin the same DB transaction.Documents appear in the dropdown within ~30 seconds.
PDF generation is async via Celery, but rows are persisted immediately. Refresh the proposal page if you don't see them — Gotenberg can be slow.
Old INV row gets a "Superseded" badge.
The Documents dropdown shows the old final invoice with a "Superseded by INV-NNNN-v2" label and a link to the Stornorechnung.
New INV becomes active.
Carries a
v2suffix ondisplay_numberif it's the second iteration. The active row is what surfaces on the proposal banner ("Awaiting payment of INV-NNNN-v2: €X").Δ_REFUND branches surface refund timeline.
A new banner "Refund in progress" appears with the credit note number, expected timing, and a "Check status" button (article 8.7).
Documents dropdown reorganises to show the new active invoice prominently and the old one as superseded. The Amendments section gets a new entry. For Δ_REFUND, the proposal banner switches from "Paid" to "Refund in progress" until the cash leg settles.
Why this works this way
The post-sign pipeline (process_amendment_signed in backend/apps/proposals/amendment_postsign.py) executes inside a single DB transaction the moment the client signs:
1. Storno the previous active FinalInvoice. If a final invoice was already issued (Window B), it's flipped to status=superseded, superseded_by points to the new invoice, void_reason records "Voided by amendment {amendment_number}", and a StornoInvoice row is created with the language-specific document type (Stornorechnung in German, Annulation in French, Rectificativa in Spanish, Creditfactuur in Dutch, Korekta in Polish, generic Cancellation in English).
2. Activate the new FinalInvoice. The preview invoice the wizard created (in status=cancelled state during draft) is recomputed at the latest amendment numbers and flipped to status=active. It carries a fresh sequential number from your year counter (INV-2026-NNNN) and a revision suffix in display_number (e.g., INV-2026-0042-v2). Both numbers stay in your audit log forever.
3. Δ_REFUND only — DepositInvoiceCorrection (Berichtigung). On Δ_REFUND branches, a third document is created formally correcting the original deposit invoice (Anzahlungsrechnung). Type is partial_refund if the new total is positive but smaller than deposit_paid; full_cancellation if the new total is zero. This document is the legal mechanism under §17 UStG (Germany), Art. 90 EU VAT Directive (general), and national parallels — without it, the deposit invoice's VAT line stays in your books at the original amount and the tax office won't accept the refund.
4. Δ_REFUND only — CreditNote (Gutschrift / facture d'avoir / nota de crédito). A fourth document, the actual credit note the client receives announcing the refund. It references the original deposit invoice number (DEP-2026-NNNN) and the deposit invoice date per Art. 219 EU VAT Directive (cross-references between corrections and originals are mandatory).
5. Stripe refund kicked off. If the original deposit was paid via Stripe (Direct Charge on the freelancer's connected account), _trigger_stripe_refund is called with the credit note's gross amount. The credit note moves to refund_status=requested. Webhook confirmation flips it to succeeded (or failed); see Section 8 for the refund lifecycle in detail.
The legal artefacts are persisted before the cash leg fires. If Stripe is unreachable, the documents are still correct — only the money pauses, and you can retry from the credit note row (article 8.8).
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.
Refunds & Notifications
When refunds happen: the Δ_REFUND amendment branches
A refund in Clozo is always tied to a Δ_REFUND amendment branch — partial (revised total smaller than deposit paid) or full (revised total at zero). The amendment is the legal trigger; the refund is the cash consequence.
Refunds & Notifications
Storno vs Berichtigung vs Gutschrift: three documents, three jobs
Three German VAT documents commonly confused with each other, each with a specific legal job and a specific moment when Clozo issues it. EU equivalents have similar names and identical purposes. Mixing them up is a frequent topic in support tickets — and a frequent cause of accountant pushback.
Refunds & Notifications
The Credit Notes page
A first-class section in the freelancer dashboard that lists every credit note across all your proposals, with status, refund amount, linked proposal, and action buttons. Use this when you want to manage refunds without drilling into each proposal individually.