diff --git a/Distribution/docs/refactor_docs/dispatch_pipeline.md b/Distribution/docs/refactor_docs/dispatch_pipeline.md
index 7f555a5..de9d472 100644
--- a/Distribution/docs/refactor_docs/dispatch_pipeline.md
+++ b/Distribution/docs/refactor_docs/dispatch_pipeline.md
@@ -160,9 +160,11 @@ enters any edits the agent made into the system and submits.
    Confirmed PO that already has a linked Invoice: should the Invoice be voided automatically?
    If the PO's items were already pulled into a loading sheet: what happens to those loading sheet
    items? Cascade rules needed before implementation.
-4. **Exact adjustment payload for `POST /api/invoices/{id}/finalize`** — the fields the office
-   worker can edit (returns, damage, discounts) are assumed but not fully specified. "Free issues"
-   handling (items given to the shop at no charge) is a known case needing its own payload field(s).
+4. ~~**Exact adjustment payload for `POST /api/invoices/{id}/finalize`**~~ — **Resolved**, see
+   [order_invoice_lifecycle.md Open Question 6](./order_invoice_lifecycle.md#open-questions):
+   `items[]` (`deliveredQuantity` + `freeQuantity` per line), `returns[]` (reusing the
+   `SaleReturn`/`CreditNote` shape from `18_returns_claims.md`, `Damaged` as a `ReasonCode` rather
+   than a separate field), and a single invoice-level `discount`.
 5. **Stage 3 and Stage 4 ordering** — Invoice printing (Stage 3) and loading sheet population
    (Stage 4) are independent flows. They are not strictly sequential — both depend on a Confirmed
    PO existing but neither requires the other to complete first.