What a batch payout is
A batch payout is a single instruction that contains many individual payments. Instead of keying each one by hand, the payer prepares a file listing every payee, amount, currency and reference, uploads it, funds it with one transfer and approves the run. The provider then processes each line as a separate payment.
Batches are used wherever a business pays many recipients on a cycle: contractor and freelancer payments, affiliate and partner commissions, marketplace seller settlements, insurance claims, refunds and royalty runs. The volume makes manual entry slow and error-prone, and the regularity makes a repeatable process worthwhile.
The advantages are control and consistency. Every payment in a run follows the same checks, carries the same kind of reference and appears in one report. The disadvantage is that one bad line can delay a run if the process is not designed to isolate it.
Payee onboarding comes first
The quality of a batch depends almost entirely on the quality of the payee records behind it. A payee should be set up and verified once, before their first payment, and then reused in every file.
A sound onboarding record usually holds:
- Full legal name of the individual or company, exactly as held at their bank.
- Address, including country of residence or incorporation.
- Bank details: account number or IBAN, bank identifier, bank name and country.
- Account currency, so the right currency is sent.
- Identity or registration details where the payer's own policy or the provider requires them.
- The nature of the relationship: contractor, affiliate, supplier, seller.
- A unique payee ID used in every file.
Collect bank details from the payee directly, through a form or portal, and confirm them through a channel you trust. Store them in one system. When a payee asks to change bank details, treat it as a new onboarding with the same checks. Most payout fraud happens at the point of change.
A sample file layout
Providers each have their own template, often in CSV format. The fields are broadly similar. The layout below is an illustrative example of the columns a payout file typically contains, with sample rows using made-up data.
| payee_id | payee_name | country | currency | amount | account / IBAN | bank_id | reference | purpose |
|---|---|---|---|---|---|---|---|---|
| P-10021 | Marta Kowalska | PL | EUR | 1850.00 | PL61 1090 ... (illustrative) | BIC | OCT-INV-0457 | Translation services, October |
| P-10388 | Harbour Creative Ltd | GB | GBP | 3200.00 | GB29 ... (illustrative) | BIC | OCT-INV-0458 | Design retainer, October |
| P-10412 | Lim Wei Jie | SG | USD | 975.50 | Account no. (illustrative) | BIC | OCT-INV-0459 | Software testing, sprint 14 |
A few rules make files cleaner. Use the payee ID as the primary key and look up bank details from the onboarding record, so the file cannot quietly introduce a new account. Give each line a unique reference. Use a full stop for decimals and no thousands separators. Include a purpose on every line, because each payment will be screened and may be reviewed on its own. Add a control total at the end, or in a separate field, so the uploaded file can be checked against what finance approved.
Validation before submission
Run checks on the file before it leaves your hands. Many providers validate on upload, but catching errors earlier saves a cycle.
- Every payee ID exists in your onboarding records and is active.
- Bank details in the file, if present, match the stored record.
- Amounts are positive, within expected ranges and in the right currency for each payee.
- No duplicate lines for the same payee and reference.
- The total matches the approved run total.
- No line is for a payee flagged as on hold.
Duplicates deserve special attention. A file exported twice, or a payee listed under two IDs, is a common way to overpay. Recovering an overpayment from an individual in another country is slow and uncertain.
Screening before every run
Each payee in a batch should be screened against sanctions lists before every run is released, as well as at onboarding. Lists change frequently. A payee who was clear in March may not be clear in October.
Screening typically checks names, addresses and countries against relevant lists. Potential matches are reviewed by a person who decides whether the hit is real. False positives are common with common names, so complete payee data helps reviewers clear them quickly.
Alongside sanctions, providers look at the shape of the run: total value, number of payees, countries involved and changes from previous runs. A run that suddenly doubles in size, or includes a new country, may be reviewed before release. Telling your provider in advance about planned changes avoids that pause.
Funding the batch
A batch needs to be funded before the payments go out. The usual pattern is that the payer sends one transfer to the provider covering the full value of the run, in one or more currencies. Where payees are paid in several currencies, the payer either funds each currency or funds in one currency and converts.
Practical points to plan for:
- Fund early enough to clear before the planned release. Incoming wires take time like any other.
- Reference the funding payment with the batch ID so it is matched to the right run.
- Decide in advance how conversion will be handled. If you fund in euros and pay in sterling, dollars and zloty, convert once for each currency at a known rate before the run.
- Agree what happens to any surplus, such as payments that were held or rejected: whether it stays on account for the next run or is returned.
Handling partial holds and rejections
In any large run, some payments will not go straight through. A beneficiary bank may reject a line for a wrong account number. A screening hit may need clearing. An intermediary may raise a query on a single payment.
A well-designed process isolates these lines so the rest of the batch proceeds. The held lines are reported back with a reason, and the payer decides what to do: correct the details and resubmit, supply information, or cancel and pay later.
Communicate with affected payees promptly. A contractor who has not been paid while colleagues have will notice. A short message saying the payment is held for a bank detail check, with a request to confirm their details through your portal, resolves most cases. For returned payments, the funds come back to the payer, sometimes less charges, and may arrive in a different currency if the payment was converted. The guide to returns and recalls covers this in more depth.
Reconciliation
After a run, finance needs to prove three things: what was approved, what was paid and what failed. A clean reconciliation compares:
- The approved run total and line count.
- The funding received by the provider.
- The line-by-line status report: paid, held, rejected, returned.
- Any conversion details, with rates and amounts.
- Returned funds and any charges deducted.
Match each line by payee ID and reference, not by name. Keep the payment confirmations, ideally with the UETR or provider transaction ID for each line, so individual payments can be evidenced later. Carry held and returned items forward to the next run as a separate list so nobody is paid twice or forgotten.
Controls that keep batches safe
Because a batch moves a lot of money in a single approval, it needs firmer controls than a one-off payment.
- The person who prepares the file should not be the person who approves it.
- Approval should be based on a summary the approver can check: total, count, currencies, new payees and changes since last run.
- Changes to payee bank details should be approved separately, before the run.
- Scheduled runs reduce last-minute pressure, which is when mistakes and fraud happen.
The guide to dual authorisation covers approval design in more detail.
Common mistakes in payout runs
Teams that run payouts for a while tend to learn the same lessons. Some of the mistakes that come up most often:
- Editing the file by hand after approval. Any change after sign-off breaks the link between what was approved and what was paid. If a line must change, regenerate the file and approve again.
- Opening files in a spreadsheet that reformats data. Spreadsheets can strip leading zeros from account numbers, convert long numbers to scientific notation or change date formats. Check the saved file in a plain text editor before uploading.
- Mixing currencies without checking funding. A run that pays in four currencies but is funded in one will stall if the conversion has not been arranged.
- Reusing references. A reference copied from last month makes reconciliation harder and can confuse payees who match by reference.
- Paying new payees in a large run. A first payment to a new payee carries more risk. Some teams pay new payees in a separate, smaller run until their details are proven.
- Forgetting held lines. A payment held last month and never resolved becomes a complaint, or is accidentally paid twice when someone adds it manually.
A simple run checklist, completed and signed by the preparer and the approver each cycle, prevents most of these. Keep the completed checklists with the run records for audit.
General information
This article is general information about batch payout operations and is not legal, tax or regulatory advice. For an outline of how CCYFX handles collections and payouts, see our Collections and payouts page.
