Payment Run

Payment Run is the batch process of selecting, reviewing, and releasing approved payments to many vendors at once, usually on a weekly or biweekly schedule to manage cash flow and processing effort. The run is also the fraud control point: a changed supplier bank account, a new payee and a duplicate invoice all have to be caught before release, not after.

Category: Accounts Payable Automation SoftwareBest Accounts Payable Automation Software

The Thursday payment run processed $2.1M across 140 vendors. On Friday morning, someone noticed that one payment had gone to an old bank account the vendor had flagged as inactive three weeks earlier. The bank account update hadn't been processed before the run, so the payment went out. Getting it back took two weeks and a bank recall request. A payment run is the batch process that selects a set of approved vendor invoices for payment, schedules them, and submits them to the bank or payment processor for release. It is the last step in the AP workflow. By this point invoices have been captured, validated, matched, coded, and approved, and the payment run turns that approved liability into outbound cash. Runs usually follow a set schedule (weekly, twice weekly, or daily in some operations) and pick up every invoice due within the run period. The selection logic decides what goes in: invoices that are approved, whose due date falls within the payment window, and that aren't on hold. Getting that logic right determines whether you capture early payment discounts, whether you pay on time and avoid late fees, and whether invoices that should be held for disputes, vendor issues, or bank account changes stay out. The payment run is where errors that built up earlier in the AP workflow become irreversible.

How payment runs work

A payment run has five steps: selection, review, approval, release, and reconciliation. Selection pulls from the approved invoice queue using the configured criteria, such as due date range, payment method, vendor group, or a specific invoice list. Review is the pre-payment check, where someone goes through the payment list before submission to catch errors, duplicates, or invoices that don't belong in this run. Approval is the authorization to release; depending on your controls, runs above a certain total value may need a second approver. Release sends the payment file to the bank as an ACH batch, wire instructions, or a check print file. Reconciliation records the payments in the AP system and matches them to the bank clearing entries. Most failures happen in the gaps between steps. A vendor bank account change requested on Monday and not processed until the following week sits as a pending update while the Thursday run pays the old account. An invoice placed on hold for a dispute and later approved, without anyone removing the hold exclusion, may be left out of the run. A duplicate invoice that entered the system after the approval cutoff can slip into the selection batch if the duplicate check runs at capture rather than at payment release. The review step before release is the last chance to catch these. Where teams treat it as a formality, the errors go straight to the bank.

Payment selection logic, ACH vs check vs wire timing

Payment selection logic has to exclude invoices that should not be paid in a given run: invoices on payment hold, invoices for vendors with incomplete or recently changed banking details, disputed invoices, and invoices whose early payment discount window hasn't arrived yet but whose net due date is in the future. Most AP systems offer selection filters, but someone has to configure them correctly and revisit them when vendor or invoice status changes. ACH payments have a processing lead time, typically one to two business days, so an ACH run released on Thursday will settle in the vendor's account on Monday or Tuesday. Build that into the schedule: an invoice due Friday has to be in a run released no later than Wednesday or Thursday, depending on your bank's ACH cutoff. Wires have earlier same-day cutoffs, typically 2 to 4 PM Eastern, and may settle the same day or the next. Check runs need lead time for printing, mailing, and postal delivery. When a run mixes payment methods, the timing differs for each, so a run with ACH, checks, and wires needs separate scheduling logic for each one. Bank account updates that arrive after a run is selected but before it is released create a sequencing problem. The new banking details are in the system, but the run was selected against the old state. Whether the run picks up the update depends on when selection was finalized relative to when the update was processed. You can close that gap by adding a vendor master review to the payment run approval step.

How platforms handle it

AP automation platforms generate a payment run proposal before release: a list of the invoices selected for payment, with vendor names, amounts, payment methods, and total run value. At minimum, the pre-payment review should cover: a check for duplicate payments within the run and against recently released runs, a look at any vendor whose bank account details changed in the past 30 days, confirmation that every invoice in the run has completed the approval workflow with no approvals outstanding, and a comparison of total run value against expected payment volume for the period. Platforms that surface these checks automatically, by flagging vendor master changes since the last run, highlighting likely duplicates, and showing approval status, make the review faster and more reliable. Platforms that produce a flat payment list with no exception flags leave the reviewer to do these checks by hand, which is slow and error-prone at scale. For large runs, a second approver on the release step is a compensating control that catches what the primary reviewer missed. The second approver should not be the person who prepared the run, and should review the payment list independently instead of confirming the first approver's judgment. For very large single payments, such as wires above a material threshold, some organizations require the CFO or controller to release the wire personally before it goes to the bank.

