Batch payment run: paying 20 suppliers without 20 transfers

A batch payment run collects all approved supplier invoices that are due, or worth paying early for the discount, into one list. One person checks it, a second person releases it, and the system sends a single SEPA file to the bank. Twenty suppliers are paid with one approval instead of twenty manual transfers, and every payment can be traced back to its invoice.

Most companies already know they should pay in batches. What goes wrong is everything around the transfer: invoices that are paid twice or not at all, discounts that expire unnoticed, and bank lines that finance matches by hand afterwards. A good payment run is less about the bank file and more about which invoices are allowed into it.

---

What is a batch payment run?

In a payment run, finance pays suppliers on a fixed rhythm instead of invoice by invoice. Many German companies run it once or twice a week. The system selects every invoice that is approved and due before the next run, and the person responsible reviews the list, removes or postpones items and submits it for release.

Technically, the result is one SEPA credit transfer file in the XML format the banks use (pain.001), uploaded through online banking or sent through EBICS, the corporate banking channel. The bank shows it as one order with many transactions. Once released, each supplier receives a normal transfer with the invoice number in the payment reference.

The rhythm itself is a control. Suppliers learn when they will be paid, finance stops answering ad hoc payment requests, and the cash flow forecast can plan outgoing payments by week instead of guessing.

There will always be exceptions: a supplier who will not ship until paid, a customs payment, a deposit. Allow them, but route them through the same checks and the same release, and record why the payment could not wait. If exceptions become the rule, the run is happening too rarely or approvals are too slow.

Which invoices belong in this week's payment run?

The selection decides whether the run is safe. An invoice should only enter the list if all of the following are true:

• It is approved. The person responsible for the budget has confirmed it, in the system, not by email. How that step works is covered in invoice approval workflow.
• It matches what was ordered and delivered. Quantity and price agree with the purchase order and the goods receipt, where there is one.
• It is not already paid. Duplicate payments usually come from the same invoice arriving twice, once as PDF and once by post, or from a direct debit and a transfer for the same item.
• The bank details are confirmed. A new or changed IBAN is checked against the supplier master data and approved by someone other than the person who entered it. Changed bank details are the classic route for payment fraud.
• Credit notes are netted. An open credit note from the same supplier reduces what you pay, rather than waiting for a refund.
• It is due, or the discount is worth taking. More on that below.

Invoices that fail one of these stay out of the run with a visible reason. The list of blocked items is often more useful than the run itself, because it shows where the process upstream needs attention. Our guide to accounts payable automation explains how to reduce the number of invoices that get stuck.

When is it worth paying early for Skonto?

Skonto is the early payment discount common on German invoices, for example 2 percent if paid within 10 days, otherwise net in 30 days. It looks small. It is not.

Paying 20 days early to save 2 percent is equivalent to an annual interest rate of roughly 37 percent. Few companies earn that on their cash, and even a current account overdraft is usually cheaper. If you have the liquidity, taking Skonto is one of the best returns available to a finance team.

The difficulty is timing. A Skonto deadline counts from the invoice date, and an invoice that spends a week in someone's inbox has lost most of its window before finance sees it. A weekly payment run should therefore sort by two dates: the net due date and the discount deadline. If the next run is after the discount deadline, the invoice belongs in this one. The rules and the arithmetic are in our article on Skonto and payment terms.

Who should release the payment run?

The person who prepares the run should not be the person who releases it. That four-eyes principle is not written into a specific German law, but tax advisors, auditors and banks all expect it as part of a working internal control system, and the GoBD (German digital bookkeeping rules) expect the process to be documented and traceable.

In practice, the preparer is an accountant or office manager, and the releaser is the managing director (Geschäftsführer) or head of finance. The bank can enforce the same split through signing rights: one person uploads the file, a second signs it, for example with a joint signature in EBICS. Many companies add an amount limit: above it, the run needs a further signature from the managing director.

Since 9 October 2025, banks in the euro area must offer Verification of Payee under the EU Instant Payments Regulation: before a transfer is executed, the payee name is checked against the IBAN, and the payer is warned if they do not match. For bulk files with several transactions, business customers may opt out. Before you do, consider that the name check catches exactly the errors a payment run is prone to: an outdated supplier name, a typo in the IBAN, or a changed account that nobody verified.

What happens after the payment leaves the bank?

The run is not finished when the file is sent. Three things should follow.

First, the payments should be booked against the open invoices, so the supplier balances show what is still outstanding. Second, the bank statement lines must be matched to those bookings. A batch can appear on the statement as one total or as individual lines, depending on your bank and settings, so agree with your bank which form you need. Matching individual lines is far easier than splitting a total by hand, as described in payment reconciliation. Third, suppliers who receive several invoices in one transfer need a payment advice that lists which invoices are covered, or their accounts receivable team will call yours.

How does Agent F help with batch payment runs?

In Agent F, accounts payable, procurement, the bank connection and the general ledger work on the same data. Invoices arrive, are matched to the purchase order and goods receipt, and are approved by the budget owner before they can be selected for payment.

On the day of the run, real-time aging shows which approved invoices are open and when each one falls due, so the preparer starts from a current list rather than a spreadsheet export. Approvals follow the workflow you define, and every step is in the audit trail. When the bank lines come back through the direct bank integration, Agent F suggests the match to the open invoices with a confidence score, a person confirms, and the bookings flow into the DATEV export for your tax advisor.

To start, fix a weekly payment day and stick to it. Add the Skonto deadline as a field to every incoming invoice. Make sure no single person can both change a supplier's bank details and release a payment. Then look at last month's payments and count how many discounts you missed.

Learn how Agent F works, or see it on your own supplier invoices at agent-f.ai/demo.