Payment Run in Accounts Payable

A payment run in accounts payable is a scheduled batch in which a company pays many approved vendor invoices at once, rather than paying each one individually as it arrives. It happens after invoices are captured, matched, coded, and approved, and it is where the money actually leaves the business. Most US finance teams run one weekly or twice monthly. Done well, it gets suppliers paid on time, captures early-payment discounts, and keeps cash flow predictable. Last updated July 2026.

Done sloppily, it produces duplicate payments, missed due dates, and angry vendors.

This guide explains what a payment run is, how the process works step by step, how often most US teams run one, the difference between a check run and an ACH run, and how clean invoice data makes the whole thing faster. It is written for AP clerks, AP managers, and controllers who own the pay cycle.

What is a payment run in accounts payable?

A payment run is a scheduled batch in which accounts payable pays a group of approved, due invoices together in a single processing cycle. Instead of cutting one check or sending one ACH transfer every time an invoice is approved, the team gathers all invoices that are ready, reviews them as a batch, and releases the payments at one defined point in time. The result is fewer, more controlled disbursements.

The word "run" comes from the batch nature of the task. Your accounting system or AP software selects every invoice that meets the criteria you set (approved, due within a date window, not on hold), proposes the total, and then executes the payments once a person signs off. Most mid-size companies run this weekly or bi-weekly rather than daily, which cuts processing cost and the chance of error.

How does a payment run work?

A payment run works by selecting approved invoices that are due, grouping them into a batch, reviewing the proposed total for errors, and then releasing the payments through checks or electronic transfers. The accounting system handles the mechanics, but a human reviews the proposal and authorizes the release. Each paid invoice is then marked as paid and posted to the general ledger so the outstanding AP balance is accurate.

The flow is deliberately sequential so that nothing gets paid twice and nothing approved gets missed. In practice it runs in this order.

1. Run the aging report and select invoices

The team pulls an accounts payable aging report to see what is due and when. From there they choose which approved invoices to include: everything due before the next run, plus anything carrying an early-payment discount worth capturing now. Invoices still in approval, in dispute, or on hold are left out.

2. Build the payment proposal (batch)

The selected invoices form the batch, often called a payment proposal. The system groups them by vendor so a supplier with five invoices receives one payment, not five. It calculates the total cash required, which lets the controller confirm the bank account can cover the run before anything goes out.

3. Review the batch for mismatches

Before release, someone reviews the proposal for duplicates, wrong amounts, vendors paid out of cycle, and any invoice that should not be there. This is the last checkpoint to catch a duplicate invoice payment or a fat-fingered amount, so it matters. Strong teams require a second set of eyes here.

4. Release the payments

Once approved, the batch is released: checks are printed and signed, or ACH and wire files are transmitted to the bank. Many teams require dual authorization, where a second person signs off before funds move, especially above a dollar threshold.

5. Confirm, post, and reconcile

Each invoice is marked paid, the payment posts to the general ledger, and remittance details go to vendors. Later, the payments are reconciled against the bank statement to confirm every disbursement cleared for the right amount. This closes the loop on the run.

What are the steps in the AP payment run process?

The AP payment run process has seven core steps: select due invoices from the aging report, build the batch or payment proposal, review it for mismatches and duplicates, obtain authorization, release the payments by check or ACH, post the payments to the ledger, and reconcile against the bank. The first three steps are about choosing what to pay, the last four about paying it and proving it was paid correctly.

Each step exists to protect against a specific failure. Selection prevents paying invoices that are not approved. Review prevents duplicates and errors. Authorization prevents fraud. Reconciliation proves the cash actually left the account as intended. Skipping any one of them is where most payment problems start.

How often should you run a payment run?

Most US businesses run a payment run weekly or bi-weekly, with the right frequency driven by invoice volume, vendor terms, and cash flow. A high-volume company might run twice a week to keep up; a small business with a handful of vendors may run once a month. Consolidating into fewer, scheduled runs reduces processing cost and gives fewer chances for confusion or duplicate payments.

The trade-off is timing. Run too rarely and you risk missing due dates or early-payment discount windows. Run too often and you spend more time and money cutting payments than you need to. A fixed cadence, say every other Wednesday, lets vendors know when to expect payment and lets you plan cash. Build the schedule around your largest vendors' terms so the run always lands before their due dates.

What is the difference between a payment run and a check run?

