Payment Run

Payment Run matters because finance software evaluations usually slow down when teams use the term loosely. This page is designed to make the meaning practical, connect it to real buying work, and show how the concept influences category research, shortlist decisions, and day-two operations.

Definition

The batch process of selecting, reviewing, and executing approved payments to multiple vendors at once — typically scheduled weekly or biweekly to optimize cash flow and processing efficiency.

Payment Run is usually more useful as an operating concept than as a buzzword. In real evaluations, the term helps teams explain what a tool should actually improve, what kind of control or visibility it needs to provide, and what the organization expects to be easier after rollout. That is why strong glossary pages do more than define the phrase in one line. They explain what changes when the term is treated seriously inside a software decision.

Why Payment Run is used

Teams use the term Payment Run because they need a shared language for evaluating technology without drifting into vague product marketing. Inside accounts payable automation software, the phrase usually appears when buyers are deciding what the platform should control, what information it should surface, and what kinds of operational burden it should remove. If the definition stays vague, the shortlist often becomes a list of tools that sound plausible without being mapped cleanly to the real workflow problem.

These concepts matter when teams are comparing how much manual AP work the platform can realistically remove.

How Payment Run shows up in software evaluations

Payment Run usually comes up when teams are asking the broader category questions behind accounts payable automation software software. Teams usually compare AP automation vendors on OCR quality, approval routing, ERP sync, payment orchestration, fraud controls, and how well the tool handles real invoice exceptions. Once the term is defined clearly, buyers can move from generic feature talk into more specific questions about fit, rollout effort, reporting quality, and ownership after implementation.

That is also why the term tends to reappear across product profiles. Tools like Tipalti, BILL, Stampli, and Airbase can all reference Payment Run, but the operational meaning may differ depending on deployment model, workflow depth, and how much administrative effort each platform shifts back onto the internal team. Defining the term first makes those vendor differences much easier to compare.

Example in practice

A practical example helps. If a team is comparing Tipalti, BILL, and Stampli and then opens Tipalti vs Airbase and Airbase vs BILL, the term Payment Run stops being abstract. It becomes part of the actual shortlist conversation: which product makes the workflow easier to operate, which one introduces more administrative effort, and which tradeoff is easier to support after rollout. That is usually where glossary language becomes useful. It gives the team a shared definition before vendor messaging starts stretching the term in different directions.

What buyers should ask about Payment Run

A useful glossary page should improve the questions your team asks next. Instead of just confirming that a vendor mentions Payment Run, the better move is to ask how the concept is implemented, what tradeoffs it introduces, and what evidence shows it will hold up after launch. That is usually where the difference appears between a feature claim and a workflow the team can actually rely on.

• How accurately does the platform capture and classify the invoices your team actually receives?
• Can approval routing reflect entity, department, amount, and policy complexity without brittle workarounds?
• How strong is the ERP sync once invoices, payments, and vendor updates all move through the workflow?
• What parts of the AP process still stay manual after implementation?

Common misunderstandings

One common mistake is treating Payment Run like a binary checkbox. In practice, the term usually sits on a spectrum. Two products can both claim support for it while creating very different rollout effort, administrative overhead, or reporting quality. Another mistake is assuming the phrase means the same thing across every category. Inside finance operations buying, terminology often carries category-specific assumptions that only become obvious when the team ties the definition back to the workflow it is trying to improve.

A second misunderstanding is assuming the term matters equally in every evaluation. Sometimes Payment Run is central to the buying decision. Other times it is supporting context that should not outweigh more important issues like deployment fit, pricing logic, ownership, or implementation burden. The right move is to define the term clearly and then decide how much weight it should carry in the final shortlist.

Related terms and next steps

If your team is researching Payment Run, it will usually benefit from opening related terms such as ACH Payment, AP Aging Report, Approval Workflow, and Duplicate Invoice Detection as well. That creates a fuller vocabulary around the workflow instead of isolating one phrase from the rest of the operating model.

From there, move into buyer guides like Payment Management System and What Is AP Automation? and then back into category pages, product profiles, and comparisons. That sequence keeps the glossary term connected to actual buying work instead of leaving it as isolated reference material.

Additional editorial notes

The Thursday payment run processed $2.1M across 140 vendors. On Friday morning, someone noticed one payment had gone to an old bank account that a vendor had flagged as inactive three weeks ago. The bank account update hadn't been processed before the run. The payment was sent. Getting it back took two weeks and a bank recall request. A payment run is the batch process through which a set of approved vendor invoices is selected for payment, scheduled, and submitted to the bank or payment processor for release. It is the final step in the AP workflow: invoices have been captured, validated, matched, coded, and approved — the payment run converts that approved liability into an outbound cash transfer. Payment runs are typically executed on a defined schedule — weekly, twice weekly, or in some operations, daily — and they process all invoices that are due within the run period. The selection logic determines which invoices are included: invoices that have been approved, invoices whose due date falls within the payment window, and invoices that aren't on hold. Getting the selection logic right matters because it determines whether early payment discounts are captured, whether payments are made on time to avoid late fees, and whether invoices that should be held — for disputes, vendor issues, or bank account changes — are excluded. The payment run is where errors that accumulated earlier in the AP workflow become irreversible.

