Refunds & Notifications · Article 6.6
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.
Until April 2026, credit notes were only visible inside individual proposals — find the proposal, open Documents, find the credit note. That worked when you had one or two refunds in flight; it broke down once you had a dozen. The Credit Notes page surfaces refund history and pending actions in one place, ranked by status so the items needing your attention sort to the top.
Step by step
Open
/credit-notesfrom the dashboard sidebar (under Refunds / Credit Notes).
Filter by status.
A row of pills at the top: All, Pending, Requested, Failed, Succeeded, Manual. Pending and Failed sort to the top by default — those are the ones needing your action.
Inspect a row.
Each shows: CRN-NNNN, refund amount + currency, status badge, proposal number link, amendment number link, issued date, refund completion date (if applicable), action buttons.
Take action from the row.
Same buttons as the per-proposal Refund banner: Refresh status (article 8.7), Retry (article 8.8), Mark refunded (article 8.9), Download PDF.
Drill into the proposal if needed.
Click the proposal number to open
/proposals/{id}for full context (Timeline, Documents, related amendment).
Why this works this way
Backend: CreditNoteListView (amendment_views.py:849, [D-116]) returns all non-deleted credit notes for the authenticated freelancer's proposals, ordered by issued_at descending. Each row carries the proposal's number, client name, and amendment number alongside the credit note's own fields — no extra round-trips needed to render the list.
The frontend page reads from the same shape as the per-proposal get_credit_notes serializer method, so the per-row component is reused. Filters are client-side (the result set is bounded by the per-account credit-note count, which is typically tens, not thousands).
Troubleshooting
Keep reading
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.
Refunds & Notifications
Refresh status — pull-based sync when the Stripe webhook didn't land
Webhooks aren't perfect. When a credit note appears stuck in `requested` despite Stripe having processed the refund, click `Refresh status` to pull the current state from Stripe directly. Same transition logic as the webhook; no risk of double-firing side-effects.
Refunds & Notifications
Retry Stripe refund — when transient failures clear
A failed Stripe refund can usually be retried — most failures are transient (rate limits, brief Stripe outages, or deposit-paid webhook arriving after the post-sign pipeline ran). The Retry button calls `_trigger_stripe_refund` afresh on the credit note.
Refunds & Notifications
Mark refunded manually — for SEPA and out-of-band proof
When a refund is issued outside Stripe — SEPA bank transfer, cash, PayPal, mailed cheque — `Mark refunded` is how you record it in Clozo. Reason field is mandatory (typically a bank reference). The credit note moves to `manual` status and the client receives a confirmation email.