Why you can't edit an invoice after it's posted — and what to do instead

A paper goods distributor running eleven vans out of two depots had an office admin named for this story only as "the AR clerk" — in practice whoever answers the phone when a customer disputes a bill. A driver had kept a case count wrong on his handheld: a customer who took 18 cases of napkins got billed for 24. The invoice posted, synced to the office that night, and showed up on the customer's statement the next morning as a $340 overcharge.

The AR clerk pulled up the invoice to fix the line, the way she'd fix a typo in an email. The quantity field wouldn't take input. She tried the price field — also locked. She called support assuming it was a bug. It wasn't a bug. Every invoicing system that's been through an audit behaves this way on purpose, and the reason matters more than the inconvenience.

The invoice already left the building

The moment an invoice posts, it stops being a draft and becomes a record two separate parties rely on. The customer has a copy — on paper, in their inbox, in their own payables system — with a specific number, a specific total, a specific date. Your own books have booked the matching receivable. If you quietly change the $340 to the correct $255 inside your system, you now have two documents under the same invoice number disagreeing with each other, and no way to tell, three months later, which one the customer actually paid against. Multiply that by every rep who's ever fat-fingered a quantity and "just fixed it," and the receivables ledger stops being a record of what happened and becomes a record of whoever edited it last.

This is the same reason accountants don't erase a mistake in a paper ledger — they cross it out with a single line, write the correction next to it, and initial it. The original entry stays legible. Software calls this an audit trail, and it exists for an unglamorous reason: when a number is wrong later, in a tax filing, a bank reconciliation, or a customer dispute, you need to reconstruct not just the correct figure but what was actually billed, when, and why it changed. An editable invoice destroys that history silently. A wrong quantity typo and a deliberately back-dated discount look identical in a system that just lets you overwrite the field — which is exactly why the control doesn't ask about intent. It just doesn't allow the edit.

Why the workaround is worse than the wait

At the paper goods distributor, the AR clerk's manager had a faster idea: ask whoever managed the database to update the row directly. It took fifteen minutes. The invoice total now matched what the customer should owe.

Three things broke that nobody noticed until month end. The commission run that afternoon had already paid the rep commission on the old $340 before the edit landed, and nothing recalculated it. The customer's own copy of the invoice, already filed in their payables system with the original total, now disagreed with the distributor's system with no paper trail explaining why. And when the bank deposit came in two weeks later for $255, automatic payment matching couldn't reconcile it against an invoice that had been silently rewritten after the fact — the matching logic, like most, keys off the invoice as originally issued. Day close didn't balance, and finding out why took the controller most of an afternoon of cross-referencing exports, because the correction left no entry of its own to point to.

None of that would have happened with a five-minute correction done the right way.

What actually happens instead

The fix is a second transaction, not a changed one. Concretely:

Void or credit, don't overwrite. The original invoice stays exactly as issued — same number, same total, same date. A credit memo or a reversing entry is posted against it for the difference, and a new, correct invoice goes out if one is still owed. Anyone looking at the account later sees three documents that tell the true story: billed $340, credited $85, net owed $255. Nothing was erased.

The correction carries its own timestamp and reason. Because it's a new entry, not an edit, it lands in the ledger with its own date and — in a system worth using — a note explaining why: short count, pricing error, damaged goods. Six months later, someone can answer "why did this customer's total change" without guessing.

Downstream numbers stay consistent. Commission, receivables aging, and payment matching all read from the same append-only history. A credit memo posted today correctly reduces today's commission base and today's open balance — it doesn't quietly rewrite yesterday's numbers that other reports, and other people's decisions, were already built on.

Closed periods stay closed. Once a day or month has been closed out and reconciled, nothing — correct or not — should post into it silently. A correction to a closed period is its own dated, visible entry in the current period, not a rewrite of history that's already been signed off on.

This is slower than clicking into a field and typing a new number. That's the point: the five minutes it costs to do it as a correction is the same five minutes that would otherwise get spent, at month end, reconstructing what actually happened from a ledger that no longer tells the truth.

What to check in your own system

• Try to edit a posted invoice's quantity or price. If it lets you, ask what happens to commission, receivables aging, and payment matching the moment you save — if nobody can answer cleanly, the edit is silently breaking something downstream.
• Confirm corrections post as a dated credit memo or reversing entry, not an in-place change, and that the original document is still visible afterward.
• Check whether a correction updates commission and aging for the day it was made, or retroactively rewrites a day that's already closed.
• Ask whether closed periods can be edited at all, by anyone, without a visible new entry.
• If "just update the database" has ever been the fix for a billing mistake at your business, treat that as the actual problem, not the invoice typo that triggered it.

iotoms' ledger is append-only for exactly this reason: a posted invoice can be credited or reversed but never silently rewritten, every correction carries its own date and reason, and receivables aging, commission, and payment matching all read from that same unaltered history — so the number in the chat assistant, the aging report, and the customer's own copy of the invoice always agree.