Questions to ask

Does our payment run approval step include a review of vendor master changes since the previous run, specifically bank account updates?
Do we run duplicate payment checks at payment run release as well as at invoice capture, and do they compare the current run against recently released runs?
Is there a second approver required before a payment run above a certain total value is released?
Does our payment selection logic correctly exclude invoices on hold, invoices for vendors with pending bank account changes, and invoices in dispute?
Do we have documented run cutoff times for ACH, wire, and check payments that account for bank processing lead times and settlement timing?
When a payment goes out in error, to the wrong account or for the wrong amount, what is our recall or recovery process, and how quickly can we start it?

Common mistakes

The most consequential payment run control gap is skipping a pre-payment review of recent vendor master changes. Any vendor bank account change processed after the previous run and before the current run's review should be flagged for explicit confirmation before release. That check catches fraudulent changes, where a social engineering attack got an account switched mid-cycle, as well as legitimate changes that were entered incorrectly. A few minutes spent on recent vendor master changes before each run is the last control between a bank-routing error and a two-week recall process. Releasing large batches without a second approver removes a check that has historically caught errors. The second approver reviews the payment list independently and catches cases where the primary reviewer missed a duplicate, approved a wrong amount, or included an invoice that should have been held. The time that costs is small next to the cost of recovering a misdirected payment. Organizations that drop the second approval to save time often reinstate it after a material payment error.

Comparing AP automation

AP tools separate on what happens to the exceptions: the invoices that do not match a PO, arrive without one, or need a second approver. Once payment run is settled as a requirement, read the Accounts Payable Automation Software category guide for how the market splits, then weigh the Stampli profile against the Tipalti profile on that requirement rather than on the feature list. Our Tipalti pricing breakdown records what the vendor publishes and what is quote-based. The BILL against Stampli comparison sets two of them side by side on the same criteria. Before you book demos, put your own numbers through the AP automation savings calculator so the business case is written down before a vendor writes it for you.

Payment Run questions

How is a payment run different from an individual payment?

A payment run is a batch process that groups multiple approved invoices into a single submission to the bank. Individual payments, typically wires for large or urgent amounts, are initiated and released as standalone transactions outside the run cycle. Runs are efficient for routine AP volume because the work of preparation, approval, and bank submission is spread across many invoices. Individual payments are used when urgency, size, or a vendor's payment instructions call for direct handling. Most AP systems support both, with different approval and release controls for each. Large wire payments usually carry stricter controls than batch ACH payments.

What should we do if we discover a payment was made to the wrong bank account after it has cleared?

A payment to the wrong bank account that has already cleared needs a bank recall or reversal request. For ACH payments, the originating bank can submit a return request to the receiving bank within a defined window, typically five business days for unauthorized transactions. The receiving bank does not have to comply if the funds have been withdrawn, though many do cooperate. Wire recalls are more involved: the originating bank contacts the correspondent bank chain and the receiving bank to request the return. Wire recalls are not guaranteed and depend on the receiving bank's cooperation and whether the funds are still there. At the same time, confirm with the intended vendor that they did not receive the payment, and ask the holder of the account that wrongly received the funds (if known) to return them. Document every step. If the payment was misdirected because of a fraudulent bank account change, report it to your bank's fraud team immediately, since they have more tools and relationships to help with recovery.

How frequently should payment runs be scheduled, and what factors determine the right cadence?

Payment run cadence depends on invoice volume, vendor terms, and how much early payment discount you want to capture. Organizations with high invoice volume and large early payment discount programs do better with daily runs, because the extra frequency keeps invoices inside discount windows and makes payment scheduling more responsive. Organizations with mostly net 30 terms and lower volume usually run weekly, with an ad hoc process for urgent payments outside the cycle. Twice-weekly runs, Monday and Thursday for example, are a middle ground that covers most discount windows without the effort of preparing a run every day. The practical limit is the pre-payment review and approval: a daily run means that review and approval happen daily, so the AP team needs the capacity for it.

ACH Payment, AP Aging Report, and Approval Workflow come up in the same workflow as payment run, and the rest of the AP automation cluster is indexed in the finance operations glossary.