Bulk payouts · run guide
Paying hundreds of people in one run, row by row
A bulk payout is one instruction that becomes many separate payments. This guide follows a batch the way an operations team runs it: preparing the file, stopping bad rows early, releasing it, reading what came back, retrying only what failed and closing the books.
- R-001Asha K. · ••4321₹4,250IMPSProcessed
- R-002Vikram S. · UPI ID₹1,180UPIProcessed
- R-003Meera T. · ••0917₹12,600IMPSFailed · invalid account
- R-004Rahul D. · ••5520₹2,40,000RTGSProcessed
- R-005Farah N. · ••8812₹3,900IMPSPending · bank quiet
- R-006Joseph P. · ••2204₹7,450NEFTProcessed
- R-007Kiran B. · ••6130₹960IMPSFailed · account closed
- R-008Sunita R. · UPI ID₹2,300UPIProcessed
- R-009Imran A. · ••3047₹18,000NEFTReturned later
- R-010Deepa M. · ••7719₹5,120IMPSProcessed
A batch is a container, not a payment
When you pay one supplier, you create one payout. When you pay four hundred sellers on a Friday, you could create four hundred payouts by hand, or send them as one batch. The batch saves effort at the start, but it doesn't change what happens underneath: every row is still an individual transfer to one account or UPI ID, with its own rail, its own bank reference and its own outcome.
Most confusion about bulk payouts comes from forgetting this. Teams expect a batch to “succeed” or “fail” as a whole, and reconcile it against one total. In practice a finished batch is a mix: most rows paid, a few rejected, one or two waiting on a slow bank, and occasionally one that comes back days later. The rest of this guide is about running that mix calmly.
If you're new to payouts in general (rails, statuses and what a UTR is), start with the payouts guide. This page covers only what changes when you pay many people at once.
| One payout | Bulk payout | |
|---|---|---|
| Instruction | One request or one dashboard action | One file or one request with many rows |
| What moves | One transfer | One transfer per row |
| Status | One status | A status per row, plus a batch summary |
| A failure affects | That payout | Only the failed rows |
| Retry | Send it again as a new payout | A follow-up batch of failed rows only |
| Reconcile against | Its bank reference | Each row's reference and bank reference |
Stage 1
Prepare the file
A batch usually arrives as a spreadsheet-style file uploaded to a dashboard, or as one API request that lists many payouts. Either way, each row needs the same few things. The exact columns and file formats Peneu accepts are confirmed during onboarding; the shape below is what almost every provider expects.
| Your reference | Beneficiary name | Account / UPI ID | IFSC | Amount (₹) | Remark |
|---|---|---|---|---|---|
| SELLER-0926-0001 | Asha Kumari | ••••4321 | ABCD0001234 | 4,250.00 | Week 38 settlement |
| SELLER-0926-0002 | Vikram Singh | vikram@bank | not needed | 1,180.00 | Week 38 settlement |
| SELLER-0926-0003 | Meera Traders | ••••0917 | EFGH0005678 | 12,600.00 | Week 38 settlement |
| SELLER-0926-0004 | Rahul Das | ••••5520 | IJKL0009012 | 2,40,000.00 | Week 38 settlement |
Account numbers are masked here; a real file carries the full number. IFSC codes and names are made up.
Rules for a clean file
- One unique reference per row, from your own system, never reused. It's how you find the row later, and how a repeated upload is recognised as a duplicate instead of paying twice.
- Amounts in one format: rupees with two decimals, no currency symbols, no thousands separators unless the format asks for them.
- Bank account plus IFSC, or a UPI ID, not both on the same row.
- A remark the recipient will recognise, because it often appears on their statement and saves a support call.
Mistakes that cost the most
- Uploading the same file twice after a timeout, without unique row references to catch it.
- Spreadsheet software turning long account numbers into scientific notation, or trimming leading zeros.
- Copying last week's file and editing amounts, leaving someone who shouldn't be paid this week.
- Bank details typed by hand from an email instead of taken from a verified master list.
Stage 2
Check every row before money moves
A row caught before release costs nothing. The same row caught after release costs a failed transfer, a support ticket and sometimes money that has to be recovered from the wrong person. So a good batch passes through a series of checks, and each one either passes the row or holds it back for a fix.
Which of these checks run automatically, and which you run yourself, depends on the setup; the gates Peneu applies to a batch are confirmed during onboarding.
Gate 1
FormatCatches: Missing fields, malformed account numbers or IFSC codes, bad amounts
Then: Rejected with the reason; fix and resubmit the row
Gate 2
DuplicatesCatches: A reference already used, or the same person and amount twice in one batch
Then: Held; confirm it's intentional or remove it
Gate 3
BeneficiaryCatches: An account that doesn't exist, is closed, or belongs to someone else
Then: Held until the details are corrected and verified
Gate 4
Amount rulesCatches: Rows above your own per-person limit, or above what a rail allows
Then: Held for approval, or moved to a rail that fits
Gate 5
FundingCatches: A batch total larger than the money available to pay it
Then: Batch waits for funds instead of half-running
Beneficiary checks are their own subject: see bank account verification for the methods, and penny drop for the ₹1 test transfer.
Stage 3
Approve and fund the batch
Release is the moment a batch stops being a plan and starts moving money, so it deserves two separate questions: has the right person agreed to it, and is the money there to pay all of it?
Who approves
The person who prepares a batch shouldn't be the one who releases it. This is usually called maker-checker: one person uploads, another reviews the summary (row count, total, largest rows, new beneficiaries) and approves.
Larger batches often need a second approver above a threshold you set. The approver should see what changed since the last run, not just the total: new names and changed bank details are where fraud and mistakes hide.
Is the money there
A batch is paid from a balance you've funded or directly from your own account, depending on how your payouts are set up. Before release, compare the batch total with what's available, and leave headroom for fees.
What happens if funds run short mid-batch differs between setups: some hold the whole batch, others process rows until the balance runs out. Confirm which applies to you before the first large run.
Scheduling.A batch can often be released immediately or set for a later time, for example to pay sellers at the start of the business day. A scheduled batch should still be reviewed close to its run time, because a beneficiary's details or your balance can change in between.
Stage 4
During the run: every row travels alone
Once released, the batch is broken back into its rows. Each row goes on the rail that suits it: a UPI ID travels on UPI, a large amount to a bank account may go on RTGS, most others on IMPS or NEFT. Rows don't wait for each other, so a batch doesn't finish all at once. The first rows can be credited within seconds while others are still in a NEFT batch or waiting on a slow bank.
That's why a batch shows progress instead of a single answer, and why the right moment to look at results is when every row has a final state, not when the upload finishes.
If more than one banking partner is connected, rows can be spread across them, and new rows can move away from a partner that's having trouble. Rows already sent through a slow partner stay there until that partner gives a final answer. Moving them would risk paying twice.
| Row | Usually goes on | Timing |
|---|---|---|
| To a UPI ID | UPI | Seconds, any hour |
| To a bank account, needed now | IMPS | Seconds, any hour |
| To a bank account, not urgent | NEFT | Next half-hourly batch, any day |
| ₹2 lakh or more to a bank account | RTGS (or NEFT) | Credited within about 30 minutes |
NEFT and RTGS timings are from RBI's FAQs. Per-transaction limits for UPI and IMPS are set by NPCI and your bank. Which rails are live on your account is confirmed during onboarding. More in the payouts guide.
Stage 5
Read the results row by row
A finished batch has four kinds of row. Status names vary between providers; the meanings below are what matter, and the exact names on Peneu are in the API reference.
Processed
The beneficiary's bank accepted the credit and a bank reference (UTR) exists.
Do: Record the reference. Tell the recipient if they asked.
Pending
Sent, but the bank hasn't given a final answer yet.
Do: Wait and check status. Never resend a pending row.
Failed
Rejected with a reason: a wrong account, a closed account, a limit, a bank outage.
Do: Fix the cause, then retry as a new payout.
Returned
It was sent, then came back, sometimes days later.
Do: Money is back with you; correct and repay, or cancel.
Failed rows never left, pending rows may leave later, and returned rows came back. On the day of the run, the amount debited is almost always less than the file total. Reconcile row by row.
Stage 6
Retry only what failed, then close the batch
A safe retry
- 1Wait until every row has a final state. A retry file built while rows are still pending will eventually include someone who gets paid anyway.
- 2Take the failed rows only, and read each failure reason. A closed account can't be fixed by retrying; the recipient has to give you new details.
- 3Correct the details, and verify any changed bank account before paying it.
- 4Give each retried row a new reference that points back to the original, such as SELLER-0926-0003-R1, so both attempts are visible in your records.
- 5Send the corrected rows as a small follow-up batch, with the same approval as the first.
Whether Peneu can build a retry batch from a finished batch's failed rows automatically is confirmed during onboarding.
When a paid row comes back
A transfer can be accepted and then returned by the beneficiary's bank, for example when the account can't receive credits or the name doesn't fit the account. The row then changes from processed to returned, and the money is credited back to you.
Treat a return as a new event on the original row, not a new row. Keep the original bank reference and the return reference together, and decide whether to pay again with corrected details or cancel the obligation. Until a rail's return window has passed, a processed row is very likely final, but not certainly.
Closing the batch: reconcile three records
A batch is closed when three records agree for every row: what you intended to pay, what the provider says happened, and what your bank statement shows.
| Row | Your file says | Payout status says | Bank statement says | Result |
|---|---|---|---|---|
| SELLER-0926-0001 | ₹4,250.00 | Processed · UTR 6271… | Debit ₹4,250.00 · same UTR | Matched |
| SELLER-0926-0003 | ₹12,600.00 | Failed · invalid account | No debit | Matched (unpaid, retry) |
| SELLER-0926-0005 | ₹3,900.00 | Pending | Debit ₹3,900.00 | Open: wait for final status |
| SELLER-0926-0009 | ₹18,000.00 | Returned | Debit, then credit ₹18,000.00 | Matched (unpaid, decide) |
Illustrative rows. Whatever report format you use, the match key is your row reference plus the bank reference.
For matching across many batches and providers, see reconciliation.
Controls worth having before your first large run
Bulk payouts concentrate risk: one approval can move a lot of money to a lot of people. These controls are common practice. Which are built into your Peneu setup, and which you enforce in your own process, is agreed during onboarding.
Maker-checker
Different people prepare and release a batch.
Approval thresholds
Batches or rows above a limit need a second approver.
New-beneficiary flag
First-time recipients and changed bank details are highlighted at approval.
Cooling-off for changes
A bank-detail change can't be paid in the same run it was made.
Balance alerts
You know before release if the batch can't be fully funded.
Roles and access
Only named people can upload, approve or download batch reports.
Who runs batches, and what each should watch
| Who pays | Typical batch | What to watch |
|---|---|---|
| Marketplaces | Weekly or daily seller settlements | Holds for returned orders; sellers changing bank details just before payday |
| Employers | Monthly salaries, off-cycle bonuses | Confidentiality of amounts; paying on the day, not the day after |
| Finance teams | Supplier runs against approved invoices | Invoice approval before payment; remittance details for the supplier |
| Gig and delivery platforms | Frequent, small payouts to many workers | UPI IDs that change; high row counts with small amounts |
| Insurers | Approved claim payouts | Paying the right policyholder account; audit trail per claim |
| Brands and fintech apps | Cashbacks, rewards, referral bonuses | Duplicate rewards from repeated uploads; very large row counts |
Bulk payout questions
What is a bulk payout?
A bulk payout sends money to many recipients from one instruction: a file or a single API request with many rows. The batch is only a container. Each row becomes its own payout, travels on its own rail and ends in its own status, so one bad row doesn't stop the others.
If one row fails, does the whole batch fail?
It shouldn't. In a well-run batch each row succeeds or fails independently. You fix the failed rows and send them again as a smaller follow-up batch; the rows that were paid are left alone.
Can I retry a row that is still pending?
No. Pending means the bank hasn't given a final answer yet, not that the payout failed. If you resend it and the original then completes, the recipient is paid twice. Check its status until it becomes processed or failed.
Why doesn't my bank statement match the batch total?
Because a batch rarely settles as one amount. Failed rows never leave, pending rows may complete later, and a row that was sent can come back as a return days afterwards. Reconcile row by row using each payout's own reference and bank reference, not the batch total.
Which file format does a bulk payout need?
It depends on the provider. Most accept a spreadsheet-style file or a list of payouts in one API request, with a reference, beneficiary details and an amount per row. The exact columns and formats Peneu accepts are confirmed during onboarding.
Should I verify every beneficiary before each batch?
Verify new beneficiaries, and anyone whose bank details changed, before they are paid for the first time. Re-verifying people you have paid successfully before adds cost without much benefit, unless your own policy or the size of the payment calls for it.
How large can one batch be?
Limits differ by provider and by rail, and very large runs are often split for operational reasons anyway: a smaller batch is easier to approve, fund and reconcile. Batch size limits on Peneu are confirmed during onboarding.
What happens to a payout that is returned after it was sent?
The money comes back to your account and the row needs a decision: correct the details and pay again, or cancel the obligation. Treat the return as a new event on the original row, keep both bank references, and never assume a sent payout is final until the return window for that rail has passed.
Run sheet
Every batch, in ten checks
- 01Unique reference on every row
- 02New and changed beneficiaries verified
- 03Totals and row count match your source
- 04Prepared and approved by different people
- 05Funding covers the total plus fees
- 06Released; progress watched until every row is final
- 07Pending rows checked, never resent
- 08Failed rows fixed and retried with new references
- 09Returns recorded on the original row
- 10File, statuses and statement reconciled
Talk through your payout runs
Tell us who you pay, how often and how many rows a run has. We'll walk through the file, approvals, funding and reporting that fit.
Official sources
- RBI — NEFT FAQs (24×7 availability, half-hourly batches)
- RBI — RTGS FAQs (₹2 lakh minimum, credit timelines, UTR)
Last reviewed . Examples, amounts and screens marked illustrative are not Peneu figures.