Closing, voiding, and reactivating invoices

Closing locks an invoice as final; voiding cancels it as if it never happened. They're not the same and they sync differently to QuickBooks. Here's the lifecycle, when to use each, and the rare case for reactivation.

Closing, voiding, and reactivating invoices

An invoice has more states than people realize, and choosing the wrong action — closing when you should void, or voiding when you should issue a credit — leaves audit trails and QuickBooks in a state that takes work to clean up. This article walks through the lifecycle, the right action for each scenario, and the rare cases where a closed invoice gets reactivated.

The lifecycle

A Suprata invoice moves through these states, in roughly this order:

  1. Draft / Open — created, editable, not yet sent. Line items can be added or removed; totals can change.
  2. Sent — the customer has received it (by email, link, or print). Still editable, but every change should be deliberate because the customer has seen the original.
  3. Approved (estimates only) — the customer signed off; an estimate at this state is ready to convert to an invoice.
  4. Partially Paid — one or more payments have been applied but the balance is not zero.
  5. Paid — the balance hits zero through payments and/or applied credits.
  6. Closed — locked from edit. Final. Reportable as revenue.
  7. Voided — cancelled as if it never happened. Removed from revenue calculations.

A few states overlap or branch — an invoice can be Sent and Partially Paid at the same time. Closed is a one-way street under normal operations; reactivation is a deliberate admin action.

Closing vs. voiding — the operational difference

The two terminal states get confused because both "end" an invoice. They mean different things:

Close Void
What it represents The invoice is final and complete The invoice should never have existed (or is being undone)
Effect on revenue Counts as revenue Removes from revenue
Tax effect Counts toward tax-collected Removes from tax-collected
Edit-ability Locked, not editable Locked, not editable
QB sync Pushes to QB as a final invoice Voids in QB or removes the sync
When to use Job done, billed, paid, archived Mistake, duplicate, cancelled work

Close when the invoice did its job. The customer paid (or the balance was settled by credit), the work is done, and you want to lock the record so nobody edits it after the fact. Closed invoices count toward your revenue and tax reports.

Void when the invoice shouldn't exist. You created a duplicate, billed for work that didn't happen, made a billing error so large that re-issuing is cleaner than crediting, or cancelled a job before any work happened. Voided invoices are removed from revenue and tax — they're treated as if they never were.

Both lock the invoice from further edit. Both push a final state to QuickBooks. The difference is whether the invoice contributes to your reported revenue.

When to close

Close an invoice when:

  • It's been fully paid (or the balance is zero through credits applied).
  • The work it represents is genuinely complete.
  • You don't expect to issue any more line items, refunds, or credits against it.
  • You're done with it operationally and want it locked from accidental edits.

Closing a partially-paid invoice is unusual but valid in a few cases — for example, you've decided to write off the remaining balance and the customer is no longer being pursued. In that case, apply a credit equal to the remaining balance first (so the invoice goes to zero through legitimate accounting movement), then close. Don't close with an open balance and no resolution; that's an audit-trail oddity that's hard to explain later.

When to void

Void an invoice when:

  • It was created in error (duplicate, wrong customer, wrong job).
  • The work it represents was cancelled before any value was delivered.
  • The line items are wrong in a way that re-issuing is cleaner than editing or crediting.
  • The invoice was sent but the customer disputed it and you both agree it shouldn't have existed.

A handful of common situations to watch for:

  • Customer cancelled the job before any work happened. Void if no money has changed hands. If a deposit was already paid and is being refunded, void after refunding.
  • You generated a duplicate by mistake. Void the duplicate; keep the real one.
  • You realize the invoice is wrong and you've already sent it. This is the trickiest case. Options:
    • Edit it if it's still in Open/Sent and not Closed/Paid. Re-send with a brief apology.
    • Issue a credit memo for the over-billed amount if the customer has already paid (see Customer credits and refunds).
    • Void and re-issue if the invoice is structurally wrong (wrong customer, wrong job, fundamentally incorrect line items) and you haven't been paid yet.

When NOT to void

