Paying the People Who Did the Work
A project here can pay the people who worked on it, through a document with its own reference, approval and posting date. That is a second way of paying somebody, running beside payroll, and neither one knows about the other.
Most systems have exactly one way to pay a person, and it is payroll. A system that grows a second one has usually done so for a good reason, and the reason is worth understanding before you use it.
Why a second rail exists at all
Because payroll cannot reach a project. A payslip in this product carries no project reference, so there is no path by which the wages of the people on a job become that job's labour cost, and no path by which a job can pay somebody.
For a business employing staff on a monthly salary, that is fine — the labour is a fixed cost and the project consumes some of it. For work delivered by people who are paid for that work specifically, it is not, and that is the gap a project payout fills.
What a payout is
A proper document rather than a note. It has a reference, a route, a status, a currency and a total. It records who approved it and when, and separately when it was posted — two different events, correctly kept apart.
It has lines, so the total is composed rather than typed. And it notifies, so the people involved learn about it without somebody remembering to tell them.
A reference and a route
It is a document you can refer to and a stated way the money travelled.
An approver, with a time
Distinct from whoever created it. Money out with no named approver is not a control.
A posted date, separate from approval
Approving and paying are two events. Collapsing them is a common and costly simplification.
Lines
The total is composed from parts rather than asserted.
A notification
The people it concerns are told.
Any connection to payroll
None. Two rails, no shared view of what a person was paid in total.
Two ways to pay one person, each careful, each complete, and no screen anywhere adds them together.
The seal, which is the best detail here
A time entry carries both an invoice reference and a payout reference, and it cannot be edited once either is set.
That is a double seal on the same record from two directions: once an hour has been charged to a customer it is fixed, and once an hour has been paid to a worker it is fixed. Both are refusals in code rather than conventions.
It matters here more than it would elsewhere, because project time is not covered by the timesheet month lock that governs attendance — hours can be logged into a closed month. The per-document seal is what stops the serious version of that: an hour somebody has already been paid for cannot be quietly changed afterwards.
What to watch when you run two rails
-
Decide per person which rail they are on, and write it down
Somebody paid through both is the situation that produces a surprise. There is no rule preventing it and no view showing it.
-
Do not expect a total-paid figure
Payroll knows what payroll paid; payouts know what payouts paid. Nothing sums them, so a person's total earnings from your organisation is a manual addition.
-
Treat approval and posting as the two dates they are
The document keeps them separate, which is correct. Reporting that reads only one of them will disagree with reporting that reads the other.
-
Reconcile payouts against project cost deliberately
A payout is money out; project labour cost is hours multiplied by a project rate. Those are different numbers about the same work, and they will not match.
That last point is the one that catches people. Paying somebody through a payout does not make the project's labour cost equal to what was paid — the cost figure is still logged hours at the project's cost rate, and the payout is a separate document. Both are recorded and they are not the same number.
Two, and the first is a view rather than a feature
The two rails are each well built. What is missing is anything that sees both at once.
Total paid per person, across both rails
Payroll plus payouts, per person, per period, on one screen. It is a join rather than a new mechanism, and it is the number anybody asked to account for what somebody earned will need.
Payout reconciled against project labour cost
What the job was costed at, against what was actually paid out on it, with the difference explained. This is the closest this module can get to a real labour cost without payroll learning about projects, and it would make job margin considerably more honest.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. If you pay delivery teams per job, the second is where the value is.
Talk to us about paying project teamsWhat AWRA OpsHub does today
- A payout document per project with a reference, route, status, currency and total, composed from lines.
- An approver and approval time recorded, separately from a posted date.
- Notification when a payout is raised.
- Time entries sealed once attached to a payout, with edits refused — the same protection as an invoiced entry.
- Both seals on the same record, so an hour is fixed once it is either billed or paid.
What it does not do
- Any connection between payouts and payroll. Two rails, and nothing sums them.
- A total-paid figure per person across both.
- Any rule preventing somebody being paid through both for the same work.
- Any reconciliation between what was paid out on a project and what that project was costed at.
- Any allocation of payroll cost to a project — a payslip carries no project.
Not ours, by choice
- The payout document is well built and the double seal on a time entry is one of the better controls in the projects module. This page is about the boundary between two rails rather than a criticism of either.
- A payout being separate from project labour cost is not a defect — they measure different things — but it is a difference people expect to reconcile and it does not.
- Nothing here is Caribbean-specific in law. The region is here because project delivery through contracted and seasonal teams is ordinary there, which is exactly the arrangement a second payment rail exists for.
Four questions about paying project workers
How many ways can a person be paid in this system?
A good answer sounds like
A number, and a list.
What it actually means
Ours is two. The count is the first thing to establish and it is rarely one.
Is there a total-paid figure per person?
A good answer sounds like
Yes, across all rails.
What it actually means
Ours has none. It is a manual addition, and it is the figure anybody investigating will ask for.
Can an hour already paid for be edited?
A good answer sounds like
No.
What it actually means
Ours refuses, on both the invoice and the payout side. This is genuinely well done.
Does paying out change the project's labour cost?
A good answer sounds like
An honest no, usually.
What it actually means
Ours does not — cost stays hours times a rate. Expecting them to match is the common mistake.
Our position
Use payouts where people are paid for specific project work and payroll where they are salaried, and decide per person which one applies rather than letting it happen. Keep a manual total of anybody who appears on both, because nothing in the product will produce one — and do not expect a payout to move the job's costed labour figure, because it will not.
Count the ways somebody can be paid
It is the same question as counting the ways a supplier can be paid, asked of the other side of the business, and it is asked far less often.
Talk about project paymentsFrequently asked questions
Does a payout post to the accounts?
It records an approver, an approval time and a separate posted date, which is the document doing its job. How it reaches your accounts is worth confirming against your own setup rather than assuming, and it is a fair question to put to us with your configuration in front of you.
Can the same hour be invoiced and paid out?
Yes, and that is normal — you bill the customer for the hour and pay the worker for it. Once either happens the entry is sealed, so the two documents cannot disagree about the hours afterwards.
Should salaried staff be paid through payouts?
Generally no. Payouts suit people paid for specific work; salaried staff belong in payroll. Mixing them for one person is permitted by the software and creates the reconciliation nobody wants to do.
