Voiding a Disbursement
A check gets lost in the mail. A wire bounces back. A payment went to the wrong vendor entirely. When a payment must be cancelled, you void it — and REDA Financials unwinds everything the payment did while keeping a permanent record that it existed. This article covers voiding a single payment, what happens to the bills it had settled, the special rules for checks, and voiding an entire batch.
Access you'll need. Voiding these requires the Accounts Payable v2 permission set (AP clerks & managers) or Accounting Admin v2 (system administrators). The Accounting Controller v2, Accounts Receivable v2, and Read Only v2 sets can view but not void.
What voiding does
Change the status to Void and give the reason
On the posted payment, set it to Void. A Void Reason is required — "check lost in transit, reissuing" beats "void" when someone asks in eighteen months. The void date is recorded alongside.
REDA Financials unwinds the payment
Its accounting entries are removed — the cash returns to your books' bank balance. Every application is deleted, so each invoice the payment had settled gets its balance due back and reappears in AP aging.
The record remains — and the void can be undone
The voided payment can't be edited or deleted; with its reason and date it becomes a permanent line in your audit trail. But voiding is not a one-way door: Reopen puts a voided payment back to Draft, where you can correct it and post it again. There are no side effects to clean up — the void already removed the applications and accounting entries. Reopen only works on a voided payment; if you would rather start fresh, create a new one.
Everything a void unwinds — at a glance
| What the payment did | What the void does about it |
|---|---|
| Recorded cash leaving the bank (its accounting entries) | Entries removed — your books' bank balance gets the money back |
| Settled invoices (its applications) | Every application deleted — each invoice's balance due returns and it reappears in AP aging, aging from its original due date |
| Consumed a check number | Kept, permanently — the number stays stamped on the voided record and is never reused |
| Existed as a record | Stays forever, frozen, with Void Reason and void date — it can't be edited or deleted |
Voiding a whole payment batch
If an entire payment run was wrong — wrong date, wrong bank account, duplicated run — void the batch instead of its payments one by one. Voiding a batch cascades: every payment in it is voided together, each unwinding its own entries and applications, and the batch's void reason is stamped on all of them. See Batch Posting & Voiding.
Void vs. reopen — pick by what happened
| Reopen to Draft | Void | |
|---|---|---|
| The money… | …never really left, or the record is simply wrong (amount typo, wrong bank account) | …left but came back, or must be treated as never effective (lost check, failed wire, wrong vendor) |
| Afterwards | Edit and post again — same payment, corrected | Record is frozen — but Reopen can put it back to Draft to correct and re-post, or issue a new payment |
| Audit trail | History shows the correction | History shows a cancelled payment with its reason |
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Voiding to fix a wrong application | The void unwinds the whole payment — cash entries, every application, and (for checks) a number spent for nothing | Delete just the wrong application and re-apply — see Applying Disbursements |
| Voiding a payment the bank already cleared | Your books say the money came back; the bank statement says it didn't — reconciliation breaks | Reconcile first; if the money truly left, the follow-up is with the vendor, not the record |
| Writing "void" as the Void Reason | The reason is permanent and it's the one thing an auditor reads first | Say what happened: "check lost in transit, reissued as next check number" |
| Forgetting the stop payment on a lost check | REDA Financials records your side — the paper check can still clear at the bank | Place a stop payment with the bank before reissuing |
| Voiding one payment when the whole run was wrong | You'll repeat the void N times and lose the one-line explanation a batch void gives | Void the batch — every payment in it voids together, with one reason |
Where to go next
- Understanding Cash Disbursements — the payment lifecycle.
- Batch Posting & Voiding — the cascade in detail.
- Check Stock & Check Printing — check number management.
Frequently asked questions
Because that's the truth: the bill is unpaid again. Voiding unwound the application, restored the balance due, and aging resumed from the original due date. Issue the replacement payment to clear it.
A voided payment can be set back to Draft — its void reason and date clear, and you can post it again. Use that only when the void itself was the mistake; if anything about the payment needs to change, a fresh payment keeps the story cleaner.
Yes — place a stop payment with your bank for a lost or stolen check. REDA Financials records your side of the void; the stop order prevents the paper check from clearing anyway.
Only if it's a draft with no check number — drafts never touched the books, so deleting them is harmless. A posted payment must be voided, and any payment carrying a check number can never be deleted (the number must stay traceable), even as a draft.
Not much — the payment voids individually and stays linked to its batch (with Void status), so the run's history remains complete. Only if the entire run was wrong should you void the batch itself, which cascades to every payment in it.
The void deletes the payment's applications — including any discount recorded on them — so the invoice returns to its full balance due. When you reissue the payment, take the discount again only if you're still inside the discount window.
Was this article helpful?