Void and delete are not the same thing in your books

Somebody raised an invoice that should not exist. A duplicate, a wrong customer, a job that was cancelled before it started. The fix is obvious and takes four seconds: open the record, make it go away.

The software offers two ways to do that, sitting next to each other in the same menu. One is called void and one is called delete. They sound like the same thing said politely and rudely. They are not, and the difference outlives the four seconds by years.

What follows is about which trace each one leaves, why the safer-sounding word is the one you cannot take back, and why everything connected to your books is told about only one of them.

The words point the wrong way

Start with the two sentences that contain the whole article, both from the same page of Intuit's documentation for QuickBooks Online.

The first: "You can't undo a voided transaction."

The second: "You can use the audit log to re-enter a deleted transaction."

Read them together. The cautious-sounding option, the one that keeps a record and feels reversible, is the permanent one. The destructive-sounding option, the one that removes the entry, is the one with a recovery route.

That is exactly backwards from what the words suggest to anyone who is not an accountant, and it matters because these two buttons are usually pressed by whoever happens to be in the system, under time pressure, choosing on instinct.

The mechanics behind the words are sensible enough once stated. Voiding keeps the document and empties it: "When you void a transaction, you keep a record of the transaction in your books that don't affect your totals", and "Voided transactions are zero and show as void in your records." Deleting removes it: "You remove a transaction everywhere except the audit log when you delete it. The transaction number doesn't change."

So a void leaves a visible zero where the transaction was. A delete leaves a gap in the ledger and an entry in a log. Neither is wrong. But only one of them can be reconsidered next week.

There is a third option on the same page, offered without a warning attached, which is the most dangerous sentence Intuit publishes on this subject: "You can delete a voided transaction and create a new one to reverse it." Follow that instruction and you have converted a preserved record into a log entry, on purpose, while believing you were tidying up.

The safety net is two years deep, and most staff cannot see it

The recovery route for a deleted transaction is real, and it has two limits that are worth knowing before you rely on it.

The first is depth. Intuit's documentation on the audit log states that "Events recorded in the audit log are available for two years." That is a long time in the life of a small business and a short one in the life of a tax question. A transaction deleted in the third year of a dispute about the first year is gone in the ordinary sense of the word.

The second is access, and it is the one that bites sooner. Intuit lists what you need in order to open it: an active subscription, and "Admin access." If you cannot see the log, the instruction is to "contact your primary admin to get access". The per-transaction view is stricter still: "Only users with full access rights will be able to view the Audit history."

Put the two together and the picture is this. The person most likely to delete something by mistake - a bookkeeper, an assistant, whoever was covering the desk

• is frequently not the person who can look at the log to see what was deleted. The safety net exists for the owner, not for the person who fell.

One reassurance in the other direction, worth having: "For audit and security reasons, you can't turn off the audit log." The record of what happened is not somebody's setting.

Which button you get depends on what you are cancelling

The two options are not offered everywhere, and the list of what can be voided is narrower than most people assume.

Intuit's page states the voidable set twice, in two notes covering two halves of the business. On the sales side: "You can only void invoices, bill payments, payments, and sales orders." On the expense side: "You can only void checks, expenses, and bill payments."

Notice what is missing from both lists. A bill - the record of what you owe a supplier - does not appear. Intuit's dedicated article on removing one describes deletion only. So in QuickBooks Online you can void the payment of a supplier bill, and for the bill itself the documented route is the destructive one.

The desktop product answers differently, which is its own small lesson about treating any of this as a general rule. There, voiding a bill is a documented command, and the two outcomes are stated side by side: "Void a Bill or Payment: The transaction amount changes to zero, but QuickBooks keeps a record of the entry for your audit trail." Against: "Delete a Bill or Payment: The transaction is removed entirely from QuickBooks. This causes the original bill to return to an unpaid status."

That second line deserves a moment. Deleting a payment does not only remove the payment. It reopens the bill. One record was removed and two records changed, and the supplier is now owed money again in your books without anybody having decided that. If a payment reminder runs off that status, the supplier will hear about it before you do.

Voiding a payment does not stop the money

Here is the thing that most needs saying plainly, and Intuit says it plainly enough that no interpretation is required.

