Bulk Voiding
An import ran twice. A migration batch landed in the wrong entity. A whole month of test documents needs to disappear from the books — properly, with reasons, not with deletes. Bulk voiding is the same Bulk Status Update tool pointed at Void, plus one extra field that matters more than all the rest: the reason.
Access you'll need. Voiding in bulk needs the same permission set as voiding one record: Accounts Payable v2 or Accounting Admin v2 for Purchase Invoices, Purchase Orders and Cash Disbursements; Accounts Receivable v2 or Accounting Admin v2 for Sales Invoices; Accounting Admin v2 or Accounting Controller v2 for Journal Entries. The Read Only v2 set cannot void.
The run
Select ruthlessly, precisely
Voiding undoes real accounting — so make the selection prove itself. Filter the list view down to exactly the bad set (the duplicate import’s date-stamp, the wrong entity) and eyeball every row before ticking.
Target Status: Void — and write a real reason
Choosing Void reveals the Void Reason box on documents that record one (sales and purchase invoices, including their memo types). One reason applies to the whole run — which is exactly right, because a bulk void should be one event: "Duplicate import 02-Jul — batch reversed." Cash documents and journal entries void without a stored reason; consider a note on the records if the context isn’t obvious.
Apply, and account for every record
Per record, the full void logic runs: accounting entries removed, applications unwound (payments and credits become available again), the document frozen with reason and date. The result report tells you exactly which voided and which refused — with reasons to act on.
Reading a void run’s summary — a Meridian example
Meridian Properties Group’s controller is clearing a batch that an import created twice. She filters the list view to the duplicate set and launches the tool; the summary reads "12 selected: 8 Draft, 3 Posted, 1 Void". That one line already tells her three things:
- The 1 Void record is already where she’s sending everything — it will be skipped untouched and reported as already at target. Someone got to it first; no harm.
- The 3 Posted records will each run their full void logic: accounting entries removed, applications unwound, reason and date stamped.
- The 8 Draft records are worth a pause — a draft never touched the books, so a duplicate draft can often simply be deleted rather than voided. If they belong in the run at all, the summary line is where she decides.
She writes the reason — "Duplicate import 02-Jul — batch reversed" — and applies. The result screen’s tiles (Updated / Already at Target / Failed) account for every record, and anything that refused comes back linked, with its exact reason in the failures table, duplicates collapsed.
What Void changes, document by document
| Document | What its void does |
|---|---|
| Sales Invoices (incl. credit memos) | Accounting entries removed, applications unwound (payments and credits become available again), void reason and void date recorded. Afterwards it’s frozen: "Voided Sales Invoices cannot be modified." |
| Purchase Invoices (incl. vendor memos and expense invoices) | The payables mirror — entries removed, reason and date stamped, then "Voided Purchase Invoices cannot be modified." |
| Cash Disbursements | The payment’s accounting is reversed — but check numbers consumed at posting are never returned; a reissue takes the next number. See Voiding a Disbursement. |
| Journal Entries | Per the action’s own description: "Void this journal entry. The Accounting Transactions are removed and the entry becomes immutable until reopened." |
| Purchase Orders | Void releases the order’s budget commitment — the money it was holding on the budget becomes available again. |
The refusals, verbatim
A record that can’t void tells you exactly why — the same message it would give you one at a time:
| The message | What it means / what to do |
|---|---|
| "Please provide a reason for voiding this invoice." | Invoices and memos record a void reason — write one in the Void Reason box before applying. |
| "Please provide a Void Date." | The void needs to know which day it belongs to — supply the date. |
| "Cannot void a Sales Invoice with applied payments or credits. Reverse the applications first." | Dependencies unwind in order: remove the applications, then re-run the void on that record. |
| "Cannot unpost or void this Sales Invoice because its auto-generated Cash Receipt could not be removed: {0}" | A cash-sale invoice travels with its own receipt; whatever blocks the receipt (the quoted reason) blocks the invoice. Fix that first. |
| "This Cash Receipt cannot be unposted or voided because it is reconciled. Remove the reconciliation first." | Bank-matched money is protected — deliberately unmatch it in the reconciliation before touching the receipt. |
| "Posted entries dated on or before the closure date cannot be unposted." | Closed books protect their contents from bulk cleanups too — reopen deliberately, or leave history alone. |
Void back to Draft instead?
If the documents are fundamentally right but need correction (wrong period, wrong account), bulk-update them to Draft instead — entries removed, documents editable, nothing frozen. Reserve Void for documents that should never have existed; reserve Draft for documents that should exist differently.
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Voiding from an eyeballed, unfiltered selection | One mis-ticked row voids a perfectly good document — real accounting, undone by accident | Build a filter that is the bad set (import date-stamp, wrong entity), verify every row, then select |
| Voiding when Draft was the right target | Fundamentally correct documents get frozen forever over a fixable date or account | Void what should never have existed; send what should exist differently back to Draft |
| Running the void with no plan for freed payments | Voiding settled invoices releases the cash that settled them — unapplied money nobody is expecting | Decide before the run where freed payments and credits should go; apply or refund them straight after |
| A vague or empty void reason | Invoices demand one ("Please provide a reason for voiding this invoice."), and a vague one is barely better — audits stall on "why?" | One specific sentence naming the event: what happened, when, what this run does about it |
| Trying to "void" by deleting | Posted documents refuse deletion — and if they didn’t, your audit trail would have holes where money used to be | Void with a reason; the document stays on file as evidence of the correction |
Where to go next
- Bulk Updates Overview — the tool, with screenshots.
- Posting & Voiding a PI — what void means on one document.
- Voiding a Disbursement — the payment-side specifics (check numbers!).
Frequently asked questions
No — one run, one reason, by design: a bulk void should be one explainable event. Records needing individual explanations deserve individual voids.
Same rules as voiding singly — the report quotes each reason. A classic: a payment can’t simply vanish while things depend on it; unwind dependencies first, then re-run the stragglers.
There is no bulk delete of posted documents — deliberately. Posted records live forever, voided or not; that permanence is your audit trail. Only never-posted drafts can be deleted at all.
Sales and purchase invoices, including their credit-memo and vendor-memo types — the reason and the void date are stamped on each voided document. Cash documents and journal entries void without a stored reason, so give context in a note on the record when it isn’t obvious.
Nothing — it’s reported as already at target and left completely untouched: its original void reason and date survive. That skip is what makes re-running a partially failed void safe.
Each void is logged in the Audit Log — the action, who performed it, when, and which record — and every voided invoice carries its reason and void date on its face. A bulk void is many ordinary, fully recorded voids.
Was this article helpful?