Fix your own invoicing mistakes

Void, delete or reverse — three separate remedies for three different mistakes, each requiring a written reason kept on the record.

What it is

A self-serve correction system covering the three things that actually go wrong: an invoice that was real but is now cancelled (void), an invoice that should never have existed (soft delete), and a payment recorded in error (reversal). Every action is enforced server-side, requires a reason of at least three characters, and stamps who did it and when.

Also called: void an invoice · delete an invoice · cancel an invoice · undo a payment · invoice mistake

See it, piece by piece
01

Void, delete or reverse — three remedies for three different mistakes

An invoice that was real and is now cancelled gets voided. One that should never have existed gets deleted. A payment recorded in error gets reversed. All three are enforced on the server rather than only in the interface, and all three are done by the person who made the mistake in under a minute instead of by an email to support.

Void this invoice
Void this invoice

INV-2026-0041 — CO-3 Overhead Doors · $9,482.35

It keeps its number and stays on the record, struck through, and stops counting toward your revenue. Use this when the invoice was genuine but the work or the charge is cancelled.

Reason *
Cancelled — job did not proceedReplaced by a corrected invoiceBilled the wrong amountBilled to the wrong customer
Replaced by a corrected invoice — door count went from 2 to 3 after the site visit.
Saved with your name and the date. Only your team sees it — never the customer.
CancelVoid invoice
The void dialog — what the action does, stated before you confirm it. The real screen, drawn from the product’s own design system. Sample data — no customer information appears here.
02

A cheque keyed twice can be backed out, and the balance rebuilds itself

The reversed payment stays listed and struck through rather than disappearing, and the invoice's paid figure is recomputed as the sum of the payments that still count. Nothing subtracts from a stored number, because subtraction is right exactly once — the row that started all this held $20,410.12 against a $10,205.06 invoice, a figure no correct arithmetic ever produced. Recomputing from the rows fixes a total that was already wrong.

03

Every correction records why, with your name and the date

The confirm button stays off until a reason is typed, and four one-tap picks drop a starting sentence into the box that you can then add to — “Duplicate — the same payment was entered twice”, plus the cheque number. It is saved with your name and the date, and only your team ever sees it. A quarter that dropped $10,205 with no note attached is a question you cannot answer three months later.

Void this invoice
Void this invoice

INV-2026-0041 — CO-3 Overhead Doors · $9,482.35

It keeps its number and stays on the record, struck through, and stops counting toward your revenue. Use this when the invoice was genuine but the work or the charge is cancelled.

Reason *
Cancelled — job did not proceedReplaced by a corrected invoiceBilled the wrong amountBilled to the wrong customer
Replaced by a corrected invoice — door count went from 2 to 3 after the site visit.
Saved with your name and the date. Only your team sees it — never the customer.
CancelVoid invoice
The four quick-pick reasons above the box — a starting sentence, still editable. The real screen, drawn from the product’s own design system. Sample data — no customer information appears here.
04

A void keeps its number; a delete keeps its record

A voided invoice stays in the list, struck through, showing who voided it and why, and drops out of every revenue total — but it never gives its number back for reuse. A deleted one disappears from every list, total and portal link while the row survives privately with its reason, so an accountant asking what happened to 0055 still gets an answer. Nothing here is erased.

Void this invoice
Void this invoice

INV-2026-0041 — CO-3 Overhead Doors · $9,482.35

It keeps its number and stays on the record, struck through, and stops counting toward your revenue. Use this when the invoice was genuine but the work or the charge is cancelled.

Reason *
Cancelled — job did not proceedReplaced by a corrected invoiceBilled the wrong amountBilled to the wrong customer
Replaced by a corrected invoice — door count went from 2 to 3 after the site visit.
Saved with your name and the date. Only your team sees it — never the customer.
CancelVoid invoice
The line under the invoice number — it keeps that number, stays on the record struck through, and stops counting toward revenue. The real screen, drawn from the product’s own design system. Sample data — no customer information appears here.
05

An invoice with money against it cannot be deleted, only voided

The server refuses and names what to do instead: void it, or reverse the payment first if it was never really received, and then the delete is allowed. Removing the document a payment was received against leaves that payment attached to nothing — and it is the one mistake here whose consequence you cannot see at the moment you make it.

How it works
  1. 1All three route through POST /api/invoices/correct rather than the generic database proxy.
  2. 2The route rejects any action without a reason and caps it at 500 characters.
  3. 3Tenancy is checked on the row before anything is written — a payment id alone is not authority to change a balance.
  4. 4A reversal re-derives paid_amount, balance and status from the surviving payment rows.
Why we built it

A builder who could not fix his own billing mistakes had to ring somebody else to do it, and until that call happened his monthly, quarterly and annual reporting was wrong. The case that forced it: two identical $10,205.06 invoices on one job, one of them raised by accident — and on investigation the deeper fault was a single cheque recorded twice, eight seconds apart, leaving $20,410.12 sitting against a $10,205.06 invoice. Voiding an invoice, deleting one that should never have existed, and reversing a payment are now things the builder does himself, each requiring a written reason so the books still explain themselves three months later.

The problem
  • Builders unable to fix their own billing errors without a support ticket.
  • Cancelled or duplicated invoices corrupting monthly, quarterly and annual reporting.
  • Payment entry errors permanently distorting an invoice's paid balance.
Sound familiar?
What you get
A mistake is fixed in under a minute by the person who made it.
Every correction is explainable at year end without anybody's memory.
Corrected invoices drop out of revenue figures immediately.
What's inside
Void an invoice
Cancel an invoice that was genuine — it keeps its number, stays visible struck through, and stops counting toward revenue.
Delete an invoice that should never have existed
Hide an invoice from every list, total and portal link — while the row survives privately with its reason so the gap can still be explained.
A paid invoice can't be deleted, only voided
The server refuses to delete an invoice that has payments against it, and explains what to do instead.
Reverse a payment recorded in error
Back out a payment that was never really received — it stays listed, struck through, and the invoice balance and status are recalculated from what remains.
Every correction records why
Voiding, deleting or reversing requires a written reason — with one-tap common answers — saved with your name and the date, visible only to your team.
Type DELETE to remove a draft
A draft invoice can be removed outright, but only after typing the word DELETE — and only while it is still a draft.

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →