diff --git a/Distribution/docs/refactor_docs/invoice_collection.md b/Distribution/docs/refactor_docs/invoice_collection.md
index 5869504..3c0d573 100644
--- a/Distribution/docs/refactor_docs/invoice_collection.md
+++ b/Distribution/docs/refactor_docs/invoice_collection.md
@@ -2,7 +2,7 @@
 
 **Status**: Proposed (design only — no code changes yet)
 **Depends On**: [order_invoice_lifecycle.md](./order_invoice_lifecycle.md) — this document only applies
-once an `Invoice` reaches `Finalized`; it does not touch Pending/Draft.
+once an `Invoice` reaches `Finalized`; it does not touch Draft/Printed.
 **Refactors**: `Models/Payment.cs`, `Models/Enums.cs` (`PaymentMethod`, `PaymentStatus`),
 `Sale.PaymentStatus`, and the payment recording flow in
 [06_sale_ride.md](../06_sale_ride.md) (`POST /api/sales/{saleId}/payments`). Also resolves
@@ -107,13 +107,13 @@ audit and for spotting collectors who never enter anything in real time.
 
 ```
 Invoice
-├── ... (existing fields from order_invoice_lifecycle.md: Status, ConfirmedAt, FinalizedAt, ...)
+├── ... (existing fields from order_invoice_lifecycle.md: Status, PrintedAt, PrintedBy, FinalizedAt, FinalizedBy, ...)
 ├── PaymentStatus (PaymentStatus)  — NEW: Pending, PartiallyPaid, Paid — mirrors the existing
 │                                     Sale.PaymentStatus pattern from 06_sale_ride.md, recomputed on
 │                                     every Payment insert (see Business Rules)
 ```
 
-This is a deliberate second axis alongside `Invoice.Status` (`Pending/Draft/Finalized`, the document
+This is a deliberate second axis alongside `Invoice.Status` (`Draft/Printed/Finalized`, the document
 lifecycle) — `PaymentStatus` only starts being meaningful once `Status = Finalized`, and answers
 `order_invoice_lifecycle.md`'s Open Question 3 (whether the two axes should merge): they stay
 separate. `PaymentStatus` is the same axis `19_finance_accounting.md` proposed baking into
@@ -130,7 +130,7 @@ has a linked Order/Invoice — see Impact section.
 
 1. A `Payment` can only be recorded against an `Invoice` whose `Status = Finalized` — matches
    `order_invoice_lifecycle.md`'s framing that Finalize is "the record used for day-end calculations."
-   Attempting to record a `Payment` against a Pending/Draft invoice is rejected (409).
+   Attempting to record a `Payment` against a Draft/Printed invoice is rejected (409).
 2. Multiple `Payment` rows are allowed per `Invoice` — collection is not required to happen in a
    single action. Each row has exactly one `Method`; a mixed cash+cheque collection on one visit is
    two rows with the same `CollectedAt`/visit context, not one split row.