Vendor payments: what your ERP already does

The payment run is the part somebody already built

Most requests to automate vendor payments arrive describing the payment run, and the payment run is the one part of this process that is already finished. Selecting which approved invoices are due, grouping them by vendor and bank account, applying the discount dates, producing a file the bank will accept and posting the result back to the ledger is a shipped feature of every serious accounting package and every ERP, and for euro transfers inside the Union the format that file has to be in is not even a vendor’s choice: the law requires the ISO 20022 XML message format wherever a business that is not a microenterprise initiates credit transfers bundled together for transmission. So the interesting question is not whether the run can be automated. It is what is left once it has been, and the honest answer is that what is left is not a payments problem at all. It is a question about the vendor master record, about who is allowed to change an account number, and about a cross-border leg where the cost is in the currency conversion rather than in the transfer. Foxnut Studios builds and hands over systems that move money, which is a reason to be plain about the transfer standard for anything that moves money before agreeing to build one that does not need building.

Four arrangements, and what each one actually changes

The four arrangements below are not four levels of sophistication. They differ in where the payment decision is made and in who carries the loss when it is made wrongly, and those are separate questions from how much of the keying is automated.

The fourth column is the one worth reading twice. In the first three arrangements the payment run is somebody else’s maintained product and the company owns only its own criteria. In the fourth the company owns a payment file generator, and a payment file generator is a piece of software whose failure mode is sending money to the wrong place.

When a person at the bank portal still wins

It wins where there are few enough vendors that the person recognises each one, where the payables list is short enough to read, and where the bank relationship is single. The failure mode is not slowness. It is that the control lives entirely in one person’s memory of who the suppliers are, so a convincing request to change an account number has nothing to fail against. The upgrade worth making at that size is a written rule about how a bank detail changes, not a system.

When the accounting system’s own payment run wins

It wins in almost every case above that size, and it is under-configured far more often than it is outgrown. The selection criteria a payment proposal exposes are the payment policy written down: pay by due date or by discount date, within this window, for this method and this currency, excluding blocked items, not exceeding this total, and check the vendor is not sitting in a debit balance first. One vendor’s documentation goes further and offers a recurring schedule that runs the proposal automatically, which is the whole of what most briefs ask a new system to do. The failure mode is criteria that were set at implementation by somebody who has left, against a supplier base that has since changed, with payment blocks accumulating on invoices nobody revisits.

When a dedicated payables or payments product wins

It wins on the two things the ERP genuinely does not do well: onboarding suppliers, including collecting and verifying their bank details from the supplier rather than from an email, and routing across several banks, currencies and countries from one place. That is a real category with a real job, and it is worth noticing that the job is supplier data and bank connectivity, not the payment run. The failure mode is buying it for the run, then discovering the onboarding module is the part that had to be implemented properly and the part nobody scoped.

When an integration built for this company wins

It wins where the payment decision itself is genuinely unusual, and the honest examples are narrow: a marketplace or platform paying out to a large population of counterparties on rules that are the product rather than an administrative function, or a treasury structure where which entity pays, in which currency, from which account is a decision with money in it and no packaged product models it. Outside those, a build here is a bank file generator with a support burden, competing against something the company is already licensed for.

What the decision turns on

Six structural dimensions decide whether a process is worth automating. Vendor payments read unusually on four of them, and the four point the same way: the process is standardised almost to the point of being a utility, and the risk that remains is concentrated at a single, cheap, non-technical control point.

Three of those rows agree in a way that is rare in this pillar. The exception row says the hard cases are enumerated and mostly somebody else’s. The volume row says the work does not grow with the thing a business case usually counts. The maturity row says the whole capability is licensed, documented and legally standardised. A process with that profile does not reward a build, and saying otherwise would be arguing against three sourced rows to reach a more comfortable conclusion.

The reversibility row is the one that redirects the effort rather than reducing it. Because a transfer executed on the account number supplied is deemed correct against whoever holds that account, the entire consequence of this process is decided by the accuracy of a field in the vendor master and by who may change it. That is not automation work. It is a change-control question with a documented answer, and the same product documentation that describes the automated run also describes a configuration that stops bank account edits made during a proposal from flowing into the payment lines, so that payments cannot be redirected without oversight and the audit trail survives.

How to automate vendor payments across countries

