If you manage agents in the field, payday is the part of the month that does not scale. Twenty agents is a long evening. Two hundred is a week, two people, and at least one payment that has to be corrected afterwards.
The reason is not laziness or bad systems discipline. It is that the information needed to pay someone is spread across places that do not talk to each other: attendance on a paper sheet or a photo in a WhatsApp group, task completion in a supervisor's head, rates in a spreadsheet, and phone numbers in a contacts list that has three versions of the same person. Payroll is the act of manually joining those four things together, and manual joins produce errors.
This article covers how bulk M-Pesa payouts work mechanically, and what has to be true in your operation for the whole thing to take ten minutes instead of three days.
Why M-Pesa rather than bank transfer
For a field workforce, the bank rail has a structural problem: a meaningful share of casual and short-term field workers do not have an active bank account, and those who do often cannot recall the account number accurately. Collecting and verifying account details for 200 temporary workers is itself a multi-day job, and it has to be redone every time the roster changes.
A phone number does not have that problem. Your agents already gave you one, they use it daily, they know it by heart, and it is the same identifier you use to assign them work. Paying to the phone number removes an entire data-collection step and the errors that come with it.
The mechanism for this is M-Pesa B2C — business to customer — exposed through Safaricom's Daraja API. It is the same rail used for insurance claim payouts and loan disbursements. It sends money from a business short code to a customer's M-Pesa number, and it can be called programmatically, which is what makes bulk payment possible at all.
One clarification, because it matters commercially: integrating Daraja is not a partnership with Safaricom. Any business can apply for API access. When you see a platform describe M-Pesa payouts, it means it calls this API on your behalf.
The four things that have to be true before you can bulk-pay
Bulk payment is the easy part. It only works if four preconditions hold, and most operations fail on the second and third.
Every agent has one verified, correctly formatted phone number. Kenyan numbers arrive in at least four shapes — 0712…, +254712…, 254712…, 712… — and a payout API will reject or misroute the wrong ones. Numbers should be normalised on entry, once, not cleaned up at payday.
Attendance exists as data, not as paper. If attendance is a photographed sheet, someone has to read it and type it in, and that person is the bottleneck. GPS check-in and check-out creates the same record automatically, with a timestamp and a location that can be defended if a client disputes it.
Work approval is explicit and recorded. "Did agent X complete the merchandising at Sarit?" needs a yes or no with evidence attached — a photo, a time, a supervisor's approval — not a recollection. The approval is what authorises the amount.
The rate is attached to the assignment, not to a memory. Daily rates differ by skill, region and agent level. If the rate lives in a supervisor's WhatsApp message, payroll is a negotiation. If it is set when the task is assigned, payroll is arithmetic.
Get those four right and the payout itself is a single action, because the amount per agent is already known and already authorised. This is the actual insight: bulk payment is not a payments feature, it is the downstream consequence of recording attendance and approval properly.
How the money moves, step by step
1
Fund the wallet.
You top up your organisation's wallet from M-Pesa, either by STK push — a prompt on your phone that you confirm with your PIN — or by paybill. This is your float. Money cannot go out that has not gone in.
2
Approve the work.
Review submitted tasks with their photo evidence and check-in records. Approval sets the payable amount for each agent. Anything not approved is not paid, and the agent can see why.
3
Review the batch.
You see the list: every agent, every amount, and the total against your available float. This is the last point at which a mistake is cheap. Check the total, not the lines — if the total is wrong, a line is wrong.
4
Send.
The batch dispatches as individual B2C transactions. Each one returns a result — completed, failed, or pending — against the agent and the task it paid for. Agents receive the standard M-Pesa confirmation on their phone, which is the receipt they trust.
What goes wrong, and what to do about it
Insufficient float. The most common failure, and the most avoidable. Top up before you approve, not after, and top up above the batch total — transaction charges come out of the same pot. A batch that stops halfway is worse than one that never started, because now you have to work out who was paid.
Individual failures inside a successful batch. A number is no longer registered, an account is dormant, a recipient has hit a transaction limit. These fail individually while the rest succeed, which is the correct behaviour — but somebody has to look at the failed list and act on it the same day. Treat it as a task, not a notification.
Transaction limits. M-Pesa has per-transaction and daily ceilings. For daily-rate field work you will rarely approach them, but a monthly consolidated payout to a supervisor or a technician on a long contract can. Know the current limits before you design the payout cycle around them.
Timing. Payouts land within seconds normally, but Safaricom runs maintenance windows and occasional incidents. Do not schedule the batch for 11pm on the last day of the month with nobody watching it.
What your records need to contain
Paying quickly is only half of it. The payment has to be defensible — to your auditor, to KRA, and to the agent who thinks they were underpaid.
For each payout you want, at minimum: the agent's identity and verified phone number, the task or period the payment covers, the approval and who gave it, the gross amount, the M-Pesa transaction reference, and the timestamp. Held together, that chain answers every question anyone will ask — including the awkward one, which is whether the person was actually where they said they were, on the day they claimed.
On tax: payments to field workers carry VAT and withholding implications that depend on whether the worker is your employee, an independent contractor, or supplied through an agency, and standard VAT in Kenya is 16%. The classification is a question for your accountant, not for a blog post — but whichever way it falls, you need invoices that state it correctly and records you can export. If your current process cannot produce a per-agent payment history on request, that is a compliance problem waiting for a bad month.
Personal data deserves the same seriousness. You are holding phone numbers, ID numbers and payment histories for people who did not negotiate a privacy policy with you. Kenya's Data Protection Act applies. Encryption at rest, access limited to people who need it, and a real answer to "what happens to this data when the contract ends" are the baseline.
The shorter version
If payday takes three days, the problem is almost never the payment step. It is that attendance, approval and rates were never recorded as data in the first place, so payday is when you finally do that work — under time pressure, from photographs.
Move the recording to the moment the work happens, and payday collapses into a review and a single send.
Gigs4You does this end to end: GPS check-in creates attendance, photo-verified approval sets the amount, and bulk M-Pesa B2C payout runs off both — with a transaction record against every task and VAT invoices generated automatically.
Start free for 14 days — no card required.