Paying the People Who Did the Work: Project Payouts
Logging hours against a job tells you what it cost. It does not pay anybody. This is the other half — turning unpaid logged time into money that actually leaves your account, without paying the same hour twice or losing the trail between the timesheet and the bank.
A Kenyan contractor finishes a fit-out. Six people worked it: three on the payroll, two casuals who come when there is work, and one subcontracted electrician with an invoice. The hours are all logged against the job, the client has been billed, and now somebody has to work out what each of those six is owed — usually in a notebook, usually on a Friday, usually twice because the first attempt included hours that were already paid last month.
This is the least discussed and most error-prone part of project work in Kenya, because it sits in the gap between two systems that were never designed to talk to each other: the place where hours are recorded, and the place where money goes out. Here is how that gap is closed, and precisely where the controls are thinner than you might assume.
What this is, and what it is not
A project payout is money out for work done on a job — it is not payroll, and it does not replace it. Payroll runs on a calendar for people you employ. A payout runs on a project, for whoever worked it, at whatever moment you choose to settle. Where the two overlap, you route the payout through payroll rather than around it, so an employee's earnings stay taxable in one place.
Why a project needs its own way of paying people
The instinct is to put everything through payroll and be done. That works when everyone who touches a job is a monthly employee. It stops working the moment your delivery model includes people who are not.
Payroll
- Runs on a fixed calendar — monthly, for a defined set of employees.
- Statutory by nature: PAYE, NSSF, SHIF and the housing levy all attach to it.
- Answers "what does this person earn this month?"
- Wrong tool for a subcontractor with an invoice, or a casual paid at the end of a two-week job.
A project payout
- Runs when the job says so, not when the month says so.
- Pays whoever worked it — employees, casuals, or an external contractor with a vendor record.
- Answers "what do we owe on this job, and to whom?"
- Can be routed into payroll for employees, so their earnings remain taxable in the right place.
The related payroll mechanics — and why an employee is not the same object as a system user — are in PAYE, NSSF, SHIF and the housing levy and casual, daily and piece-rate workers.
How a payout is built
The starting point is not a blank form. It is your own unpaid logged time, which is the only figure nobody has to remember.
-
Draft from unpaid hours
The system gathers every time entry on the project that has not already been paid on an earlier payout, groups it by the person who did the work, and creates one hours line each. The rate it uses is the project's cost rate — the internal cost per hour, not what you bill the client.
-
Correct the rates
The draft prices everybody at the same project rate, which is a starting assumption rather than a truth. While the payout is a draft, you can set the rate per line, and the amount recomputes. This is the step people skip and then wonder why the senior technician and the apprentice cost the same.
-
Add what hours do not capture
A fixed line covers everything that is not an hourly amount: a stipend, a completion bonus, a subcontractor's agreed fee. A contractor line needs a payee — either a vendor record, which makes it automatically payable, or just a name, which means you will settle it manually.
-
Approve it
Approval stamps who approved it and when, and freezes the payout against further editing. A payout with nothing to pay cannot be approved.
-
Check the preflight, then post
Once approved, you see line by line how each payee will actually be paid — automatic M-Pesa, automatic bank transfer, through payroll, or manually — and whether that provider is even configured. Then you post, and the money starts moving.
A payout on a finished fit-out
Three different hourly rates, because they were set per line rather than left at the project default. The two fixed lines are things no timesheet would ever have produced. Every hour behind the first three lines is now stamped as paid and cannot appear on the next payout.
One important behaviour at the moment of posting
This deserves its own section because it surprises people, and because knowing it changes how you sequence the work.
When you post, the hours lines are recalculated against currently unpaid time, not against the figures that were in the draft. If somebody logged another eight hours between your approval on Thursday and your posting on Monday, those eight hours are swept into the payout and paid, at the line's rate. The total you post can therefore be higher than the total you approved.
The reasoning is sound — the amount always reflects what is genuinely owed and unpaid, so no hour is silently orphaned. But the practical consequence is real: approve and post in the same sitting, or tell the team that time logging on the project stops before a payout goes out. Treat a long gap between approval and posting as an open door.
Two routes out of the building
For employees you want taxed correctly
Route it through payroll
Each employee line becomes a taxable extra earning on this month's payslip, described with the payout reference and the project name. It is taxable and not pensionable. Note the period is the current month regardless of when the work was done, so a payout for March work posted in May lands on the May payslip.
For casuals, contractors and anything not on a payslip
Pay it directly
Each line becomes a pending money-out transaction in the Payments Register. For Kenyan shilling payouts, mobile-money payees are sent an M-Pesa B2C transfer automatically and bank payees a Paystack transfer — where those providers are configured. The accounting accrues the whole direct spend as a liability immediately and moves each amount to Bank only as its transaction confirms.
When a payee has no payout details, or the currency is not KES
Record it manually
The line still exists as a pending transaction with a name and an amount, and you mark it paid — bank, cash, cheque or card — once the money has genuinely gone. Flipping it to paid triggers the settlement entry, so the books follow the cash rather than leading it.
The preflight screen counts these buckets for you before you post, and tells you whether M-Pesa and Paystack are actually configured for your organization. That is deliberate: discovering that your mobile-money credentials were never set up is a much better experience before a payout than after one. The subcontractor case specifically is worked through in paying subcontractors on a Kenyan site.
What stops you paying the same hour twice
Two independent stamps on each time entry, doing two different jobs. Understanding that they are independent is the key to not double-counting anything.
| Billing the client | Paying the worker | |
|---|---|---|
| What gets stamped | The invoice the hour was billed on | The payout the hour was paid on |
| Rate used | Bill rate — what the client is charged | Cost rate — what the hour costs you |
| Direction of money | In | Out |
| What it prevents | Invoicing the same hour twice | Paying the same hour twice |
| Depends on the other? | No | No |
| Applies to non-billable time? | No — only billable entries are invoiced | Yes — unpaid work still gets paid |
So an hour can be paid but not yet billed, billed but not yet paid, both, or neither. That is not an inconsistency; it is the reality of project cash flow, and separating the two stamps is what lets you see it. Both rates are also snapshotted onto the time entry when it is logged, so changing a project's rates next quarter does not silently rewrite what last quarter cost or earned.
What a posted payout touches
The time entries
Every paid hour carries the payout it was paid on, so it can never be gathered into another one.
The Payments Register
Each direct line becomes a money-out transaction with the payee, amount, currency and method — sitting alongside vendor and payroll payments in one register.
The ledger
The whole direct spend is accrued to payroll payable at posting. Each amount moves from payable to bank as its transaction confirms success, so your liability and your cash are both honest at every point in between.
Payslips
Employee lines become taxable extra earnings in the current month, described with the payout reference and project.
The project cost figure
A payout does not add to the project's cost, because the logged time already carried the cost. The cross-project profitability report shows payouts for cash context beside the cost figure, without subtracting them — otherwise labour would be counted twice.
That last row is the one people query most. Cost is what the work consumed; a payout is when you settled it. Adding both would double your labour cost on every job.
What we do and do not do
What AWRA OpsHub does today
- A draft payout built automatically from unpaid logged time, grouped per person.
- Per-line rate correction and fixed lines for stipends, bonuses and subcontractor fees, while the payout is a draft.
- Contractor lines payable to a vendor record, or to a free-text name for manual settlement.
- A draft → approved → posted lifecycle, with the approver and time recorded, and editing frozen after approval.
- A preflight showing how each line will be paid and whether the provider is configured, before you post.
- Automatic M-Pesa B2C and Paystack bank transfers for Kenyan shilling payouts where details exist.
- Accrual to payroll payable at posting, with settlement to bank as each transaction confirms.
- A payroll route that turns employee amounts into taxable extra earnings on the payslip.
- Manual "record as paid" for cash, cheque or bank done outside the system, and retry for a failed transfer.
- A paid stamp on every time entry, independent of the invoice stamp, so no hour is paid or billed twice.
- A refusal to delete a time entry that has already been invoiced or paid out, so the records those documents were built from survive.
What it does not do
- Any reversal of a posted payout. There is no unpost, void or credit — a posted payout is permanent, and a correction means a compensating entry.
- Separation of duties: the single permission that lets someone create and edit a payout also lets them approve and post it. One person can do the whole run.
- A frozen amount between approval and posting — hours logged in that window are swept in, and the posted total can exceed the approved one.
- Per-employee cost rates held on the person. The draft prices everyone at the project rate; differentiating them is a manual per-line edit.
- Statutory deductions on the direct route. Direct payouts are gross amounts out; if PAYE should apply, that is what the payroll route is for.
- Automatic M-Pesa or Paystack settlement for non-KES payouts — those are manual regardless of the payee's details.
- Multi-currency payouts within one run; a payout carries a single currency.
The two on that list that would matter most to a growing business are separation of duties on approval, and a reversal path for a posted payout. Neither is architecturally hard. Both are honest gaps today, and worth weighing against how much money a single payout run moves in your business.
Before you post your first one
Six checks, in order
- Confirm the project's cost rate is the internal cost of an hour, not what you bill the client. Getting these two the wrong way round inflates every payout you ever run.
- Check that everyone who worked the job has an employee record with their hours attached — unassigned time entries produce no payout line at all.
- Set the per-line rates deliberately before approving. The default is one rate for everyone.
- Decide the route per payout: payroll for employees you want taxed correctly, direct for everyone else.
- Read the preflight and fix any "not configured" warning before posting, not after.
- Approve and post in the same sitting, and stop time logging on the project until it is done.
The cost side of the same hours is in project budget vs actual, the client-billing side in billable time in Kenya, and where every other kind of project cost comes from in charging costs to the right job.
Pay the job, not the guesswork
A payout built from unpaid logged time, priced per person, approved and posted with an [audit trail](/glossary/audit-trail), settling through M-Pesa or bank transfer — and every paid hour stamped so it can never be paid twice.
See project costing in AWRAFrequently asked questions
Is a project payout the same as running payroll?
No. Payroll runs on a calendar for people you employ; a payout runs on a project for whoever worked it, whenever you decide to settle. Where they overlap you route the payout through payroll — employee amounts then become taxable extra earnings on the payslip, so their earnings stay in one place for tax. Casuals and subcontractors go out on the direct route instead, as gross amounts with no statutory deductions applied.
How does the system know which hours have already been paid?
Each time entry carries the payout it was paid on. A new draft only gathers entries with no payout stamped, so an hour paid in March cannot reappear in May. This is deliberately independent of the invoice stamp that prevents double-billing the client — an hour can be paid but not billed, billed but not paid, both or neither, and the two stamps never interfere with each other.
Can we pay different people different rates on the same payout?
Yes, but not automatically. The draft prices every hours line at the project's cost rate, and you then set the rate per line before approving. There is no per-employee cost rate held on the person that the draft could read, so a mixed-skill team needs a deliberate pass over the rates. Skipping that step is the most common reason a first payout looks wrong.
What happens if someone logs more hours after we approve but before we post?
They get paid. At posting, the hours lines are recalculated against all currently unpaid time for that person on that project, so the posted total can be higher than the total you approved. The logic is that nothing owed is left behind, but the practical advice is firm: approve and post in the same sitting, and pause time logging on the project until the payout is out.
Can a posted payout be reversed?
No. There is no unpost, void or reversal — a posted payout is permanent, its time entries are stamped as paid, and the accrual is in the ledger. A mistake has to be corrected with a compensating entry rather than undone. Given that, the approval step is worth treating as a genuine review rather than a formality, especially since the same permission that lets someone build a payout also lets them approve and post it.
Does a payout increase the project's cost?
No, and that is intentional. The cost of labour was already captured when the hours were logged, at the cost rate. Adding the payout on top would count the same labour twice. The cross-project profitability report shows what has actually been disbursed alongside the cost figure, for cash context, without subtracting it from margin.
What if a transfer fails?
The transaction sits as failed in the Payments Register and can be retried on its own rail — M-Pesa or bank — without re-sending anything that already succeeded or is still pending. Alternatively, mark it as paid manually once you have settled it another way. Either path keeps the ledger honest: money only moves from payable to bank when a payment actually confirms.