On employee paychecks, voiding "changes your paycheck dollar amount to $0 but doesn't cancel a direct deposit or return funds." On contractor payments, voiding "changes your payment dollar amount to zero", and separately: "This doesn't stop a direct deposit from processing and doesn't return funds to you." And once the payment has gone through, the option disappears entirely: "If the direct deposit payment has been processed, you can no longer void, cancel, or delete the transaction."

Voiding is a bookkeeping act, not a real-world one. The ledger says zero. The bank does not care what the ledger says.

This is the single most expensive misunderstanding in the whole subject, because it feels like an action and produces a satisfying visual result. Somebody voids the payment, sees the zero, and reports the matter dealt with. The money leaves on schedule, and the discrepancy surfaces at the next reconciliation, by which time nobody remembers the four seconds in which it was created.

If you would rather have somebody go through what your books and your bank actually agree about, and where they only appear to, that is the process audit. $299, three business days, and a written map you keep whether or not you hire us.

For the bank reconciliation, void and delete are the same event

The folk rule in bookkeeping circles is "void, don't delete". It is decent advice in general and completely wrong in the one place where errors are most expensive.

Intuit's page on fixing a broken beginning balance lists the causes, and the relevant one reads: "A reconciled transaction was edited, deleted, voided, moved, or unreconciled." Voided sits in the same list as deleted, doing the same damage. The suggested diagnosis is to open the audit log and "Review the audit log for deleted or voided transactions" - the two words again treated as one problem.

Put plainly: when you void a check, every detail line on it is changed to a 0.00 amount and posted, so the impact on the books is just as if you had deleted it.

For a reconciliation, that is the whole story. The reconciliation matched a transaction of a certain amount against a bank line of the same amount. Change the transaction to zero and the match is broken, regardless of which verb you used to do it.

What follows is worse than the original problem. Undoing a reconciliation to repair it is itself, in Intuit's own description, irreversible, and it removes associated material along with it. So the sequence that begins with a four-second tidy-up can end with a decision that a bookkeeper genuinely should not make alone.

A user described the resulting mess on 16 January 2026, having voided two reconciled sales receipts and recreated them: "It is showing the old transaction, and the new transaction... It is showing a negative in the reconciliation amount, and I am unable to save and move forward."

A closed period is a warning, not a lock

Most owners assume that once the books are closed, the software will refuse to let anybody reach back into them. It does not, and the setting names give the game away.

Intuit documents that when someone tries to modify or remove a transaction dated on or before the closing date, "QuickBooks will either give a warning or ask for a password, depending on your settings." The two available settings are "Allow changes after viewing a warning" and "Allow changes after viewing a warning and entering password".

Both begin with the word Allow. There is no refuse.

And the lock is not on by default: turning it on is an administrator's action, which in a business of five people is very often an action nobody has ever taken. The result is that last year's numbers - the ones already reported, already quoted to a bank, already used in a return - can be altered by anybody who clicks past a dialog box on a busy afternoon.

The people this happens to are rarely careless. They are usually new: handed the account this year, discovering that whoever closed last year did so with it not balanced, and finding that the closed period neither lets them fix it cleanly nor stops them from making it worse.

Nothing downstream is told

This is the part that turns a bookkeeping curiosity into an operations problem, and the half of it that matters most is documented rather than inferred.

Your accounting system is not alone. It is connected to a payment processor, an online shop, a scheduling tool, a spreadsheet somebody maintains, possibly a CRM. When a transaction is voided or deleted, what do those systems learn?

For deletions, there is a signal. Intuit's change data capture documentation - the mechanism a connected system uses to ask what changed - states that "Deleted entities return a Deleted value for the status field.", and its worked example instructs the receiving system to remove the record or mark it as deleted. That is a clear, actionable message: this is gone, act accordingly.

For voids, there is nothing equivalent. I had the whole page read: it documents exactly one status value, Deleted, and never mentions voiding at all. So a connected system asking what changed is told in so many words when a record has gone, and is told nothing that would distinguish a void from any other edit.

Sit with the consequence. The action that is irreversible in your books is the one that reaches a connected system looking like a routine edit. The action that is recoverable in your books is the one that announces itself.

