Bulk Payments: How a Batch Run Works, and the Four Ways It Fails

Bulk payments fail in a particular way, and this is the shape of it. The file had 340 lines and was submitted at 5:50 p.m. on the last working day of the month. It came back rejected at 6:04 p.m. with an error naming a line number and a field code.

Line 212 had a recipient name longer than the fixed-width field allowed. The whole file bounced, so all three hundred and forty payments failed, including the one on line 212. The bank's support line closed at six.

Batch payments are the efficient way to move money to many people, and the least forgiving.

One malformed row holds up hundreds. The failure arrives at the end of the process, hours after the mistake was made, in a message written for a systems integrator rather than for the person who has to fix it.

What bulk payments actually are

A bulk payment, also called a batch payment or a mass payment, is a single instruction containing many individual payments. You submit one file or one approved set, and the bank or platform breaks it into separate transfers.

The economics are the reason it exists. Sending 400 payments individually means 400 fees, 400 approvals, and 400 chances to fat-finger an account number. Sending them as one batch means one submission, one approval decision, and one reconciliation.

The trade-off is visibility.

In a batch, individual payments become rows. Rows attract less scrutiny than payments, and an approver signing off a total is not looking at any of them.

Three things are commonly called bulk payments and behave differently:

Whichever you use, the same four failure modes apply.

The file is the product

For bank batches, everything depends on a file format that is older and stricter than anything else you deal with.

ACH files use a fixed-width format with defined record types and positional fields. SEPA uses an XML message. Both have rules about field lengths, permitted characters, mandatory fields, and how the totals in the control record must agree with the sum of the detail records.

The practical consequences show up in ordinary data.

An accented character in a recipient's name may be rejected or silently transliterated. A name longer than the field is truncated or fails. An ampersand in a company name breaks some XML if the file wasn't properly escaped. A trailing space in an account number is a different account number.

None of these are exotic.

All of them come from a supplier record that a human typed, in a system that accepted it without complaint, months before the payment run existed.

Validate before submission.

Not because the bank won't tell you. Because the bank tells you at 6:04 p.m. Running the format rules against your own file takes seconds and moves the failure to a point in the day where somebody can still do something about it.

Bulk payments limits apply per payment, not per file

This is the misunderstanding that produces the most awkward conversations.

A Same Day ACH batch can contain any number of payments, but each individual payment is subject to the per-payment limit, currently $1,000,000 and rising to $10,000,000 on 17 September 2027. A file totalling $9 million made of many small payments is fine. The same file containing a single payment of $1.4 million is not.

The same logic applies elsewhere. RTP carries a $10,000,000 limit per transaction and runs 24/7/365. FedNow raised its customer credit transfer limit from $1,000,000 to $10,000,000 on 12 November 2025, and participants can set lower limits than the network maximum, which is the part that catches people: your bank's limit may be well below the scheme's.

Ask for two numbers before designing a run.

The per-payment limit your bank applies, and the per-file total it will accept. They are different constraints, and neither of them is the published network figure.

The choice between rails for a given run follows the same logic as any other payment, set out in wire transfer vs ACH and mapped more widely in payment rails.

Partial failure is the real risk in bulk payments

A batch that fails completely is annoying. A batch that partly succeeds is dangerous, because the natural response creates the second problem.

The fourth is the one that costs real money.

Somebody sees a failure notification, assumes the run didn't go through, and resubmits. It is an entirely reasonable inference from an ambiguous message, which is why the fix is in the process rather than in the person.

Three habits prevent almost all of it.

Record the outcome per row, not per file. The unit of truth is the payment, not the submission.

Build any retry from the failed rows only, as a new file with its own reference, never by resending the original.

Give every file a unique batch reference and check it before submission, so a duplicate submission is caught by your own process rather than by the bank's.

Approving a batch nobody can read

An approver looking at a batch sees a total. Approving one number is not the same act as approving the couple of hundred payments inside it, and treating the two as equivalent is how fictitious rows survive review.

What makes batch approval meaningful is a small set of checks that work on aggregates rather than requiring someone to read every line.

Compare this run to the last one: total, count, and the recipients present in one and not the other.

New recipients in a payroll or supplier run are the rows worth a human look, and there are usually a handful of them rather than hundreds, which makes this a two-minute check rather than an audit.

Flag any row whose amount differs materially from that recipient's usual amount. A supplier normally paid $2,400 who appears at $24,000 is either a genuine large invoice or a missing decimal, and both deserve a question.

Check the total against the source. The batch should reconcile to the approved invoice list or the payroll register before it reaches the bank, not after.

The control framework underneath this, including who can approve and what happens when bank details change, is in payment fraud prevention, and encoding the routing as a rule rather than a habit is part of vendor payment automation.

Reconciling bulk payments back to the ledger

A batch pays out as many payments and usually appears on the bank statement as one debit. That asymmetry is the whole reconciliation problem.

