Batch Payment Run
The payment run is AP's weekly ritual: decide what to pay, pay it all, prove it happened. This article is the practical playbook for running it well in REDA Financials — what to check before you start, how to decide what makes the run, and how to verify the outcome. (The click-by-click wizard is in Creating a Payment Batch.)
Access you'll need. Creating and posting 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 create or post.
Before the run: a five-minute checklist
- Post what should be paid. Only posted invoices enter a run — sweep the Draft and Pending Approval list views first.
- Apply vendor memos. Spend available credit before spending cash — check the Vendor Memos (Unapplied) list view.
- Scan the aging. The AP aging tells you what's due, what's overdue, and what can wait.
- Know your cash. The run's total leaves one bank account on one date — make sure it can.
- Check stock, for check runs. Enough check numbers left on the bank account? The batch assigns them automatically and stops when the stock runs out.
Inside the wizard: the decisions that matter
The wizard has three steps (the click-by-click version is in Creating a Payment Batch); what follows is the judgment each step asks of you.
| Step | What the system does | What you decide |
|---|---|---|
| 1 — Select | Lists every outstanding posted invoice, filterable by entity, vendor and due date | Which bills make the run. Ticking is a payment decision — everything ticked will be paid, posted, applied, in one pass |
| 2 — Review | Groups the selection into proposed payments — one per vendor (or per vendor-and-dimension combination), and suggests early-payment discounts for invoices still inside their discount window | The grouping, every amount (override for partial payments), and every suggested discount — accept, adjust or clear each one |
| 3 — Create | Creates the batch: every payment born posted, check numbers assigned for check runs, applications auto-created, and a completion report of what succeeded and what didn't | The batch's payment date, bank account and payment method — one of each for the whole run. The bank account pre-fills from the entity's Default Bank Account – Expenses (falling back to Default Bank Account when unset); change it if this run pays from another account |
Meridian's June run (batch MCDB001001) is the shape to copy: three bills ticked in step 1 — CityClean's May bill and Hudson Elevator's May and June bills — grouped in step 2 into two vendor payments, CityClean $2,200 and Hudson $1,900. Step 3 stamped the run June 2026 payment run, ACH, from the operating account: one batch, two payments, $4,100, every invoice settled and every application written, in one confirmation.
Deciding what makes the run
| Strategy | How, in the wizard |
|---|---|
| Everything due by date X | Filter step 1 by due date — the classic weekly run. |
| Catch every discount | Include invoices whose discount window closes before your next run; the wizard suggests the discount amounts itself. |
| Vendor-by-vendor | Filter by vendor for negotiated settlements or on-hold suppliers. |
| Partial payments | Override any proposed amount in step 2 — the invoice stays open for the remainder. |
The discount pass, done right
Step 2's suggested discounts are the run's quiet money-maker. For each selected invoice still inside its payment term's discount window, the wizard proposes the discount: pay less cash, clear the bill in full, and the difference lands in your Purchase Discounts account as income. A $2,000 bill on 2/10 Net 30 pays out at $1,960 with $40 earned — small per invoice, meaningful per year (the arithmetic — roughly a 36% annualized return — is in Settlement Discounts & Terms). Two habits keep it honest:
- Time runs to the windows, not the calendar. If your only run is Friday and a discount window closes Thursday, you'll miss it every time — include invoices whose window closes before your next run, even if their net due date is weeks away.
- Never keep a suggestion you're not entitled to. The suggestions respect the window at the moment of the run; if you postpone the batch, re-check them rather than carrying stale discounts into a late payment.
After the run: verify in three looks
- The completion report — payments created, applications made, failures with reasons. Handle failures with a follow-up run.
- The batch record — totals and count match what you intended; the Cash Disbursements tab lists each payment for spot checks (check numbers, remittance PDFs).
- The aging refresh — the paid invoices drop out of the open buckets immediately.
What the run leaves behind
| Record | What it holds | Where to look |
|---|---|---|
| The batch | The run's identity — reference, date, bank, method, Total Amount, Record Count | The Cash Disbursement Batch record; its Audit Trail logs every status change |
| The payments | One posted Cash Disbursement per vendor (or vendor-and-dimension group), check numbers where assigned | The batch's Cash Disbursements tab |
| The applications | Which slice of which payment settled which invoice — with any discount taken | Each payment's Applications tab; mirrored on each invoice |
| The ledger entries | Cash out, payables cleared, discounts earned | Each payment's Accounting Transactions list |
| The completion report | Created, applied, failed — with the reason per failure | Shown at the end of step 3; act on it immediately |
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Running before posting the week's invoices | Draft and pending-approval bills are invisible to step 1 — they miss the run and age another week | Sweep the Draft and Pending Approval list views first, post what's ready |
| Paying cash while memo credit sits unspent | The run pays balances the credit could have covered | Apply vendor memos the day before — the run then sees only the true net balances |
| Treating step 2 as a formality | Everything you confirm is posted and applied seconds later — there is no staging area to catch it in | Review grouping, amounts and discounts as the final approval it is |
| Ignoring the completion report's failures | Those vendors simply don't get paid — and nobody notices until the calls start | Read the report while the run is fresh; fix causes; follow-up batch for the remainder |
| One giant run across purposes | A single batch mixing rent, construction draws and utilities is hard to review and hard to explain | Smaller, purposeful runs — they cost nothing extra and each batch record tells one story |
A rhythm that works
Meridian runs payments every Friday: memos applied Thursday, aging reviewed Friday morning, one ACH batch per entity before noon, check batch only when a vendor insists on paper. Whatever your cadence, the goal is the same — every payment decision made once, in one place, with one record of it.
Where to go next
- Creating a Payment Batch — the wizard walkthrough.
- Batch Posting & Voiding — when a whole run must be cancelled.
- AP Aging Reports & Snapshots — the run's navigation chart.
Frequently asked questions
No — a batch has one bank account, one date, one payment method. Two accounts means two batches, which keeps each batch reconcilable against its own bank statement.
Runs are per entity — each company pays its own bills from its own bank. Run them back-to-back; each gets its own clean batch record.
If the payment hasn't actually gone out (checks unprinted, ACH file not transmitted), void that single payment and issue a corrected one — or void the whole batch and rerun if the run itself was wrong. See Batch Posting & Voiding.
At its reduced balance due — the memo already settled part of it. That's exactly why memos go first: the run proposes only the net cash actually owed.
Yes — override the proposed amount in step 2. The payment applies for what you set, and the invoice stays open (and keeps aging) for the remainder. Typical for construction draws and disputed portions.
Dimension grouping: when payments are grouped per vendor-and-dimension combination, bills carrying different cost dimensions become separate payments so each payment's dimensions stay clean. Prefer one payment per vendor? Turn the dimension option off in step 2.
Was this article helpful?