Supported Objects
The Bulk Status Update button lives on the list views of every major document in REDA Financials. This reference lists them, with the per-document details that matter — which statuses you can target, whether a void reason is recorded, and the type-specific rules that still apply record by record.
Access you'll need. No special permission — your standard access to each object is what counts: Accounts Payable v2 or Accounting Admin v2 for Purchase Invoices, Purchase Orders, Cash Disbursements and Allocation Batches; Accounts Receivable v2 or Accounting Admin v2 for Sales Invoices and Cash Receipts; Accounting Admin v2 or Accounting Controller v2 for Journal Entries and Asset Ledger entries. The Read Only v2 set can view but not change status.
The reference
| Document | Statuses you can target | Void reason recorded? | Type rules that still apply per record |
|---|---|---|---|
| Sales Invoices (incl. Receipts and Credit Memos) | Draft · Posted · Void | Yes — plus void date | Credit memos must total negative; approval gate applies |
| Purchase Invoices (incl. Expense and Vendor Memos) | Draft · Posted · Void | Yes — plus void date | Expense type needs payment method + bank; vendor memos must total negative |
| Cash Receipts | Per the receipt lifecycle | — | Reference required; posting creates the cash entries |
| Cash Disbursements | Draft · Posted · Void | — | Check payments consume check numbers at posting; voids never return them |
| Journal Entries | Draft · Posted · Void | — | Lines must balance; per-entity balance on intercompany entries |
| Purchase Orders | Draft · Posted · Void | — | Budget check runs at posting; void releases commitment |
| PI Allocation Batches | Draft · Posted · Void | — | Posting builds the allocation JE; reopening removes it |
| Asset Ledger (depreciation entries) | Scheduled · Posted (per entry lifecycle) | — | Posting writes the depreciation to the ledger — normally the scheduler’s job; bulk is your manual override |
Where the button lives — and what it opens
On every supported object the entry point is identical: open a list view, tick the rows you want, and the Bulk Status Update button in the list header opens the same screen everywhere — a summary of the selection by current status ("12 selected: 8 Draft, 3 Posted, 1 Void"), a Target Status picker offering that object’s own statuses, the Void Reason box when the target is Void on documents that record one, and Apply. The result screen is equally uniform: "{X} updated · {Y} already at target · {Z} failed", three tiles, and a failures table quoting each record’s exact error. Learn it once on invoices and you know it on journal entries, orders, and asset entries too.
The per-record rules, in each object’s own words
"Type rules still apply per record" is abstract until you see the messages. A sampler of the exact refusals each object can send back in a bulk run’s failures table:
| Object | The message | What it means |
|---|---|---|
| Sales Invoices | "Sales Invoice must have at least one line before posting." | An empty draft can’t post — in bulk or alone. |
| Sales Invoices | "Cannot void a Sales Invoice with applied payments or credits. Reverse the applications first." | Voids respect dependencies; unwind applications, then re-run. |
| Purchase Invoices | "Expense invoices require a Payment Method to create the Cash Disbursement." | An Expense invoice posts its own payment — it must know how the money moved. |
| Purchase Invoices | "Credit Memo/Vendor Memo must have a negative total." | A memo must be shaped like a memo before it posts. |
| Journal Entries | "Transaction does not balance: Debits … != Credits …." | The fundamental rule holds at any scale. |
| Journal Entries | "Intercompany posting is out of balance for Entity …: Debits … != Credits …." | Cross-entity entries must balance within each entity, not just overall. |
| Purchase Orders | "Purchase Order posting failed: Budget exceeded for GL Account …: Available …, Requested …" | Budget enforcement runs per order at posting time. |
| Cash Receipts | "Bank Account is required for Receipt type Cash Receipts." | A receipt is a bank deposit — it needs its bank. |
| Asset Ledger | "Cannot post this Asset Ledger entry - Amount must be greater than zero." | A zero or negative charge isn’t a posting. |
| Asset Ledger | "The Debit GL Account and Credit GL Account must be different." | Each entry is a two-account movement — same account both sides moves nothing. |
What’s deliberately not here
- Budgets, bank reconciliations, aging snapshots — their lifecycles are individually meaningful; bulk-flipping them would be a control smell, not a convenience.
- Recurring templates — activate and pause them individually; each schedule is a decision.
- Master data (accounts, products, entities) — no status lifecycle to update; use standard list editing for field changes.
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Running a "post everything" pass on an unfiltered invoice view | Sales Invoice views include credit memos; Purchase Invoice views include vendor and expense memos — a run meant for invoices sweeps up documents of a different nature | Filter by type first (the shipped type views exist for exactly this), then select |
| Expecting the void reason box on every object | Only sales and purchase invoices (with their memo types) store one — on cash documents and journals the context evaporates | For objects without a stored reason, add a note on the records when the why isn’t obvious |
| Bulk-posting Asset Ledger entries that aren’t due yet | Future-dated depreciation lands in the ledger early, misstating the current period | Leave scheduled entries to the Depreciation Batch; bulk-post only what you deliberately filtered as due |
| Treating a missing button as a bug | Time lost chasing an "issue" that is the design — unsupported objects simply don’t carry it | Check this article’s reference table first; for supported objects, check your selection and the view’s layout |
| Using bulk update where individual judgment is the point | Reconciliations, snapshots and templates have individually meaningful lifecycles — mass-flipping them isn’t efficiency, it’s a control gap | Work those records one at a time; that friction is intentional |
Where to go next
- Bulk Updates Overview — how the tool works.
- Bulk Posting · Bulk Voiding — the two big use cases.
Frequently asked questions
Check the object (only the documents above carry it) and your selection — the button acts on ticked rows. If it’s missing where the table says it should exist, your administrator may have customized the list view layout.
No — it’s a status tool (plus the void reason that belongs with a void). For editing other fields en masse, use standard list-view inline editing, which respects the same posted-record locks.
The picker shows that object’s own lifecycle — invoices offer Draft, Posted and Void; Asset Ledger entries move between Scheduled and Posted. The tool changes status; it never invents statuses an object doesn’t have.
The mechanics are identical everywhere: each record runs its full normal lifecycle logic independently, already-at-target records are skipped untouched, and failures come back with verbatim reasons. What differs is each object’s own rules — the ones in the tables above.
No special permission anywhere — your standard access to the object and its records is what counts. If you can make the change on one record, you can make it on fifty; if you can’t, every one of them refuses with the same message.
It’s the design: "Each record is processed independently; partial success is possible." Nothing is half-done — each record either completed its full change or was left exactly as it was, with the reason reported. Fix the causes and re-run on the failures.
Was this article helpful?