What Happens When You Convert an Estimate to an Invoice

Clicking "convert to invoice" on an approved estimate feels like it should relabel that same document. It doesn't. What actually happens is closer to cloning: a new invoice is created from scratch, and the original estimate is kept around, marked as converted, rather than transformed into the thing it produced. That distinction explains why both documents remain independently visible afterward, and why the two stay permanently cross-referenced.

The Estimate Doesn't Become the Invoice — It Produces One

When you convert an estimate, the system first confirms the source document is actually an estimate and not already an invoice — a document already of type "invoice" can't be converted again. It then builds a new document from a copy of the estimate's data: same line items, same client, same totals, but with a freshly generated ID (a millisecond timestamp, guaranteeing it's distinct from every existing document), its type changed from "estimate" to "invoice," its status set to "draft" regardless of what the estimate's status was, and two new fields recording where it came from — sourceEstimateId, pointing back at the estimate, and convertedAt, a timestamp of the conversion itself. That new invoice is inserted as an entirely separate row set, unconnected in storage to the estimate's own rows beyond the ID references each carries.

The Original Estimate Doesn't Disappear

Meanwhile, the estimate itself isn't deleted or hidden. Its status is updated to "converted" — a status distinct from draft, sent, approved, or rejected — and its stored data gets two new fields of its own: convertedInvoiceId, pointing forward at the new invoice's ID, and the same convertedAt timestamp. The result is a bidirectional link: open the estimate and you can see which invoice it turned into; open the invoice and you can see which estimate it came from. Neither document is a dead end pointing at nothing.

Why a New ID Instead of Reusing the Estimate's

Reusing the estimate's own ID and just relabeling its type in place would have been the simpler implementation, but it would collapse two things that are genuinely useful to keep separate: the estimate as it was actually sent to and approved by the client, and the invoice as it's actually billed and paid. Keeping them as distinct records means an estimate's approval history, comments, and view tracking stay attached to the estimate specifically, while the invoice starts its own independent audit trail, its own view tracking, and its own payment history from the moment it's created — none of it commingled with the estimate's, and none of it lost if you ever need to look back at exactly what the client originally approved versus what they were eventually billed.

The Audit Trail Records Both Sides

Conversion writes two separate audit-trail entries in the same transaction: a "converted" event on the estimate's own trail, noting which invoice it produced, and a "created" event on the new invoice's trail, noting which estimate it came from and tagging the source as an estimate conversion rather than a document created from scratch. Anyone reviewing either document's history later sees an accurate account of how it came to exist, rather than an invoice whose audit trail simply starts mid-story with no explanation of its origin.

You Can Set a Different Invoice Number at Conversion Time

Conversion accepts an optional invoice number in the same request; if you provide one, it's used for the new invoice instead of whatever number, if any, the estimate happened to carry. This matters because estimates and invoices commonly live in separate numbering sequences — an estimate might be labeled EST-014 while your invoices run their own INV- sequence — and conversion is the point where a document crosses from one sequence into the other, so it's the natural moment to assign it its real invoice number rather than carrying over an estimate number that was never meant to appear on a bill.

What This Means for How You Work With Estimates

Practically, this means converting an estimate is safe to do without worrying about losing the original — it stays fully intact and accessible, just relabeled as converted rather than pending. It also means editing the resulting invoice afterward — adjusting a line item, say — has no effect on the estimate's own stored data, since the two are entirely separate records after the moment of conversion. If a client wants changes after you've already converted, you're editing the invoice going forward; the estimate remains a fixed historical record of what was originally proposed and approved.