A check run is a payment run that pays specifically by printed check, while a payment run is the broader term covering all payment methods: checks, ACH transfers, wires, and virtual cards. Every check run is a payment run, but a payment run today usually includes mostly electronic payments rather than paper. The terms are often used interchangeably out of habit from the paper-check era.

The practical difference is mechanics. A check run involves printing, signing, stuffing, and mailing physical checks, which is slower and carries mail-fraud risk. An ACH or electronic run transmits a payment file to the bank and settles in a day or two with a clear audit trail. Many teams still run both: ACH for vendors set up for it, checks for the holdouts.

What is a payment proposal in a payment run?

A payment proposal is the draft list of invoices and amounts the system suggests paying in a given run, before anyone authorizes it. It shows each vendor, the invoices selected, the amount per vendor, and the grand total. The AP team reviews and edits this proposal, removing anything that should wait, before turning it into actual payments.

Think of the proposal as the dry run. Nothing has moved yet, so it is the safe place to catch problems: a vendor paid last week appearing again, an invoice missing its discount, an amount that looks wrong. Once the proposal is clean and authorized, the system converts it into the real payment batch and releases it.

How long does a payment run take?

A well-run payment run takes anywhere from under an hour to half a day of hands-on work, depending on volume and how much is automated. The mechanical selection and batching take minutes in modern software. The time sink is the human review: checking the proposal, chasing down questionable line items, and getting authorization. Settlement then adds a day or two for ACH or several days for mailed checks.

What stretches a run out is bad upstream data. If invoices were captured with wrong amounts or missing PO numbers, the review step turns into an investigation. Teams that capture clean data and resolve exceptions before the run spend far less time at the proposal stage, which is why the fastest pay cycles start at the point of data entry, not the point of payment.

Who approves a payment run?

A payment run is typically authorized by a controller, AP manager, treasurer, or CFO, depending on the dollar amount and company policy. Individual invoices are approved earlier by the budget owner who incurred the expense; the run itself is then released by a finance leader who confirms the batch total and that the cash is available. Larger amounts often require a second authorizer.

Good controls separate duties so the person who enters or processes invoices is not the same person who authorizes and releases payment. That separation, combined with dual sign-off above a threshold, is the single most effective guard against both honest errors and payment fraud in the run.

What can go wrong in a payment run?

The most common payment run problems are duplicate payments, paying the wrong amount, missing a due date or discount, paying an unapproved or disputed invoice, and sending funds to a fraudulent or outdated vendor bank account. Most of these trace back to two root causes: dirty invoice data going into the batch, and weak review or authorization controls before release.

A duplicate vendor record or an invoice keyed twice slips a second payment into the batch. A wrong amount captured at entry pays out wrong. A missing approval lets something through that should have been held. The fix is upstream: accurate capture, a clean vendor master, exception resolution before the run, and a disciplined two-person review of the proposal. The payment run only pays out what the rest of the AP cycle hands it.

How does invoice data extraction speed up the payment run?

Accurate invoice data extraction speeds up the payment run by handing the batch clean, validated amounts and vendor details, so the review step finds fewer problems to fix. When vendor, invoice number, date, due date, and totals are captured correctly the first time, duplicates are easier to catch, due dates are reliable, and the proposal needs less manual correction before release.

The payment run is the last step in a chain, and it is only as fast as the data it inherits. Extraction software reads each invoice, pulls the header fields and line items without a template per vendor, and exports clean records into your accounting system. That means the aging report is right, the amounts are right, and the run goes from a slow investigation to a quick review and release. If you want to see how that front end works, you can extract invoice data automatically and feed clean records straight into your pay cycle.

Getting the most from every payment run

A clean payment run is downstream of everything that came before it. The invoices have to be captured accurately, matched against purchase orders and receipts, coded to the right accounts, and approved by the right people. Get those right and the run becomes a short, controlled, low-risk task. Get them wrong and every run turns into firefighting.

Start by fixing capture so the data entering the batch is trustworthy, then tighten the review and authorization controls around the run itself. The teams with the smoothest pay cycles are not the ones with the fanciest payment tool; they are the ones whose invoice data was clean long before payment day arrived.

Related reading: what invoice processing involves end to end, how an invoice approval workflow works, three-way matching before payment, capturing early-payment discounts, and preventing duplicate invoice payments. To automate the data side, see our invoice data capture software and accounts payable automation software. When you are ready to automate the disbursement itself, accounts payable payment automation handles approval routing and vendor payments, and once payments clear you can reconcile them faster by converting statements with a bank statement to Excel converter.