Voiding is the wrong tool when:

  • The customer paid the invoice and now wants a refund. Don't void the invoice — refund the payment. Voiding while there's a payment attached creates a phantom payment with no invoice to apply to and confuses QB sync. See Refunds and partial refunds.
  • You over-billed and the customer paid the inflated amount. Issue a credit memo or partial refund. Voiding loses the record of what was billed and paid.
  • A partial scope-change happened on a job. Edit the still-open invoice, or issue a credit for the difference. Voiding and re-issuing rebuilds the audit trail unnecessarily.
  • The work happened but the customer is refusing to pay. That's a collections issue, not a void. The invoice is real; track it as overdue and follow your collections process. Voiding to "give up" misstates revenue.

QuickBooks implications

If QuickBooks is connected, closing and voiding push different events to QB:

  • Close → invoice is finalized in QB, contributes to QB revenue, taxes in QB tax reports.
  • Void → invoice is voided or deleted in QB (depending on configuration), drops out of QB revenue, removes from QB tax reports.

This is the source of most "the QB number doesn't match the Suprata number" issues. If a Suprata invoice is closed and a QB invoice for the same record is voided (or vice versa) due to a sync hiccup, the totals diverge. Run the QB sync report periodically to catch state mismatches early.

The cancelled/voided invoice report shows your voided invoices in one place — useful for audit and reconciliation:

The cancelled and voided invoice report

Reactivating a closed invoice

This is rare. Closed is supposed to mean final. But sometimes:

  • You closed the invoice prematurely and need to add a line that should have been on the original.
  • You discovered an error after closing and the cleaner fix is to edit-and-recompute rather than credit-and-re-bill.
  • A payment was applied to the wrong invoice and you need to detach it.

If you have admin permissions and the system surfaces a "Reactivate" or "Reopen" action, use it deliberately:

  1. Reactivate the invoice.
  2. Make the change.
  3. Close it again.
  4. Verify QB synced the corrected version, not just the original close. Check the QB sync log.

The gotcha: reactivating an invoice that already flowed to QuickBooks and then re-closing it can confuse the QB side — the invoice is already there as final, and a second close event isn't something QB always handles cleanly. The exact behavior depends on your QB version and your sync configuration.

Better default: don't reactivate. If a closed invoice is wrong, issue a credit memo or a follow-on adjustment invoice. Treat closed as actually final and use credits/adjustments to make corrections. Reactivation is for the rare, well-justified, single-record fix — not a routine workflow.

Reactivating voided invoices

Voided invoices generally cannot be un-voided; the action is intended to be permanent. If you voided in error and need that invoice back, the practical path is to create a fresh invoice with the same line items rather than trying to resurrect the voided one. Yes, the invoice number will be different. Yes, that's annoying. It's also the cleanest audit trail.

A clean lifecycle in practice

For 95% of invoices, the path is:

  1. Create as draft.
  2. Send to customer.
  3. Customer pays.
  4. Close.

That's it. No voids, no reactivations, no credit memos. The complications above only enter the picture when something goes wrong — and the goal is to handle them with the right tool the first time so you don't accumulate a thicket of mismatched states.

Common mistakes

  • Voiding paid invoices instead of refunding. The payment is still attached; voiding the invoice leaves the payment with nowhere to go. Refund the payment first; then if there really should be no invoice record, void after the refund settles.
  • Closing invoices with non-zero balances. Creates "closed but unpaid" records that look like a collections issue forever. Resolve the balance (credit, write-off, refund, payment) before closing.
  • Voiding to fix a small error. Editing while still Open is almost always cleaner than void-and-reissue. Save voiding for invoices that genuinely shouldn't exist.
  • Reactivating routinely to make edits. Reactivation is an exception path, not a workflow. If you find yourself reactivating monthly, either you're closing too early or you need credit memos / adjustment invoices for ongoing changes.
  • Forgetting that QuickBooks updates on a delay. A close in Suprata flows to QB on the next sync run, not instantly. If you close and then immediately void to "undo", QB may receive both events out of order. Wait for the first sync to confirm before issuing the reversing action.
  • Mixing up Approved (estimates) with Closed (invoices). Approved is an estimate state — the customer signed off and you can convert it to an invoice. Closed is for invoices that are final. They're not interchangeable; an estimate doesn't get "closed", it gets converted (and the resulting invoice goes through its own lifecycle).
  • Not recording why an invoice was voided. Voids should always have a documented reason in the invoice notes — "duplicate", "customer cancelled job", "billing error replaced by inv #2345". An auditor who can see the void but not the reason will assume the worst.

Related articles