Bulk Posting
Forty draft invoices at month-end don’t need forty Post clicks. This playbook posts them in one pass — and shows you how to handle the two or three that refuse.
Access you'll need. Posting in bulk needs the same permission set as posting 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 post.
Before the run
- Work from a Draft view. The shipped Draft list views show exactly what’s waiting; add an entity filter if you close company by company.
- Sweep approvals first. Posting respects the approval gate — documents pending approval will fail with exactly that reason. The Pending Approval view tells you what to chase before the run, not after.
- Spot-check a few drafts. Sixty seconds scanning dates and totals catches the misfiled document before it posts into your ledger — bulk speed cuts both ways.
The run
Select and launch
Tick the drafts (the header checkbox selects the page), click Bulk Status Update, confirm the summary reads like you expect — "14 selected: 14 Draft" — and set Target Status to Posted.
Apply
Each document posts through its complete, normal posting logic — validations, accounting entries, aging, the lot. Nothing about bulk skips a rule.
Read the result like a work list
"12 updated · 0 already at target · 2 failed" — and the two failures listed with names and full reasons. That failures table is your remaining to-do list.
Reading the result screen
The result screen leads with the headline — "{X} updated · {Y} already at target · {Z} failed" — over three tiles: Updated, Already at Target, Failed. Below them, the failures table lists each refused record as a link with its full error message, duplicate messages collapsed so one systemic cause (a closed period, say) reads as one line however many records it caught. The screen’s help text is the design in a sentence: "Each record is processed independently; partial success is possible."
A worked month-end at Meridian
Meridian Properties Group’s AP accountant opens the Draft Purchase Invoices view on the last business day: fourteen drafts. She ticks all fourteen, clicks Bulk Status Update, confirms the summary — "14 selected: 14 Draft" — sets Target Status to Posted, and applies. The result: "12 updated · 0 already at target · 2 failed", with the two failures listed:
| Failed record | The message | Her fix |
|---|---|---|
| A contractor bill still in the approval queue | "This document requires approval before posting. Approval Status must be Approved or Not Required." | Pings the approver; re-runs on that one invoice after approval lands. |
| An invoice keyed with last month’s date | "Invoice Date must fall within the selected Accounting Period." | Opens the record, corrects the date (the period re-derives), re-runs. |
Twelve invoices posted in one pass, two fixed within the hour — and if she accidentally re-ran the original fourteen, the twelve already posted would simply report already at target, untouched. That skip behavior is what makes the fix-and-re-run loop safe.
The refusals, verbatim
Bulk posting quotes the same messages the Post button gives you singly. The ones month-end runs meet most, across document types:
| The message | What it means / what to do |
|---|---|
| "This document requires approval before posting. Approval Status must be Approved or Not Required." | The approval gate stands in bulk — sweep the Pending Approval view before the run, not after. |
| "Invoice Date must fall within the selected Accounting Period." | Date and period disagree — fix the date, or clear the period so it re-derives. |
| "Transaction Date … is on or before the GL book closure date …. Reopen the books to post." | The books are closed through that date — post into an open stretch, or have an administrator adjust the closure. |
| "GL Account is inactive and cannot receive new postings. Select an active account or reactivate this one." | A line references a deactivated account — re-code it or reactivate the account, then re-run. |
| "Sales Invoice must have at least one line before posting." / "Total posting amount is zero. Add at least one non-zero line." | An empty or zero-value draft slipped into the selection — complete it or leave it out. |
| "Transaction does not balance: Debits … != Credits …." | A journal entry in the run doesn’t balance — bulk posting won’t bend the fundamental rule for speed. |
| "Expense invoices require a Payment Method to create the Cash Disbursement." | Type-specific completeness: an Expense invoice posts its own payment, so it needs to know how the money moved. |
| "Credit Memo/Vendor Memo must have a negative total." | A memo in the selection isn’t shaped like a memo — a credit must credit. |
| "Purchase Order posting failed: Budget exceeded for GL Account …: Available …, Requested …" | Budget enforcement runs per record at posting — reduce the order, or revisit the budget allocation. |
The usual suspects, and their fixes
| Failure message says… | Fix |
|---|---|
| Approval isn’t Approved / Not Required | Chase the approval, then re-run on that record. |
| Date outside the accounting period | Open the record; fix the date or the period. |
| An inactive GL account / product / entity | Reactivate or re-code the line, then re-run. |
| Type-specific requirements (an Expense invoice’s payment method, a memo’s negative total) | Complete the document as its type demands — the message names the gap. |
After fixing, select just the failed records and run again — the already-posted ones would simply be skipped, but a clean selection keeps your reports tidy.
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Running before sweeping approvals | Every pending-approval document fails with the same message — a predictable, avoidable failures list | Work the Pending Approval view first; post after the approvals land |
| Posting an unreviewed selection "because they’re all drafts" | Draft status means unposted, not correct — the mis-dated or mis-coded draft posts as happily as the good ones | Sixty seconds scanning dates and totals in the list view before ticking |
| One giant run across entities and months | The result report mixes unrelated failures, and re-running a fix means wading through everything again | Slice by entity or month — each run’s report then tells one story |
| Re-selecting the whole view after fixing failures | Harmless (posted records skip) but noisy — every report is padded with "already at target" rows | Select just the failed records for the re-run; the failures table names them |
| Treating a failure as the tool’s problem | The message is the document’s own posting validation — ignoring it means the document stays wrong, not just unposted | Read the reason, fix the record (or its period/approval), re-run |
Where to go next
- Bulk Updates Overview — the tool itself, with screenshots.
- Bulk Voiding — the cancellation counterpart.
- Month-End Close Checklist — bulk posting in its natural habitat.
Frequently asked questions
Each run works one list view, so one document type at a time — invoices in one pass, journal entries in another. The runs take seconds each; the separation keeps results readable.
Identical to posting one by one — same entries, same tax records, same links. Open any posted record’s Accounting Transactions to verify; you’ll find them exactly as usual.
The same as any wrongly posted document: reopen it to Draft (entries removed) or void it — individually, or via a bulk run back to Draft for a whole batch of regrets.
No — each record is processed independently, so one refusal never blocks the rest. The run always finishes and always reports: updated, already at target, failed, with every failure’s reason quoted.
Order doesn’t matter to the outcome: each document posts on its own merits, independent of the others in the run. If one document genuinely depends on another being posted first (rare), run them in two passes.
Normal postings — because that’s what they are. The Audit Log records each posting with who ran it and when; each document’s own history shows the status change. Forty postings by one person in one minute tells its own story.
Was this article helpful?