Refunds & Notifications · Article 6.1
Wann Erstattungen erfolgen: die Δ_REFUND-Änderungsauftrags-Zweige
Eine Erstattung in Clozo ist immer an einen Δ_REFUND-Änderungsauftragszweig gebunden — teilweise (überarbeitetes Gesamt kleiner als gezahlte Anzahlung) oder vollständig (überarbeitetes Gesamt bei null). Der Änderungsauftrag ist der rechtliche Auslöser; die Erstattung ist die finanzielle Konsequenz.
Clozo hat keine „Dem Kunden etwas Geld zurückgeben"-Schaltfläche, die vom Vertrag losgelöst ist. Jede Erstattung ist der finanzielle Teil eines unterzeichneten Änderungsauftrags, der den Gesamtbetrag unter das reduziert hat, was der Kunde bereits als Anzahlung gezahlt hat. Dieses Design ist bewusst gewählt — Erstattungen ohne eine entsprechende Vertragsänderung sind ein Alptraum für Steuerprüfungen; die Verknüpfung jeder Erstattung mit einem unterzeichneten Änderungsauftrag stellt sicher, dass die rechtlichen Dokumente (Stornorechnung, Berichtigung, Gutschrift) und die Geldbewegung immer synchron sind.
Quick visual tour
Step 1: Erstattungsanfrage kommt an. Keine Panik — es gibt einen klaren Weg.
Step 2: Berechtigung im Entscheidungsbaum prüfen. Die meisten Fälle sind gültig.
Step 3: Auf Erstatten klicken. Stripe übernimmt die eigentliche Geldbewegung.
Step 4: Münzen fliegen von Ihrem Tresor zurück zum Kunden.
Step 5: Eine Gutschrift ausstellen. Die Buchhaltung schließt sauber ab.
Step by step
Den Erstattungsbetrag festlegen.
Es handelt sich nicht um eine Zahl, die Sie eingeben — es ist die Konsequenz der Bearbeitung von Positionen in einem Änderungsauftrag. Neues Gesamt unter eingezogener Anzahlung → Erstattung. Neues Gesamt bei null → vollständige Anzahlung erstattet.
Den Änderungsauftrag-Assistenten öffnen.
/proposals/{id}/amend. Positionen in Schritt 1 reduzieren, bis das Anzahlungskontext-Banner des Assistenten „Erstattung: X €" anzeigt.Den Grund in Schritt 2 angeben.
Mindestens 30 Zeichen (das längere Minimum spiegelt wider, dass Sie kürzen — machen Sie es explizit). Der Grund erscheint auf dem Nachtrag, auf der Gutschriftsnarration und ist Teil des Prüfpfads.
Senden und auf die Kundenunterzeichnung warten.
Der Änderungsauftrag durchläuft den Standard-PIN-gesicherten Ablauf (Artikel 7.4). Bei der Unterzeichnung läuft die Erstattungspipeline.
Die Erstattungs-Timeline beobachten.
Ein „Erstattung in Bearbeitung"-Banner erscheint auf der Angebotsseite nach der Unterzeichnung. Phasen: ausgestellt → angefordert (Stripe akzeptiert) → abgerechnet (Stripe-Webhook bestätigt) — siehe Artikel 8.4.
Nachdem der Kunde den Δ_REFUND-Änderungsauftrag unterzeichnet hat, wechselt das Angebotsbanner zu „Erstattung in Bearbeitung" mit der Gutschriftsnummer und einem erwarteten Zeitfenster. Das Dokumenten-Dropdown erhält die neuen Dokumente (Storno, Berichtigung, Gutschrift). Der refund_status der Gutschrift steuert die Benutzeroberfläche: requested → „Erstattung in Bearbeitung, erwartet in 3–5 Werktagen"; failed → „Erstattung fehlgeschlagen" mit Wiederholungs-/manuellen Optionen; succeeded / manual → „Erstattung abgeschlossen am [Datum]".
Why this works this way
Der Erstattungsfluss ist in process_amendment_signed (backend/apps/proposals/amendment_postsign.py) verwurzelt. Zum Unterzeichnungszeitpunkt prüft die Funktion amendment.triggers_refund. Wenn wahr, berechnet sie refund_gross = deposit_paid − revised_total (auf null begrenzt) und:
1. Erstellt eine DepositInvoiceCorrection (Berichtigung der Anzahlungsrechnung) mit correction_type=partial_refund oder full_cancellation.
2. Erstellt eine CreditNote (Gutschrift) mit refund_status=pending, den Brutto-/Netto-/Mehrwertsteuerbeträgen aufgeteilt über _split_refund_vat, und Verweisen auf die ursprüngliche Anzahlungsrechnung (Nummer + Datum) gemäß Art. 219 EU-Mehrwertsteuerrichtlinie.
3. Ruft _trigger_stripe_refund auf, um den finanziellen Teil über die Stripe API auf dem verknüpften Konto des Freelancers zu versuchen.
Zwei verschiedene „Auslöser"-Quellen erzeugen eine Erstattung:
| Auslöser | Zweig | Erstellte Dokumente | Finanzieller Teil |
|---|---|---|---|
Änderungsauftrag mit revised_total < deposit_paid, ursprüngliche Anzahlung über Stripe bezahlt | Δ_REFUND teilweise ODER vollständig | Storno + Berichtigung + Gutschrift (+ stornierte Schlussrechnung bei vollständig) | Stripe-Erstattung (Artikel 8.2) |
Änderungsauftrag mit revised_total < deposit_paid, ursprüngliche Anzahlung über SEPA / außerhalb bezahlt | Δ_REFUND teilweise ODER vollständig | Dieselben Dokumente | Manuelle SEPA (Artikel 8.3 + 8.9) |
Es gibt keinen „Schlusszahlung erstatten"-Pfad, da die Schlusszahlung keine Anzahlung ist — sobald Bezahlt, ist der Vertrag abgerechnet. Um einen bezahlten Vertrag teilweise zu erstatten, erstellen Sie einen Änderungsauftrag, der den Umfang reduziert (Δ−), unterzeichnen ihn; das Angebot wechselt zurück zu Schlusszahlung ausstehend mit einem kleineren Saldo, und jeder übermäßig eingezogene Betrag wird über die Post-Unterzeichnungs-Pipeline als Δ_REFUND behandelt. Der Änderungsauftrag ist immer der Hauptweg.
Hinweis: Seit dem 07.05.2026 ist auch das direkte Löschen eines in_work-Angebots verboten — das Backend lehnt DELETE mit HTTP 409 in_work_requires_amendment ab. Der rote „Alles erstatten"-Callout des Änderungsauftrag-Assistenten (Schritt 1) ist der einzige UI-Pfad zur Erstattung einer bezahlten Anzahlung; ein Klick darauf setzt die Menge jeder Position auf 0, der Assistent zeigt den Δ_REFUND vollständigen Zweig an, und bei der Kundenunterzeichnung läuft die Pipeline dieses Artikels (gemäß [D-125]).
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
Stripe automatic refund (Direct Charges via Connect)
When the original deposit was paid via Stripe, the refund is automatic. Clozo issues a Refund on the freelancer's connected account, watches for the `refund.updated` webhook, and flips the credit note to `succeeded` once Stripe confirms — typically within 3–5 business days for the cash to reach the client.
Refunds & Notifications
SEPA / out-of-band refund: when automation can't help
When the original deposit was paid via SEPA bank transfer (or any non-Stripe channel), Clozo can't refund automatically — Stripe API has nothing to refund. You issue the SEPA transfer manually from your bank, then click `Mark refunded` to update the credit note and notify the client.
Refunds & Notifications
Refund stages: issued → requested → succeeded (or manual)
The credit note moves through up to four states from creation to settled. Each state corresponds to a specific point in the refund lifecycle, with predictable UI badges and email triggers.