Bulk Status Updates
The same mass-action serves every document type in REDA Financials: select records in a list view, click Bulk Status Update, pick the target status, and each record is processed through its full normal rules — posted, reopened or voided en masse, with a per-record result report. It's automation's honest cousin: fast hands, no shortcuts.
Access you'll need. Bulk Status Update is not a separate permission — it respects each document's normal access. You can bulk-change only records you can already post/void individually: Accounts Payable v2 for POs/PIs/disbursements, Accounts Receivable v2 for sales invoices/receipts, Accounting Admin v2 or Accounting Controller v2 for journals and other core records; Read Only v2 cannot change any.
Where it works
Journal entries, sales invoices, purchase invoices, cash receipts, cash disbursements, purchase orders, asset ledger entries — the button lives on their list views. The two big rhythms it serves:
- Month-end posting sweeps — every reviewed draft posted in one run (the journal-entries walkthrough shows it end-to-end).
- Cleanups — a batch of erroneous drafts voided, a mis-posted set reopened.
The three behaviors to remember
- No guards bypassed: each record passes its full posting/void validation — an unbalanced journal or closed-period invoice fails individually with its exact message.
- Per-record isolation: failures never poison the batch — successes commit, failures report. 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 result table is the deliverable: read it, fix the fails, re-run on the subset.
Running one, start to finish
Select in the list view
Filter the list to exactly the set you mean — "this month's reviewed draft journals", "the import batch from Tuesday" — and tick the records. The selection is the scope; nothing outside it is touched.
Pick the target status
Click Bulk Status Update and choose where these records should end up — Posted for a month-end sweep, back to Draft for a reopen, Void for a cleanup.
Read the result table
Every record reports individually: moved, skipped (already at the target status), or failed with the full error message. The result table is the deliverable — work it like a checklist.
The three outcomes, per record
| Outcome | What happened | What you do |
|---|---|---|
| Updated | The record passed its full validation and moved to the target status — a bulk-posted invoice is posted exactly as if someone opened it and clicked Post | Nothing; it's done, and the accounting happened |
| Skipped | The record was already at the target status — skips are not failures | Nothing; re-running a sweep is harmless by design |
| Failed | A rule said no — the same message you'd see one-at-a-time (a closed period, an unbalanced journal, a missing setup), listed in full at the end | Fix the cause, re-select the failed subset, run again |
Meridian's month-end sweep
Last day of June, Meridian Properties Group's US books: 38 reviewed draft journal entries need posting. The accountant filters the journal list to June drafts, selects all, runs Bulk Status Update → Posted. The result table comes back: 36 updated, 1 skipped (someone posted it by hand that morning), 1 failed — the error names an unbalanced entry. She opens that journal, fixes the missing credit line, re-runs on just that record, and month-end posting is done in minutes — with the same validation trail as 38 individual posts, because that's literally what happened.
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Selecting by eyeball instead of by filter | A stray record from another period rides along into the sweep | Build the filter first (period, status, entity), then select — the list view is your scope control |
| Closing the result table without reading it | Failures are silent afterwards — the unposted stragglers surface weeks later as reconciliation gaps | Treat the result table as the deliverable: every Failed row gets fixed or explained before you move on |
| Expecting bulk to push through a validation error | It never will — no guard is bypassed, by design; the same record fails the same way at any volume | Fix the underlying cause (open the period, balance the journal), then re-run |
| Using bulk void as an undo for one mistake | Mass actions deserve mass intent — a one-record problem doesn't need a batch tool | Open the record and act on it directly; keep bulk for genuinely bulk work |
Where to go next
- Bulk Updates Overview — the cross-module reference.
- Bulk Status Updates (Journal Entries) — the worked example.
- Operations Scheduler — the scheduled counterpart.
Frequently asked questions
No — it is posting one by one, at speed. Every record runs its full normal rules and writes its normal accounting; the only difference is who clicks. That's why the results read per record, not per batch.
They're skipped, not failed — the built-in help says it plainly: "Records already at the target status are skipped (not failed)." Re-running a sweep over the same list is deliberately harmless.
No. Failures are isolated per record: the failed one is rolled back completely, the successes stand. Fix the failure's cause and re-run on just that subset.
Where the document's own rules allow reopening, yes — the bulk tool moves records to whatever target status the record could reach individually. Anything the single-record rules forbid (a reconciled receipt, a closed period) fails with the same message it would give you one-at-a-time.
The same people who could make those changes individually — the action grants no extra power. If your permission set can't post a purchase invoice, it can't bulk-post one either.
Was this article helpful?