Paying vendors in other countries is the one part of this process where something genuinely remains to be decided, and it is not the part that the word automation usually points at. The measurements below come from the Financial Stability Board’s 2025 progress report against the G20 cross-border payments targets, taken in March 2025.

The first fact reorders the whole question. For a business-to-business cross-border payment of twenty thousand dollars, the average total cost was 1.6 percent, of which 1.4 percentage points was the foreign exchange margin and 0.2 percentage points was the fee. The currency conversion is 87.1 percent of what a cross-border vendor payment costs. Automating the run touches the 0.2. Deciding which entity pays, in which currency, from which account, and whether two flows in opposite directions can be netted before either crosses a border, touches the 1.4. A company that has automated its cross-border payment run and has not looked at its currency and routing policy has automated the cheap part of the bill.

The second is that the corporate cross-border experience is materially worse than the wholesale one, and worse than it was two years ago. Wholesale payments, meaning those of one hundred thousand dollars or more, ran above ninety percent credited within one business day, with more than half credited within the hour. Business-to-business retail payments over the same period ran at 39.6 percent credited within one business day, down from 54 percent in 2023, and 2.2 percent within one hour. Ten percent of business-to-business corridors cost more than three percent. And only 43.2 percent of business-to-business payment services published both their cost and their speed to the sender, against 73.7 percent for person-to-person services. So the operational problem in cross-border payables is not that the run is slow to prepare. It is that the payment leaves and its arrival date and final cost are frequently not knowable in advance, which is a forecasting and vendor-communication problem rather than a processing one.

The third is that the standardisation that makes domestic vendor payments a solved problem stops at the currency area’s edge. For euro transfers inside the Union the file format is fixed by law, in euro-area member states the payee-verification service is now a legal requirement, and screening obligations sit on the provider. Outside that perimeter, formats, name-verification services and cut-off conventions are per-country and per-bank, and the migration of the international messaging network to ISO 20022 is still in progress, with the same report noting that speed improves once both ends of a payment have completed it.

What follows for a system, and it is a different specification from the domestic one. The cross-border work worth automating is the decision layer: which of the group’s entities and accounts should settle a given supplier, in which currency, on which rail, and by when in order to hit the invoice’s due date given a settlement window that is not reliably one day. The mechanical submission is, again, something the bank or the payments product already does. And the payee-verification asymmetry deserves stating plainly, because it is the practical safety difference between a domestic and a foreign payment: inside the euro area a mismatch between the account number and the supplier’s name will now be surfaced before authorisation, and outside it, in most corridors, nothing will check that the name and the number belong together at all.

What this comparison usually gets wrong

The first error is counting invoices. A business case built on the number of payments per month is measuring the one variable that does not drive the cost, because the file is one file at any line count and its format is fixed. The variables that do drive it are the number of banking relationships, currencies, legal entities and countries in scope, and a case that does not name those four has not been costed.

The second is treating fraud as a payments control. Business email compromise is a scam about a message, not about a transfer: the fraudulent instruction to change a bank account arrives by email, is accepted by a person, and is then executed perfectly by whatever system the company runs. A faster and more automated payment process makes a successful redirection settle sooner and with fewer people looking at it. The control that works is upstream and administrative, in who may amend a vendor bank record and what evidence they need, and the recovery numbers show why prevention is the only economical option: even the federal recovery team, working with law enforcement and banks, freezes funds in about two cases in three when it is invoked at all.

The third is reading the payee-verification opt-out as a performance setting. It is a liability setting. The Regulation deliberately allows a business submitting payment orders as a package to decline the name check, and equally deliberately requires the provider to explain what declining it does to liability and refund rights. Any automated run large enough to trip the check is exactly the run for which somebody will propose turning it off, and that proposal should be made by whoever carries the loss rather than by whoever owns the schedule.

The fourth is scoping late payment as a courtesy. In European commercial transactions the interest runs without a reminder, the fixed forty-euro compensation is payable per debt without a reminder, and business-to-business payment terms are limited to thirty days by default and sixty as a general ceiling unless a longer period is expressly agreed and not grossly unfair. A payment calendar that quietly stretches terms is not a working-capital strategy in that jurisdiction; it is an accruing liability that nobody is invoicing yet, and it is an argument for a correctly configured run rather than against one.