Two further limits on that mechanism matter for a small business. It remembers thirty days: "CDC operations can track changes within the last 30 days." A deletion from six weeks ago is invisible to a connected system that asks. And a single response is capped at a thousand records, which is precisely the case you hit while cleaning up duplicates - the one time bulk deletions happen.

Then there is the layer most small businesses actually use, which is not a custom integration at all. Zapier's QuickBooks Online page lists twenty-nine triggers: new account, new bank transaction, new bill, new customer, new estimate, new expense, new invoice, new payment, new deposit, new journal entry, updated bill, updated customer, updated invoice, and so on. Every one of them fires when something is created or updated. Not one fires when something is voided or deleted. There is an action to void an invoice - the tool can do it for you - and no way to learn that one happened.

Anyone who goes looking for a "deleted invoice" trigger finds the gap quickly. The route the platform offers instead is its generic API request action, which is to say: this does not exist as a feature, write it yourself.

So the practical position for a small business is that the books remember the cancellation and nothing else does. The CRM still shows the revenue. The chasing sequence still chases. The commission report still pays. This is the same shape as the problem in why automations fail silently, except that here there is not even a failure to detect. Everything worked.

It is worth saying that this is a design choice rather than a law of physics. Stripe, handling the same two intentions on its own invoices, emits a distinct event for each: one when an invoice is deleted, another when one is voided. Two human intentions, two named signals. The capability exists; it is just not uniformly offered by the systems where your books live.

The transaction you deleted comes back

There is a specific failure that follows from all of this, and it is common enough to be funny to the people it happens to.

The pattern is a transaction that is voided or deleted, and is back with the same amount at the next login - deleted five times, back five times. The cause is usually a bank rule set to add matching transactions automatically. The user deleted the record. Nobody told the thing that was creating it.

The same shape shows up in bulk: a morning spent deleting duplicates, and the next day the audit trail shows them all added back by the system itself. Or an import of a file of new transactions that quietly brings back several past ones that had been deleted.

None of this is a bug. In each case a rule, a feed or an import is doing the job it was configured to do, and deletion in the ledger is not an instruction to any of them. The record is a consequence of a process; removing the consequence does not change the process. That is the same question as which system owns the field, asked about existence rather than about values.

Not every system has these two buttons

It would be convenient if "void, don't delete" were a rule of bookkeeping. It is not even consistent across the products a small business is likely to be using.

Xero treats a void as terminal and says so twice: "Voided invoices can't be reinstated or restored." It also makes a different design choice about numbering than Intuit does, which catches people out: a voided invoice's number cannot simply be reused, and to reuse it you must change the number before voiding.

Zoho Books goes the other way entirely. A voided invoice can be brought back to draft, which the documentation presents as the recommended alternative: "This is a better alternative to deleting an invoice permanently, letting you retain any information in the invoice." Deletion there is final: "Once you delete an invoice, you will not be able to retrieve it again."

Wave has no void at all. Its documented invoice statuses run draft, unsent, sent, viewed, partial, paid, overpaid and overdue, with no void among them, and deletion is plain: "Deleted invoices cannot be recovered." It also does something the QuickBooks-shaped systems do not, which is simply refuse: "If an invoice was paid through Wave's online payment feature, the invoice cannot be deleted, even if it has been refunded."

FreshBooks has no Void command at all. The invoice menu offers Archive and Delete, and the nearest thing to a void is Mark as Bad Debt, which FreshBooks describes as a way to "write off or void the invoice so that it's no longer outstanding". It also inverts the QuickBooks instinct completely: deleted items "can be undeleted for later use", while "Deleting credits, payments, and time entries is permanent and cannot be undeleted". Same verb, two different degrees of permanence, inside one product.

Sage Accounting documents both, with deletion for drafts and voiding for posted invoices, and its UK knowledge base says of the pair: "Once you delete/void an invoice, you can't get it back and would need to enter a new invoice instead." Its guidance where tax is involved is to create a credit note instead of editing, deleting or voiding. Note the product name: none of this necessarily describes Sage 50, which a small business is at least as likely to be running.

