Bulk Status Updates
Month-end at Meridian ends with a familiar scene: a dozen draft journals — accruals, allocations, the recurring batch's output — all reviewed, all ready. Posting them one by one is clicking for its own sake. The Bulk Status Update tool posts (or reopens, or voids) a whole selection in one run, with a per-record report of what happened.
Access you'll need. Posting, reopening, and voiding entries in bulk requires the Accounting Admin v2 or Accounting Controller v2 permission set. The Accounts Payable v2, Accounts Receivable v2, and Read Only v2 sets can view entries but not change their status.
Running one
Select records in a Journal Entries list view
Filter a list view to the batch you mean (e.g., Status = Draft, this month), tick the rows, and click Bulk Status Update.
Review the breakdown, pick the target status
The tool shows how many of your selection sit in each status, and asks where they should go — Posted for the month-end scenario; Draft (mass reopen) and Void (mass cancel) work the same way.
Run, then read the results
Each record is processed independently: successes commit, failures roll back that record only and appear at the end with the full error message. As the built-in help puts it: "Records already at the target status are skipped (not failed). Failures, if any, are listed at the end with the full error message — fix and re-run on the failed subset."
The three targets and what each does
| Target Status | What happens to each selected entry | Watch for |
|---|---|---|
| Posted | The full posting run: gates checked, ledger rows written, entry locked — identical to clicking Post on the record | Unbalanced entries, closed books, inactive accounts — each failure reports its exact message |
| Draft | A mass reopen: each posted entry's ledger rows (and tax records) are deleted and the entry unlocks for editing | Entries in closed periods or with reconciled lines refuse, by name |
| Void | A mass cancel: ledger rows removed, entries locked as Void, kept on file | This is a real void per record — the entries stay voided until individually reopened |
Three behaviors hold for every run:
- Already-there records are skipped, not failed — selecting a mixed list and targeting Posted simply posts the drafts and waves the rest through.
- Each record stands alone. A failure rolls back that record only; it can't take the batch down with it.
- Every failure reports its real message — the same text you'd see posting that entry by hand, listed per record in the results table.
No shortcuts through the gates
Bulk is a convenience, not a bypass. Every entry passes the exact same posting checks it would face alone — balanced, open period, open books, healthy accounts — and a bulk reopen deletes each entry's ledger rows exactly as an individual reopen would. One unbalanced entry in a batch of twenty means nineteen post and one is reported back; the batch never poisons itself.
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Running on an unfiltered list view | "Select all" on the wrong view posts — or voids — entries you never reviewed | Filter first (Status = Draft, this month), eyeball the rows, then select |
| Treating failures as a retry problem | Re-running the same batch reproduces the same failures — the gate messages are naming real defects | Fix each failed entry per its message, then re-run on the failed subset |
| Bulk-reopening reconciled entries | They fail one by one ("…has reconciled lines. Remove the reconciliation first.") | Unmatch them in the bank reconciliation deliberately before any mass reopen |
| Using bulk post to force problem entries through | There's nothing to force — bulk runs the same gates as the Post button | The gates are the quality bar; make each entry pass on its own merits |
Where to go next
- Posting & Unposting JEs — the gates each record passes.
- Bulk Posting — the cross-module picture.
- Recurring Journal Entries — where month-end's drafts come from.
Frequently asked questions
No — the successes are committed. Fix the failed entries per their error messages (usually an unbalanced line or a closed period), select just those, and run again.
The shared tool serves documents that require one (invoices record a void reason). Journal entries don't carry a void-reason field, so anything typed there is simply not stored for JEs.
Selections process record by record, so large batches simply take longer. For very large operational sweeps (hundreds+), the scheduled batch tools in Bulk Updates Overview are built for scale.
No — a status update never creates entries, and reversal means new mirror entries. Accruals with a Reversing Date are reversed by the auto-reversal scheduler; this tool changes the status of the entries you select, nothing more.
No — skipped means "already at the target status", counted separately from failures precisely so you can select generously. A skip changed nothing; a failure names what to fix.
Was this article helpful?