Invoices are never deleted

A user asks to delete an invoice. The correct answer is that you can’t, and understanding why teaches you most of what’s different about accounting software.

An invoice is not a row

An invoice isn’t a row in your application. It’s a document with a sequential number, issued to someone, usually reported to a tax authority. Deleting it breaks the sequence, removes evidence of something that genuinely happened, and leaves the counterpart holding a document your system denies exists.

The domain already has the answer, and it’s older than software: you don’t erase an entry, you post a reversing one. The invoice is voided, or a credit note is issued against it. Both are new records referencing the original. The history reads: this happened, and then this undid it.

The distinction propagates through the whole model

• Cancelling is a state and a date, not an absence.
• A credit note is its own document, with its own number and its own line items — it isn’t a negative invoice.
• Reversing a payment writes a reversal movement; the original stays.
• Even for internal records, deletion destroys the answer to “what did the system say last Tuesday?”.

The programmer’s instinct is the domain’s opposite

The programming instinct is that removing a row is the clean way to undo. In a business system it’s the opposite: the row is a fact, and facts don’t stop having happened.

Once you internalise it, a lot of design gets simpler. Almost nothing is deleted. Things get superseded, reversed or closed — and the trail is the product.

It’s one of the principles behind the money flows in our systems: receivables, cash and current accounts are ledgers, not editable tables. When an auditor (or the owner) asks what happened, the system has the complete answer.