Paying many people at once, without paying anybody twice

Paying two hundred people at once has two classic failure modes, and most systems manage to have both.

Failure one: all or nothing

Row 147 has a malformed phone number. The file is rejected.

Nobody is paid. It is the 28th. The finance officer now has an evening ahead of them, and two hundred people have a worse one.

Failure two: the retry

The file part-succeeds. A hundred and eighty people are paid, twenty are not, and the report says completed with errors.

Somebody now has to work out which twenty. If they get it wrong and re-run the whole file, a hundred and eighty people are paid twice — and recovering an overpayment from someone who has already spent it is not a technical problem, it is a series of difficult conversations.

Validate before anybody approves

The file is checked when it is uploaded, before approval and before anything moves.

Errors are reported with the row and the reason. Fix them and re-upload, or proceed without them. This is a two-minute correction at a desk rather than an incident at eight in the evening.

Approval is a separate act

Uploading and approving are different actions, so nobody pays two hundred people by clicking the wrong thing once.

For most organisations this is also the control they actually want: the person who prepares payroll is not the person who releases it.

Outcomes per row

Every row reports its own result: paid, or failed with a reason.

So re-running means re-running the rows that failed — not the file. The double-payment failure mode simply does not arise, because there is no reason for anybody to resend a batch wholesale.

Events, not inboxes

Batch outcomes are published as events, so a payroll system can react to them.

Nobody should be refreshing a page to find out whether their staff were paid.

What it costs

Payouts are priced individually at the ordinary rate for the rail. There is no surcharge for sending them together.

What you can check

These are facts about the running platform, not adjectives. Each one is visible in the product, in the API reference or in the ledger.

• The file is validated before approval, so errors are found while nothing has moved.
• Outcomes are per row, so a failure is attributable to a line rather than to the file.
• Approving is separate from uploading, so nobody pays two hundred people by pressing the wrong button once.
• A batch has a bounded number of rows and a documented column layout, so a file either conforms or is rejected with a reason.
• Batch events are published, so a payroll system can react to the outcome rather than polling somebody’s inbox.

What it costs

Payouts are priced individually at the ordinary rate for the rail; there is no separate charge for sending them as a batch.

Is it switched on?

Whether this is available depends on the authorisations in place and on what the administrator of a given deployment has switched on. That changes, and an article does not — so the live answer lives on the feature page, which reads it from the platform itself: Bulk payouts on the features page.

Read next

• Withdrawals and payouts — Held, executed, or returned. Never lost in between.
• Team and roles — Delegate the counter, not the business.
• Signed webhooks — Your software finds out before your customer does.