There is one prior question this page does not answer, and it belongs upstream. Whether the invoice should have been approved for payment at all, and whether the amount matches what was ordered and received, is a different control with a different failure mode. This page begins after that decision has been made, and a payment system built on approvals nobody trusts will simply pay disputed amounts on time.

The verdict

Buy it, and check first whether it is already bought. On the evidence in the profile above, vendor payment automation is a configuration project rather than a build, and the burden of proof sits on anyone proposing otherwise. The exceptions are a closed list defined in legislation and largely handled by the payment service provider. The effort does not scale with the volume a business case usually counts. The message format is mandated. The application layer, down to a schedule that runs the proposal without anyone starting it, is documented in the product most companies in this position already license. There is no plausible reading of those rows that produces a build, and manufacturing one to look even-handed would be a worse failure than the recommendation being commercially inconvenient.

What survives is smaller than a project and more important than the run. The reversibility row says a payment executed against the account number the system supplied is final as against the person who actually holds that account, so every pound of consequence in this process is decided by the accuracy of one field and by the rule governing who may change it. The regulatory row says the one control that catches a wrong account in the euro area can be lawfully switched off for exactly the batch files an automated run produces, and that switching it off moves liability. Neither of those is fixed by software. They are fixed by a written change-control rule for vendor bank details, a segregation of the person who edits that record from the person who releases the run, and a decision, made by name, about whether the payee check stays on.

The cross-border leg is the only place a build has an argument, and it is an argument about currency and routing rather than about payments. Where 87.1 percent of the cost of a cross-border vendor payment is the foreign exchange margin, and where fewer than half of such payments arrive within a business day, the thing worth automating is which entity settles which supplier in which currency and when, so that a due date is met given a settlement window nobody can promise. That is a decision system, and it happens to sit next to a payment run rather than inside one.

For a team weighing this, the useful first move costs nothing. Open the payment proposal in the system already installed and read its selection criteria against the payment policy as it is actually practised. Then take the last twelve months of vendor bank-detail changes and try to establish, for each one, who requested it, who approved it and what evidence was checked. The first exercise usually finds that the automation was licensed years ago and never configured. The second usually finds the actual exposure, and it is never in the payment run.

If you have not run the second exercise on your own vendor-master changes recently, that is worth doing this week - tell us what you find and we will help you read it.

The part most pages leave out

When not to choose Foxnut Studios

Situations where another option is the better call, and where we say so in the first conversation rather than the fourth.

• The accounting package or ERP already carries a payment proposal and a payment run, and nobody has configured the selection criteria, the payment blocks or the bank file export. The brief is to build something that assembles a payment file. That software, and the studio says so. One major vendor's own product documentation describes selecting invoices by due date or cash discount date, filtering by vendor range, method of payment, currency and legal entity, checking that a vendor is not in a debit balance before paying, previewing or suppressing the proposal, and defining a recurring schedule that runs the proposal automatically. That is the whole of the brief, already shipped and supported. Paying to rebuild it is the most common thing found underneath a vendor payment automation request, and configuring the licensed one is a week rather than a project.
• The design removes the human release step from the payment run, on the reasoning that a reviewed proposal is the bottleneck and the file is correct by the time it gets there. A human control point, or a simpler deterministic rule. The asymmetry is in the law rather than in the software: under the European payment services rules a payment order executed in accordance with the unique identifier is deemed to have been executed correctly with regard to the payee that identifier names, and where the identifier supplied was wrong the payment service provider is not liable and owes only reasonable efforts to recover. Sending is the last moment at which a payment is still a decision. Automating the assembly and keeping a person on the release costs a signature; automating the release costs whatever the file contained.
• The payments are euro-area credit transfers submitted as a package, and the design opts the file out of the payee-verification service so that a run of several thousand lines completes without interruption. The incumbent certified vendor, whose attestation is the product. The opt-out is lawful and deliberate: the Regulation gives users who are not consumers the means to opt out when submitting multiple payment orders as a package. But the same article requires the provider to state the implications for liability and refund rights of ignoring or declining the check, and the refund obligation it creates runs to a provider that failed to perform the check, not to a payer who declined it. A bank or scheme participant that runs the verification, screens its users daily against restrictive measures and carries the scheme membership is selling exactly the attestation the opt-out gives away.
• The case rests on the time the payment run takes, and one person currently clears the month's run in a morning from a proposal the accounting system already produces. The person already doing it, unchanged. A payment file is one file whether it carries ten lines or ten thousand, so the effort does not scale with the invoice count. It scales with the number of banks, currencies, legal entities and exceptions, and where those are one, one, one and few, the whole saving is the morning. The useful automation at that size is upstream of the run, in the approval that decides what enters it, and it is usually already licensed.
• The vendor master's bank details are maintained from emailed remittance forms and PDF letterheads, with no record of who changed an account number, when, or on whose authority. The organisation itself, doing the documentation first. A payment run is only ever as correct as the account numbers it reads, and automating it makes a wrong account get paid faster and on a schedule. The United States federal crime reporting defines business email compromise by precisely this population, businesses regularly performing wire transfer payments, and the same ERP documentation that describes the automated run also describes a configuration that stops bank account edits made during a proposal from reaching the payment lines, so that payments cannot be redirected without oversight. The control is already in the box. The record of who may change an account number is not.

