Payment run: definition and how it works in accounts payable

What it means

A Payment run is a scheduled batch, not a single payment. Accounts payable selects invoices that are due, confirms the payment method on the vendor record, applies the required approvals and releases the payments by check, ACH, wire or card. The run is the point where a list of approved invoices becomes a set of payment instructions.

The selection normally follows due date and payment method, but the exact order and rules vary by company, country and contract. Some teams run checks separately from ACH or wire payments; others release all methods from one batch. An urgent or exception payment may be handled outside the scheduled cycle, again depending on policy.

The term appears under several names: check run, payment batch and pay run. Whatever the name, the control idea is the same. A Payment run fixes which invoices are in scope before money leaves, so it is also the best place to stop a duplicate payment before it happens. Related controls such as positive pay, remittance advice and ACH payment sit around the run and have their own pages.

How it works in practice

In practice, AP starts from the invoices that are due and payable. Clerks clear holds, disputed items and missing approvals before the run is built. The vendor record must be active and must carry the correct payment method and remittance route. The run is then approved under the authority rules that apply to the company and contract.

At release, compare the run to the approved selection. The count of invoices, the total amount and the payment methods should agree. For checks, the check numbers and amounts should match the run list. For ACH and wire, the bank file and the acknowledgments should match the released items. For card, the batch total and the card transactions should agree. A difference is a reason to stop, not to explain away.

After release, AP follows each item to acceptance or rejection. Rejected items should be corrected and handled under a controlled exception process, not mixed back into a new run without a check against the original. The Payment run record should show what was selected, what was approved, what was released and what was rejected. That trail is what makes the next run safer.

Where it goes wrong

The most common failure is re-sending a failed or partly failed run. Suppose an ACH file is rejected for some items and accepted for others. AP corrects the vendor record and sends the whole run again. The items that were already accepted can be paid twice. Before any re-release, compare the bank acknowledgments with the original run list line by line and exclude every item that settled.

Another failure is an exception payment that never leaves the run. An invoice is pulled for a wire because it is urgent, but the check run still includes it because the removal was not carried through to release. The vendor receives both. The same happens when a check is reprinted after a partial check run without voiding the original. Freeze the final selection, document every exception and reconcile the released file to the frozen list.

Duplicate vendor records, changed bank details and manual checks outside the run create the same result. An invoice paid by manual check can re-enter the next Payment run if the payment is not recorded against the invoice. A failed payment that is not voided can return in a later run. Approval shortcuts make all of these harder to see. Approval limits, void rules and bank cut-off rules differ by country, company and contract, so apply your own policy rather than a generic rule.

What to check

Before release, check that every selected invoice is due and approved, that holds and disputes are cleared, and that the vendor record is active with the intended payment method. Confirm bank details through your established verification process, not from an email alone. Run a duplicate check just before release. A duplicate check just before release catches more than a yearly review.

Compare the count and total of the run with the approved selection, then look for items paid since the last run, items from a failed or partly failed prior run, and manual or off-cycle payments. Check whether any credit or adjustment should have reduced the payment. If the run is split by method, reconcile each method to its own release file or check list.

After release, reconcile the acknowledgments to the Payment run, clear positive pay exceptions and send remittance advice. Record rejected items and keep them out of the next run until the cause is fixed. The exact checks vary by country, company and contract, but the principle does not: the run must reconcile to what was approved, released and settled.

Questions