Customers screenshot invoices. Auditors reprint them. Banks match them. If your system "updates" a sent document to include a usage line that arrived late, you have created two realities: the one in the customer's inbox and the one in yours.
Sonic's rule is dull and non-negotiable. Unpaid drafts and in-progress documents may still accept lines. Anything final, sent, void, or paid does not.
The state machine finance actually needs
| Invoice state | Accepts new product lines? | Typical correction |
|---|---|---|
| Draft / in-progress | Yes | Edit, regenerate from schedule or events |
| Final / sent | No | Credit note, or new invoice alongside |
| Paid | No | Credit note or new invoice; never rewrite |
| Void | No | New invoice if you still need to bill |
This is not pedantry. It is how you answer "what did we ask them to pay on 14 August?" without opening three tabs and a prayer.
Regeneration paths — after a subscription gate resolves, after seat events land late, after usage catches up — must still respect product-line idempotency. Sonic will not duplicate a line that already billed for the same product in the same period on an open draft. On a closed document it will not touch the line at all.
What to do when reality arrives late
Operators feel the immutability rule most often in these situations:
Late usage in the same period. Put it on the next draft for that period if one is still open. If the period's invoice is already sent, a new invoice alongside — or the next period's bill if your contract allows arrears billing.
Wrong quantity on a sent invoice. Issue a credit note for the difference, or a partial credit and a correcting invoice if your process requires both sides visible.
Upgrade mid-period after send. Schedule change produces an adjustment invoice (upgrade) or credit note (downgrade). The original sent invoice stays frozen.
Freight re-rate after send. Issued shipment invoices keep the rate that applied at issue. Draft recomputation when you save a rate index is allowed; sent documents do not silently pick up Thursday's fuel row.
The pattern: change the future document, not the customer's memory of the past one.
How this interacts with schedules and gates
Subscription schedules keep generating while invoices move through states. A payment-gated schedule may sit Upcoming with an open gate even when a displayed start date is in the past — because the subscription term has not legally started until gate products are paid.
When the gate opens, Sonic materialises phase dates and may generate catch-up invoices. Those land on new or open drafts, not on invoices you already emailed.
Seat and usage events that arrive after send follow the same split: refresh open drafts; never append to sent.
Bulk operations respect the same rule
Bulk finalize, send, and mark-paid run server-side with document-field allocation order fixed before sequences consume numbers. That is a different problem from immutability, but the same philosophy: the chain should not depend on parallel races or "hope the last write wins."
Watch out for
- "Final" but unsent is not in collections. Watchtower ages sent unpaid only. Do not confuse internal finalisation with customer delivery.
- Credit notes are the honest correction. They exist because sent invoices do not shrink.
- Draft regeneration is normal. Open drafts recomputing when events change is expected behaviour, not a bug — as long as sent documents stay frozen.
- PDF in the inbox is evidence. If your process requires a re-send, send a new document or a credit-note-backed correction; do not assume the portal overwrite reached everyone.
- Freight grouped invoices are still immutable after send. A window invoice that bundled twelve hauls does not gain a thirteenth haul line later.