Deleting a Client Doesn't Touch Their Invoices

Deleting a saved client is a one-line database operation: the client's row is removed, and the endpoint returns success. It sounds like it should be more consequential than that, given how much can reference a client in an active workspace — invoices, payments, comments, portal links. The reason it isn't is a structural decision that runs through the whole product: a saved client record is a convenience, not a source of truth that anything else depends on.

Invoices Don't Reference Clients — They Copy Them

When you create an invoice from a saved client, the client's billing details are copied, as text, straight into the invoice's own stored data at that moment. There's no foreign key from an invoice back to the client record it came from — the invoices table has no client ID column at all. Once that copy is made, the invoice and the client record it originated from have no ongoing structural relationship; the invoice's "bill to" field is now just text that happens to have started out identical to what the client record contained at the time. This is why deleting the client afterward genuinely cannot cascade into the invoice: there's no reference for the deletion to follow, because none was ever stored.

What Actually Does Get Deleted or Detached

That said, not everything referencing a client is left alone — a few things are genuinely tied to the client record by a real foreign key, and deleting that record does affect them, in two different ways depending on how each relationship was defined. Client portal links are deleted outright along with the client: the portal-tokens table's link to a client is set to cascade on delete, so every portal link you'd generated for that client stops existing the moment the client record does — there's no client left for a portal link to represent, so the link goes with it. Document comments, expense records, and time entries associated with the client behave differently: their link to the client is set to null rather than cascading, so a comment a client left on an invoice, or an expense you'd tagged with that client, survives the deletion but loses its client attribution going forward.

Why Invoices Specifically Were Designed This Way

Storing a copy rather than a reference is what makes an invoice a reliable historical document in the first place. An invoice is legally and practically meant to represent exactly what was billed to exactly whom, as it stood at the time it was sent — not a live view that changes retroactively if the underlying client record is later edited or removed. If invoices referenced clients by ID instead of copying their details, editing a saved client's billing address would silently rewrite the "bill to" field on every invoice ever sent to them, including ones from months or years ago that a client, an accountant, or an auditor might need to match against what was actually communicated at the time. Decoupling the two avoids that entirely: editing or deleting a client only ever affects the client record and the small set of things genuinely tied to it, never the historical invoices that happened to be created from it.

What This Means If You're Cleaning Up Your Client List

In practice, this makes deleting a saved client a low-stakes cleanup action rather than something to approach cautiously. Removing a client you no longer work with doesn't touch a single invoice in your history, doesn't affect any report that totals up what that client has paid or owes (those reports match invoices to clients by comparing stored text, not by ID, so they keep working off the invoice data directly), and won't retroactively change anything a client has already seen. The one thing worth checking before deleting a client is whether you'd generated a portal link for them that's still in active use — that link stops working immediately as a direct consequence, since there's a real cascade behind it, even though every document the link used to show remains completely intact and reachable through other means afterward.