Proposals & Invoices ยท Article 5.6
Multi-amendment chains: one draft at a time, baseline = current effective
A proposal can have many amendments over its life โ but only one open at any given moment, and each new amendment baselines on the most recent signed state, not the original proposal. Here's how the chain holds together.
Most proposals get zero or one amendment. A few get more โ design projects where the brief evolves, development projects where the spec drifts, retainers where each month is a new addendum. Clozo handles chains of any length by treating each new amendment as a delta against the most recent signed state, not against the immutable original. This keeps the math intuitive: when you're amending after a previous amendment signed, you're working from the current contract, not from a point in the past.
Step by step
Look at the proposal detail page.
Below the Documents dropdown, an Amendments section lists every amendment on the proposal in chronological order, with status (signed / declined / cancelled / expired), sequence number, signed-on date, and a deep link to the addendum PDF.
Open the wizard for a new amendment.
From
/proposals/{id}Actions panel,Propose scope change. The wizard inspectshas_signed_amendmentand pre-loads the latest signed scope as the baseline.Edit, send, sign as usual.
The flow is identical to a first-time amendment from the freelancer's perspective. The client sees a diff against the latest signed state, not against the original proposal.
After signing, the chain extends.
The newly signed amendment's revised scope becomes the baseline for any future amendment. The Documents dropdown gets a new addendum PDF (AMD-NNNN-vN), a new active FinalInvoice (with revision incremented), and a new Stornorechnung for the previous active invoice.
A clean Amendments section on the proposal detail page enumerating the chain. Each row is independent: own status, own documents, own audit trail. The "current effective scope" is always the latest signed amendment's revised state; the original proposal's line items are preserved in proposal.line_items (immutable per [D-086]) but only the revised state drives invoices and totals going forward.
Why this works this way
Three rules govern the chain:
1. One open at a time. A DB constraint (uniq_open_amendment_per_proposal with condition status IN (sent, viewed)) enforces this at the data layer. The wizard enforces it at the UI layer by routing you to Resume Draft if a draft already exists. If you try to draft a second amendment while another is awaiting client signature, the API returns 409 open_amendment_exists. To start a new amendment, the previous one must move to a terminal state: signed, declined, cancelled, or expired.
2. Baseline = current effective scope. When you open the wizard for a fresh amendment on a proposal that already has signed amendments, Step 1 shows the line items from the latest signed amendment as the locked "Original" column โ not the line items from the original proposal. The API surfaces this via proposal.has_signed_amendment and proposal.revised_line_items; the frontend wizard pivots to those when present.
3. Deposit anchors to the original. Even after multiple signed amendments, the deposit calculation uses the very first total (parent.total_amount), not the latest revised total. This is intentional per [D-086]: the deposit was paid against a specific number; it doesn't retroactively re-scale. The wizard's deposit-context banner reflects this โ the deposit โฌ stays constant across the chain even as the revised total moves.
Troubleshooting
Keep reading
Proposals & Invoices
Creating an amendment (the 4-step wizard)
The amendment wizard at `/proposals/{id}/amend` walks you through line items, reason, preview, and email โ in that order. Five minutes for a simple change, ten minutes for a complex one. The client doesn't see anything until you click Send on Step 4.
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
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.