Proposals & Invoices · Article 5.3
The final invoice (INV-) — Schlussrechnung, facture de solde
The final invoice closes the project. It states the full work value, then explicitly references the deposit invoice and **deducts both the deposit amount and the deposit VAT**, so you don't pay tax twice. This deduction is mandated by §14 UStG and parallel rules across the EU.
The Schlussrechnung is the document that makes EU VAT timing work for staged payments. Your project's full value is taxable; you've already invoiced the deposit (and owed VAT on it then); now the final invoice has to settle the rest without re-charging VAT on the deposit portion. The mechanics are unforgiving — get them wrong and the §14c UStG "double-VAT trap" applies, where you legally owe both the original deposit VAT and the (incorrectly) re-charged deposit VAT on the final invoice.
Step by step
Confirm deposit is paid.
Final invoice can't fire until
Deposit paidstatus. Check the dashboard badge.Click
Issue final invoice.From the proposal detail page Actions menu. A confirmation modal asks for the project completion date (defaults to today).
Email goes out automatically.
Within ~2 seconds, the client gets an email with the INV-2026-NNNN attached and (if Stripe enabled) a "Pay final balance €X" button.
Verify the deduction.
Open the INV from the Documents dropdown and confirm the deposit-deduction lines (net, VAT, gross) appear — they should, but if you've manually edited templates, sanity-check.
Wait for final payment.
Stripe webhook lands automatically; for SEPA, mark manually when you see the inbound transfer.
status flips from In work to Awaiting final payment. Documents dropdown gains the INV-. Timeline records "Final invoice issued at HH:MM UTC". Action buttons change: Issue final invoice is gone; Mark final payment as received appears.
Why this works this way
The §14 UStG deduction mechanic (Germany; mirror rules elsewhere). The final invoice has this structure:
``` Project total (net) €1,600.00 + VAT 19% €304.00 = Project total (gross) €1,904.00
Less: Deposit invoice DEP-2026-0042 Deposit (net) −€400.00 Deposit VAT 19% −€76.00 Deposit (gross) −€476.00
Balance due (gross) €1,428.00 ```
What this means for the client's accounting:
- The project total VAT (€304) was the chargeable amount. - €76 was already invoiced + paid on the deposit (DEP). - €228 remains to be invoiced + paid on the balance. - The client's input-VAT register (Vorsteuerabzug) shows: €76 from DEP + €228 from INV = €304 total, exactly matching the supply.
Why every line of the deduction has to be there. A common shortcut — listing only "Less: Deposit (gross) €476" without breaking out net and VAT — fails Art. 226 inspection in Germany and Austria. The tax authority needs to see the VAT line so the client's input deduction is traceable. Clozo's render_final_invoice_pdf (apps/pdf/service.py:182) emits all three lines (net, VAT, gross) explicitly.
Cross-jurisdiction parity:
- Germany: §14 UStG Abs. 5 — the Schlussrechnung must reference each Anzahlungsrechnung and deduct net + VAT. - Netherlands: BTW Art. 35a Wet OB — the eindfactuur must show the previously invoiced amounts and the related VAT. - France: CGI Art. 271-II + BOI-TVA-DECLA-30-20-10 — the facture de solde must cite each facture d'acompte; the input VAT was already deducted by the client at the moment of the acompte payment, so the facture de solde subtracts it. - Italy: DPR 633/1972 Art. 21 — the fattura di saldo must reference each fattura di acconto.
The §14c UStG double-VAT trap. If you accidentally show VAT on the deposit portion in the final invoice without deducting it as "previously invoiced", German tax law treats the new VAT line as a separate chargeable amount. You'd owe both:
1. The original €76 on the DEP (already due). 2. An additional €76 implied by the wrongly stated VAT on the final invoice.
The client cannot deduct the second amount as input VAT because the supply was the same. Net result: you pay €76 of VAT you don't actually owe; the client is annoyed; correcting it requires a Berichtigungsrechnung (correction). Clozo's renderer always emits the deduction lines correctly, so this trap is closed by default — but if you ever manually edit a final invoice (which you shouldn't), watch for it.
When the final invoice fires. Two paths:
1. Manual: click Issue final invoice from the proposal Actions menu after Deposit paid. Use this when you want to mark the project complete on a specific date.
2. Auto-pre-render (background): a Celery task (prepare_final_invoice.delay()) renders the final-invoice PDF in advance the moment deposit is paid, so the email when you click Issue goes out instantly. See article 2.6 (proposal-status-deposit-paid) for the async flow.
100% prepayment proposals don't have a final invoice. If you picked 100% deposit on the proposal, the DEP is the only invoice — there's no remaining balance to settle. The proposal closes on Mark as completed.
Troubleshooting
Keep reading
Proposals & Invoices
The deposit invoice (DEP-) — Anzahlungsrechnung, facture d'acompte
The deposit invoice is the legal artefact that records VAT liability on an advance payment. Under EU VAT Directive Art. 65, the deposit becomes chargeable the moment the client pays — the deposit invoice is what the law requires you issue.
Lifecycle
Status: Awaiting final payment, then Paid
You've issued the final invoice. The client now owes the remaining balance (full amount minus the deposit they already paid). When the money lands, status flips to `Paid` and the final receipt is generated.
Refunds & Notifications
EU invoice compliance — Art. 226 mandatory fields, sequence numbering, retention
Every invoice Clozo issues complies with EU VAT Directive Art. 226: 14 mandatory fields, sequential numbering with no gaps, immutability after issue, and 10-year retention.
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.
Proposals & Invoices
Invoice numbering — sequential per year per type, atomic, no gaps
Every invoice gets a sequential number from an atomic counter scoped per freelancer per year per document type. No gaps allowed under EU VAT Directive Art. 226(2); enforced by a row-level database lock so concurrent operations cannot collide.