One statement line has to be matched against every payable inside it. If the batch is recorded in your ledger as a single payment, the individual payables never clear, and the aged listing keeps showing invoices you've already paid.

The mechanism that works is a clearing account. The batch debits a payment clearing account as one line, matching the statement. Each individual payment credits the same account as it is applied to its invoice. The account nets to zero when every row is accounted for, and any non-zero balance is exactly the list of rows that didn't do what you expected.

That balance is the most useful number the process produces.

It is a running list of unexplained items rather than a difference somebody has to hunt for on day four of the close. How it folds into the wider sequence is in month-end close.

Recipient data is where batches die

Every failure above traces back to a record that was fine for a human and wrong for a file.

Four fields cause most of it. Account numbers with spaces, dashes, or leading zeros stripped by a spreadsheet. Names longer than the field, or containing characters the format doesn't accept. Currency codes that don't match the account. And bank identifiers that were correct before the recipient's bank merged with another.

The spreadsheet problem deserves its own warning, because it's silent. Open a CSV of account numbers in a spreadsheet application and a value like 0041299 becomes 41299, and a long number becomes scientific notation. The file looks fine on screen. It fails at the bank, or worse, it pays someone else.

Keep the payment file out of spreadsheet applications.

If someone has to open it, force text formatting on those columns first, and treat any file that has been opened and re-saved as a new file that needs validating again.

Cross-border batches

A batch of international payments is not one payment with many beneficiaries. It's many international payments submitted together, and each one enters the correspondent chain separately, with its own routing, its own screening, and its own deductions.

Which means the batch does not settle as a unit.

Some rows land in two days and some in six. A supplier asking why theirs is late is asking about their row, and "the batch went out on Tuesday" is not an answer to that question.

Where the deductions come from, and how to stop suppliers receiving less than they invoiced, is set out in correspondent banking.

On-chain batches

Paying many recipients from one wallet has a different failure profile, and it's worth being precise about which parts are better and which are worse.

Better: no file format, no cutoff, no partial-acceptance ambiguity at the file level.

Each transfer either confirms or it doesn't, and the record is public. There is no state in which the bank has your file and nobody knows what happened to it.

Worse: no recall. A wrong address in row 47 of a bank file usually returns. A wrong address on-chain is a payment to whoever holds that key, permanently. And each transfer carries a network fee, so a run of 200 transfers has a gas cost that varies with network conditions at the moment you send.

What actually goes wrong in a crypto payout run, failure by failure, is covered in crypto payouts, and the comparison of tools for doing it at volume is in mass crypto payout system.

The operational discipline that makes it survivable is the same as for a bank file, with one addition: screen the addresses before the run rather than after. VaultNow handles payouts of up to 100 transactions from a CSV or address book with screening attached, at $0.50 per transaction plus gas, which puts the check inside the run instead of beside it.

Frequently asked questions

What is a bulk payment?

A single instruction containing many individual payments, submitted as one file or one approved run and broken by the bank or platform into separate transfers. It reduces fees, approvals, and manual entry, at the cost of making individual payments less visible.

What is the difference between a bulk payment and a batch payment?

Nothing consistent. The terms are used interchangeably, along with mass payments, mass payment solutions, and payout automation. What matters is which underlying rail the payments travel on, because that determines the limits, the timing, and whether a payment can be returned.

Is there a limit on how many payments bulk payments can contain?

Network schemes generally limit the value of each individual payment rather than the number of payments in a file, but individual banks and platforms set their own caps on both the row count and the file total. Ask your bank for both numbers, because they are usually lower than the published scheme limits.

What happens if one payment in a batch fails?

It depends on the bank and the error. Some reject the entire file for a single malformed row, others process the valid rows and report the rest as failed. The dangerous case is the second one handled badly: resubmitting the whole file to fix a few rows pays everything again.

How do you avoid duplicate payments when retrying a batch?

Record outcomes per payment rather than per file, build the retry as a new file containing only the failed rows with its own unique reference, and never resubmit the original. Check the batch reference against previously submitted references before sending.

How do you reconcile a batch payment?

Post the batch to a payment clearing account as a single debit matching the statement line, then credit that account as each individual payment is applied to its invoice. The account should net to zero, and any residual balance is the exact list of rows that did not settle as expected.

Why do account numbers break in payment files?

Usually because the file was opened in a spreadsheet application, which strips leading zeros and converts long numbers to scientific notation without warning. Keep payment files out of spreadsheets, or force the affected columns to text before opening.

Bulk payments are a volume discipline. The controls that matter operate on the file rather than on individual payments: validate the format before submission, record outcomes per row, retry only what failed, and reconcile through a clearing account that nets to zero.

The same discipline applies when the run settles on-chain, with less margin for error because nothing comes back. VaultNow covers payouts from a CSV or address book with screening and permissions attached, so the run carries the same controls your bank file does.

General information, current as at 31 August 2026. Not legal or financial advice. Scheme limits carry the effective dates stated.