Stripe, which is where many of these transactions are actually born, states the underlying principle more cleanly than the accounting packages do: a draft invoice can be deleted and not recovered, a finalised one cannot be deleted at all and can only be voided, and that void "is terminal, which means that the invoice's status can never change". The dividing line is not what you intended. It is whether the document has entered the world.

Six systems, and no two of them answer the whole question the same way. Any sentence beginning "in accounting software, voiding is..." is going to be wrong somewhere that matters.

What the tax authorities actually ask for

The reason all of these systems refuse to simply forget is not stubbornness, and it is worth grounding in something more solid than folklore. I am going to be careful here, because this is an area where confident sentences do real damage.

The IRS's guidance on business records is permissive about method and firm about substance: "You may choose any recordkeeping system suited to your business that clearly shows your income and expenses", and "Your books must show your gross income, as well as your deductions and credits." Then the clause that matters for anyone whose books exist only inside software: "All requirements that apply to hard copy books and records also apply to electronic records."

The software does not get an easier standard than the shoebox.

There is an older document, a revenue procedure published in 1998 setting out how records kept in an automated system must work, that names the requirement in the exact language a software designer would use: "the internal controls used to prevent the unauthorized addition, alteration, or deletion of retained records". I have not checked whether that procedure has been superseded in the years since, so read it as an illustration of where the design comes from rather than as current guidance - but it does explain why your accounting package behaves as it does.

In the UK the framing is about retention rather than mechanism. Companies must keep records of "all money received and spent by the company", must keep them "for 6 years from the end of the last company financial year they relate to", and gov.uk states the consequence directly: "You can be fined £3,000 by HMRC or disqualified as a company director if you do not keep accounting records."

And there is one rule that speaks to this article's central problem more precisely than anything else I found. For VAT-registered businesses under Making Tax Digital, the required links between systems must be digital, and the notice is explicit about the alternative: "Manually transferring data within or between software programs, products or applications (that make up functional compatible software) is not acceptable under Making Tax Digital."

Which is worth reading twice in the context of everything above. When you void something in your books, and nothing downstream is told, the obvious remedy is for a person to go and fix the number in the second system by hand. For a VAT-registered UK business, that remedy is the specific thing the rule names.

None of this is legal advice, the rules differ by country, and your accountant is the person to ask about your own case. The point is narrower: the behaviour that feels like software being awkward is software implementing somebody's requirement.

What to check in your own setup

Find out who can see the audit log. If the answer is one person and that person is not the person doing the bookkeeping, the recovery route is theoretical.

Check whether your books are locked at all. Not whether they are closed - whether the lock is switched on, and which of the two settings is in force. Both allow changes; only one asks for a password first.

Ask what happens downstream, per connection. Take one recent void and one recent deletion, then look at each connected system in turn and see what it believes. Do this once and you will know your own answer rather than the general one.

Find the automatic creators. Bank rules, imports, recurring templates, syncs from a shop or a payment processor. Anything that creates transactions on its own will recreate what you remove unless it is changed too.

Write down which action your business uses, and for what. Not because one is right, but because at the moment the choice is being made independently, several times a week, by whoever is nearest.

Ask your accountant before touching a closed period. The software will let you. That is not the same as it being a good idea, and the repair for a broken reconciliation is worse than the original error.

When this stops being a settings question

For a business with one accounting system and a bookkeeper who reconciles monthly, the checks above cover it. Decide the rule, restrict who can reach the closed period, and know where the audit log is.

It stops being that when the cancellation has to travel. The invoice is in the books, the order is in the shop, the payment is with the processor, the job is in a scheduling tool, and the customer is in a CRM that is still counting the revenue. Cancelling in one of those is not cancelling; it is telling one of five systems something the other four will never hear. That is the same problem as the order that was cancelled after the invoice went out, arriving from the accounting end instead of the sales end, and it has the same resolution: somebody has to decide which system's version is the truth, and then make the rest follow.

Working out whether that is a rule or a rebuild is what the process audit settles: what can be automated, in what order, and what each piece is worth, in writing, in three business days.

Nothing here is accounting, tax or legal advice.

Related: when a new account breaks your bookkeeping automation is this article's mirror image, where the thing that upsets your connected systems is a record appearing rather than one disappearing.