# Vendor Payment Runs: Plan, Review, and Release Payments

> Build a payment run from approved bills, review holds and bank changes, reconcile the batch to the bank, and handle multi-currency payments and DPO questions.

- Canonical page: https://procindex.com/blog/vendor-payment-runs
- Author: ProcIndex Editorial Team
- Published: 2026-02-09
- Updated: 2026-11-10
- Topics: accounts-payable, payment-runs, cash-management, dpo, multi-currency

Bills are approved and the payment run is due this afternoon. If the reviewer still has to open every bill to find out what changed since approval, the run gets harder every month volume grows. What the reviewer needs is a batch they can tie to approved bills and a short list of items that need a decision.

Approval only puts a bill on the candidate list. A bill can be approved and still be excluded because it is on hold, its payment details changed, or paying it now would use cash needed elsewhere. The payment run is where those questions get answered, and where the last chance to stop a bad payment sits.

> **Deciding whether to pay early?** The [early-payment discount calculator](https://procindex.com/tools/early-payment-discount-calculator) shows what a discount is worth against your cost of cash.

## The payment run, step by step

1. **Select candidates.** Pull approved bills for the paying entity by due date, discount deadline, and cash available for the run.
2. **Remove what shouldn't go.** Take out bills on hold and send any bank-detail changes through independent verification.
3. **Review the batch.** Look at it by vendor, amount, currency, and payment method. Check that no bill appears twice.
4. **Release.** The authorized approver releases the batch under your payment policy.
5. **Reconcile.** Tie the bank result back to the batch. Give rejected or returned payments an owner and a reason before retrying them.

## Start from aging, then add what aging can't tell you

Run AP aging as of the date you plan to use and reconcile the total to the payables ledger before you build anything from it. Open the detail by supplier and keep the bill ID, due date, and open amount. In NetSuite, for example, the A/P Aging Detail report shows unpaid bills, days past due, and open balances by vendor. [Oracle's A/P Aging Detail Report documentation](https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_N1529840.html)

Aging tells you what is open and how old it is. It doesn't tell you which bills are approved, which are held, or which have already been paid but not reconciled. Put those states beside the amount.

| Bill status | What to do |
| --- | --- |
| Approved and due before the next run | Put it in the proposed run under the agreed terms |
| Eligible for an early-payment discount | Verify the eligible amount and deadline, then compare the discount with the cost of paying early |
| Waiting for receipt or price confirmation | Give the buyer or receiving lead the exact line and set a review date |
| Credit expected from the supplier | Verify which bill it applies to and whether the remainder is due |
| Payment sent but not reconciled | Check the payment and bank records before issuing another |

The discount row has its own guide: [early-payment discounts](https://procindex.com/blog/early-payment-discounts). Holds are covered in [invoice holds and payment blocks](https://procindex.com/blog/invoice-holds-and-payment-blocks).

### How ERP payment proposals select bills

ERPs typically build a proposal from selection criteria. In Dynamics 365 Finance, Microsoft documents payment proposals that select invoices by due date, cash discount date, or both. Its setup also allows skipping the invoice preview, so confirm where your own review happens before using that option. [Microsoft's payment proposal guide](https://learn.microsoft.com/en-us/dynamics365/finance/accounts-payable/create-vendor-payments-payment-proposal)

Whatever the system, treat the proposal as a draft. Review the selected bills before treating it as the payment schedule.

## Prepare the batch before the reviewer signs in

Show the funding account, payment method, batch total, and bill references. List withheld items separately. Every hold needs a reason and an owner, even if the reason is just that a credit memo hasn't been applied yet.

Keep the approved list with the run. If someone adds a bill, changes an amount, or changes where a supplier will be paid, send the revised batch back through review.

### Give the reviewer a clear stopping point

| What the reviewer sees | What to check before release |
| --- | --- |
| Batch total differs from the approved list | Identify additions, omissions, or changed amounts |
| Same supplier appears more than once | Check the bill references and look for a payment already in flight |
| Bank details changed since the last payment | Confirm the separate verification and approval are documented |
| Run was rebuilt after an upload timed out | Check the bank's status for the original submission before sending another file |

### Illustrative example: tying the batch to the approved list

The approved list for Thursday's run has 38 bills totalling $412,600. The batch AP prepared totals $398,350, a difference of $14,250. Before release, the reviewer should be able to explain every dollar:

| Item | Amount |
| --- | --- |
| Approved list | $412,600 |
| Less: bill placed on hold after approval (receipt disputed) | −$9,800 |
| Less: supplier credit memo applied against an approved bill | −$4,450 |
| Batch total | $398,350 |

$9,800 + $4,450 = $14,250, which accounts for the full difference. If the reviewer can't build this bridge from the records in front of them, the batch isn't ready.

## Choose the method the supplier can accept

| Method | Confirm before release |
| --- | --- |
| ACH | The vendor accepts it and the account details were independently verified |
| Virtual card | The vendor accepts card payments and the remittance identifies the bill |
| Wire | Recipient instructions and approval requirements were independently checked |
| Check | The mailing address is current and the outstanding check can be reconciled |

Use your bank's cutoff and confirmation rules when scheduling the run. If you send an ACH file, follow your bank's file instructions. Nacha's format includes batch and file control records with entry counts and debit and credit totals. Compare those totals with the approved run, then check the bank's acknowledgement. [Nacha ACH File Overview](https://achdevguide.nacha.org/ach-file-overview)

A supplier's request to change bank details belongs in a separate verification process using contact information you already trust. The [duplicate payments and vendor master guide](https://procindex.com/blog/duplicate-payments-vendor-master) covers that path.

## Finish the run after release

Keep separate statuses for prepared, released, accepted, and reconciled. Whoever owns reconciliation should be able to trace an accepted payment to its bank activity and a rejected payment back to the unpaid bill. If the bank returns one item from a larger batch, isolate it so the rest of the run stays intact.

Keep the ERP payment record, bank result, and vendor remittance tied to the same bill. Then AP can answer a supplier's "where's my money" without rebuilding the batch.

## Multi-currency payments

A design agency invoices your U.S. company in euros. The department approves the euro amount, accounting records the bill in dollars, and the bank debits a different dollar amount on payment day. Give each number a label and a source, or the person reconciling the payment has to guess whether a difference came from the rate, a fee, or an amount still owed.

**Approve in the contract currency.** Check the legal entity, vendor, contract currency, invoice amount, and due date. Show the original amount beside any converted amount used for approval, and record the rate, its source, and date. Ask the controller how approval limits work when the approver sees one currency and the ledger uses another. If the supplier changes invoice currency, send it back to the owner to confirm terms.

| Stage | Evidence to keep |
| --- | --- |
| Bill approval | Original invoice, contract currency, paying entity, approver |
| Accounting entry | Bill ID, transaction currency, base-currency amount, rate used |
| Payment | Supplier amount, funding amount and currency, execution rate, fees |
| Reconciliation | Bank debit, payment reference, amount applied to the bill, any open balance |

### Illustrative example: rate difference versus fee

A €20,000 bill is recorded at 1.08 USD per EUR, so the payable is $21,600. On payment day the rate is 1.10, so settling €20,000 costs $22,000. The bank also charges a $25 transfer fee. The bank debit is $22,025.

- Realized exchange loss: $22,000 − $21,600 = $400
- Fee: $25, recorded separately
- Total: $21,600 + $400 + $25 = $22,025

If the reconciler sees only "$425 more than the bill," they can't tell which part is rate and which is fee. In NetSuite, realized exchange-rate variance uses rates from the source transaction and the payment transaction; trace both before adding a manual entry. [Oracle's realized gain and loss documentation](https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/bridgehead_4279828767.html)

Test a partial payment and a case where the supplier reports receiving less than expected. Compare the payment confirmation with the agreed fee arrangement before deciding whether AP owes a balance. And if a payment request times out after submission, check the provider and the accounting record for the original request before retrying.

## Use DPO to ask better questions, not to set the run

Days payable outstanding (DPO) estimates how long payables stay open. A common estimate divides average trade payables by cost of goods sold for the period and multiplies by the days in the period. If you have reliable credit-purchases data that matches the payables balance, you can use that instead. Document the method and keep it consistent.

For example, average trade payables of $1,800,000 and quarterly COGS of $5,400,000 give $1,800,000 ÷ $5,400,000 × 90 = 30 days.

A rising DPO can come from longer agreed terms, which is planned cash timing, or from a queue of overdue, disputed bills, which needs an owner and a decision. Track missed due dates alongside DPO so a higher average doesn't hide bills that simply got stuck. If treasury wants to move a payment beyond its due date, have the supplier owner discuss it and record the agreement before changing the schedule. For how payables timing feeds the forecast, see [DSO and cash forecasting](https://procindex.com/blog/dso-cash-forecasting).

## What goes wrong

- **Proposal released without review** because the preview step was turned off.
- **Upload timeout, file resent**, and the bank processes both.
- **One return holds up the whole batch** because statuses are tracked at batch level only.
- **Bank-detail change applied mid-run** to a batch built on the old instructions.
- **Credit applied twice**: once on the bill, once by reducing the payment manually.

## Audit one past run

Pick a past run that included a hold or a return. Ask a second person to explain, from the records alone, why the amount debited differs from what AP originally proposed. Every place they have to ask someone or open another system is a gap to close before the next run. If the bottleneck turns out to be earlier, with bills arriving late for approval, look at [scaling finance without hiring](https://procindex.com/blog/scaling-finance-without-hiring).

## Sources

- https://learn.microsoft.com/en-us/dynamics365/finance/accounts-payable/create-vendor-payments-payment-proposal
- https://achdevguide.nacha.org/ach-file-overview
- https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_N1529840.html
- https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/bridgehead_4279828767.html

---

Published by ProcIndex, which builds AI accounting agents for construction and manufacturing finance teams. ProcIndex currently connects to NetSuite, Sage Intacct, and QuickBooks. Worked examples in this guide are illustrative, not customer results.