How payment runs work — and where timing, sequencing, and data gaps create failure points

A payment run involves five steps: selection, review, approval, release, and reconciliation. Selection pulls from the approved invoice queue based on the configured criteria — due date range, payment method, vendor group, or specific invoice lists. Review is the pre-payment check: someone reviews the payment list before submission to catch errors, duplicates, or invoices that shouldn't be in this run. Approval is the authorization to release: depending on the organization's controls, this may require a second approver for runs above a certain total value. Release submits the payment file to the bank — 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. The failure points in this sequence are concentrated 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 executes against the old account. An invoice that was placed on hold for a dispute but was subsequently approved without removing the hold exclusion may be omitted from the run. A duplicate invoice that entered the system after approval cutoff may slip into the selection batch if the duplicate check runs at capture rather than at payment release. The review step — the pre-payment check before release — is the last opportunity to catch these failures. In organizations that treat the review as a formality, errors pass through to the bank.

Payment selection logic, ACH vs check vs wire timing, and what happens when bank account updates don't precede the run

Payment selection logic must correctly exclude invoices that should not be paid in a given run: invoices on payment hold, invoices for vendors with incomplete or recently changed banking information, invoices that are disputed, and invoices whose early payment discount window hasn't arrived yet but whose net due date is in the future. Most AP systems provide selection filters, but those filters must be configured correctly and reviewed when vendor or invoice status changes. ACH payments have a processing lead time — typically one to two business days — meaning that an ACH payment run released on Thursday will settle in the vendor's account on Monday or Tuesday. This timing must be factored into run scheduling: an invoice due on Friday must be included in a run released no later than Wednesday or Thursday, depending on the bank's ACH cutoff. Wire payments have earlier same-day cutoffs — typically 2 to 4 PM Eastern — and may settle same day or next day. Check runs have lead time for printing, mailing, and postal delivery. When payment method is mixed within a run, the timing implications differ by method. A payment run that includes ACH, checks, and wires requires different scheduling logic for each. Bank account updates that arrive after a run has been selected but before it is released create a sequencing problem. The updated banking information is in the system, but the run was selected against the prior state. Whether the run reflects the update depends on when selection was finalized relative to when the update was processed — a timing gap that can be closed by running a pre-payment vendor master review as part of the payment run approval step.

How AP platforms handle payment run setup and approval — what the pre-payment review step should include

AP platforms generate a payment run proposal — a list of invoices selected for payment, with vendor names, amounts, payment methods, and total run value — before the run is released. The pre-payment review should include at minimum: a check for duplicate payments within the run and against recently released runs, a review of any vendors whose bank account information changed within the past 30 days, confirmation that all invoices in the run have completed the approval workflow and no approvals are outstanding, and a review of total run value against expected payment volume for the period. Platforms that surface these checks automatically — flagging vendor master changes since the last run, highlighting invoices approaching duplicate status, displaying approval completion status — make the pre-payment review faster and more reliable. Platforms that generate a flat payment list without exception flagging require the reviewer to perform these checks manually, which is time-consuming and error-prone at scale. For large payment runs, a second approver on the release step is a compensating control that catches errors the primary reviewer may have missed. The second approver should not be the same person who prepared the run, and they should review the payment list independently rather than simply confirming the first approver's judgment. For very large single payments — wires above a material threshold — some organizations require the CFO or controller to explicitly release the wire before the bank submission.

Questions to ask to assess the controls around your payment run process

• Does our payment run approval step include a review of vendor master changes since the previous run — specifically bank account updates?
• Are duplicate payment checks performed at the time of payment run release, not just at invoice capture — and do they cross-reference 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 is sent in error — to a wrong account or for a wrong amount — what is our recall or recovery process, and how quickly can we initiate it?

Payment run mistakes that result in misdirected payments and difficult recoveries

Not running a pre-payment review against recent vendor master changes is the most consequential payment run control gap. Vendor bank account changes that are processed after the previous payment run but before the review for the current run should be flagged for explicit confirmation before the run is released. This check catches both fraudulent bank account changes — where a social engineering attack successfully changed an account mid-cycle — and legitimate changes that may have been processed incorrectly. The few minutes spent reviewing recent vendor master changes before each payment run is the final control that catches bank-routing failures before they become two-week recall processes. Releasing a payment run without a second approver on large batches removes a check that has historically caught errors. The second approver provides an independent review of the payment list and catches cases where the primary reviewer missed a duplicate, approved an incorrect amount, or included an invoice that should have been held. The cost of the second approver's time is low relative to the recovery cost of a misdirected payment. Organizations that eliminate the second approval step for efficiency frequently reinstate it after a material payment error demonstrates the value of the control.