Sources

1. Regulation (EU) 2024/886 amending Regulations (EU) No 260/2012 and (EU) 2021/1230 as regards instant credit transfers in euro, Official Journal 19 March 2024 - Article 5c on verification of the payee, including paragraph 6 on the opt-out available to non-consumer users submitting multiple payment orders as a package and paragraph 8 on liability and refund, Article 5d on at least daily screening of payment service users against targeted financial restrictive measures, and recitals 21, 24 and 25. Read as the Official Journal full text on EUR-Lex Retrieved 11 August 2026
2. Directive (EU) 2015/2366 on payment services in the internal market (PSD2) - Article 88 on incorrect unique identifiers, paragraphs 1 to 3, and Article 89 on payment service provider liability for non-execution or defective execution. Read as the consolidated directive text on EUR-Lex, CELEX 32015L2366 Retrieved 11 August 2026
3. Regulation (EU) No 260/2012 establishing technical and business requirements for credit transfers and direct debits in euro - Article 2(25) defining an R-transaction, Article 5(1)(d) requiring the ISO 20022 XML message format where a non-consumer, non-microenterprise user initiates credit transfers bundled together for transmission, and recital 14 on mandatory standards. Read as the full text on EUR-Lex, CELEX 32012R0260 Retrieved 11 August 2026
4. Directive 2011/7/EU on combating late payment in commercial transactions - Article 2(6) defining statutory interest as the reference rate plus at least eight percentage points, Article 3(3) on the thirty-day period and Article 3(5) on the sixty-day ceiling for business-to-business terms, and Article 6(1) on the fixed sum of EUR 40 payable without a reminder. Read as the full text on EUR-Lex, CELEX 32011L0007 Retrieved 11 August 2026
5. Federal Bureau of Investigation, Internet Crime Complaint Center, '2024 Internet Crime Report' - the business email compromise complaint and loss figures, the definition of business email compromise in Appendix B, and the Recovery Asset Team's 2024 Financial Fraud Kill Chain results. Read as text extracted from the Bureau-hosted PDF Retrieved 11 August 2026
6. Financial Stability Board, 'G20 Roadmap for Enhancing Cross-border Payments: Consolidated progress report for 2025', published 9 October 2025 - section 3.1 on wholesale speed, and Tables 7, 8, 9, 12 and 15 on the cost, foreign exchange component, corridor spread, speed and transparency of business-to-business retail cross-border payments. Read as text extracted from the FSB-hosted PDF Retrieved 11 August 2026
7. Nacha, 'ACH Network Rules: Reversals and Enforcement' - the five-banking-day window within which a Reversal must be made available to the receiving institution, the closed list of permissible reasons for a Reversing Entry, the formatting requirements, and the R11 and R17 return codes for an improper Reversal Retrieved 11 August 2026
8. Nacha, 'ACH Network Volume and Value Statistics' - full-year 2025 network volume and value, and the business-to-business payment count and value for 2025 Retrieved 11 August 2026
9. Microsoft, 'Create vendor payments by using a payment proposal', Dynamics 365 Finance product documentation, article dated 19 November 2025 - the payment proposal selection criteria, the advanced parameters including the vendor balance check and the multi-legal-entity options, the vendor payment proposal automation scheduling feature, and the note on vendor bank account changes at proposal time Retrieved 11 August 2026

Foxnut Studios works on briefs like this one from Bengaluru and Paris. If you want the shape of that before you talk to anyone, here is what an AI engagement covers and what you keep.