Paid for the Hours the Site Logged
Pay based on hours logged and you have made the log worth money — which is the moment it starts being written carefully, and also the moment it starts being written creatively. What the payout actually reconciles, and the lock that does not cover the clock you are paying from.
Site labour gets paid from a number somebody wrote down. On a good job that number comes from a timesheet signed by a foreman. On most jobs it comes from a foreman remembering the week on a Friday afternoon, which is a different thing wearing the same clothes.
The gap between those two is not usually theft. It is rounding, in one direction, applied consistently: a man who arrived at half past seven is remembered as arriving at seven, a half day becomes a day because he came all that way, and a week that was four and a half days is paid as five because arguing about it on a Friday is not worth anyone's afternoon.
Each of those decisions is defensible on its own and reasonable in the moment. Together, across a site of forty people and a job of fourteen months, they are a number with a great many zeroes in it, and nobody ever made a decision to spend it.
Paying from a log changes the log
The moment hours logged become the basis for payment, three things happen at once, and it is worth expecting all three rather than being surprised by the second.
- The log gets written properly. People record their time when the record is what pays them, and not before. This is the whole benefit and it arrives immediately.
- The log gets written optimistically. The same incentive that produces diligence produces generosity. Hours creep, particularly at the boundaries of a day and particularly for whoever does the entering.
- Disputes move from the payment to the log. This is progress even though it does not feel like it. An argument about a timesheet entry from a fortnight ago is a smaller and more resolvable argument than one about a payment.
A system that pays from logged hours therefore needs two properties rather than one: it has to build the payment from the log faithfully, and it has to make the log hard to revise after the fact. The first is the easy half.
The moment the log pays people, it starts being written carefully — and creatively. Both, at once, by the same people, for the same reason.
How a payout is built
A payout starts as a draft assembled from a project's unpaid logged time: one line per person with hours outstanding, priced at the project's cost rate as a starting point.
-
The draft is pre-filled, not fixed
Each line arrives with the hours that person has logged and not yet been paid for, and a rate taken from the project. Both the rate on each line and the note are editable before anything is approved, so a site agent and a labourer on the same project do not have to be paid the same figure.
-
Fixed lines can be added
Not everything on a payout is hours. A subcontractor sum, an allowance, a one-off — these go on as fixed lines alongside the hours lines, so a single payout can cover a mixed week.
-
It has to be approved before it can be posted
A draft cannot be posted. That is enforced rather than encouraged — posting anything other than an approved payout is refused outright.
-
Hours are recomputed at the moment of posting
This is the control worth understanding. When the payout is posted, each hours line is reconciled again against that person's currently-unpaid time, and the hours and amount are recalculated. The draft is a proposal; the log at the moment of posting is what pays.
-
Empty lines drop out
A line that reconciles to nothing, or to a negative, is skipped rather than posted as a zero — so a payout does not carry rows that exist only to look complete.
Why recomputing at post time matters
It closes the most obvious gap in any pay-from-log system: time logged between the draft being prepared and the payment being made. If a foreman enters three days of missing hours on the Tuesday after the draft was built on the Monday, those hours are in the payment rather than deferred to next time and forgotten. It also means the draft you approve and the amount that posts can differ, which is a thing to know rather than discover.
Where it goes
A posted payout lands in two places, and both matter for different reasons.
It enters the Payments Register alongside every other outflow, so project labour is visible next to supplier payments and payroll rather than sitting in a separate world. And it posts to the double-entry journals, so the cost reaches the ledger as a posting rather than as a figure somebody transcribes from a report at month end.
There are two routes. Employee lines can be routed through payroll, where they become a taxable payslip earning and are treated exactly as employment income should be. Or they can be paid directly, which is the right answer for casual site labour paid outside the payroll cycle — and which carries a limitation worth stating clearly.
What AWRA OpsHub does today
- Drafts built from unpaid logged time, one line per person, pre-filled at the project cost rate.
- Rates editable per line before approval, so different roles on one project are paid differently.
- Only an approved payout can be posted — this is refused rather than discouraged.
- Hours are re-reconciled at posting against currently-unpaid time, so late entries are picked up and the amount is recomputed rather than trusted.
- Posts into the Payments Register and the double-entry journals, so labour cost reaches the ledger as a posting.
- Employee lines can route through payroll and become a taxable payslip earning.
What it does not do
- The direct route records a payment rather than making one. Lines are marked paid and the accounting is correct, but the bank or mobile-money disbursement itself is a separate act you perform. Treat the record as the instruction and the receipt, not as the transfer.
- The attendance lock does not cover project time. Locking an employee's month stops attendance edits, overtime and regularizations — it does not stop project hours being logged into that month, and project hours are what a payout is built from.
- No stored per-person rate. The project cost rate pre-fills every line, and adjustments are made on the payout each time rather than held against the person.
Not ours, by choice
- We will not mark money as having moved when it has not. The direct route says a payment was recorded, and we would rather that be an obviously separate step than have a green tick imply a transfer nobody made.
- We will not let a draft post itself. The approval is a real gate, and a system that let an unapproved payout through on a busy Friday would be removing the only place a second person looks at the figure.
Extending the timesheet lock to project time entries, a per-person rate held against the employee, and a live disbursement rail on the direct route, are all scope rather than ceilings. The lock service, the payout model and the Payments Register integration all exist and work; each is a written specification and a price.
The lock gap is the one to design around before you rely on this for site labour. Locking a month is a real control on the attendance side and it is not a control on the clock you are paying from, so your close process needs a step that checks project hours for the period rather than assuming the lock covered it.
Two clocks, one of them locked
This deserves its own section because it is the kind of thing that is entirely reasonable in design and surprising in practice.
There are two ways time is recorded. Attendance — clocking in and out, overtime, regularizations — belongs to the HR side and can be locked per employee per calendar month. Once a month is locked, those records cannot be edited, which is what makes a payroll run defensible after it has happened.
Project time entries are the other clock. They are logged against tasks, they are what a payout is built from, and they are not covered by that lock. Locking March for an employee does not prevent project hours being entered against March.
Neither behaviour is wrong on its own. Attendance is a payroll record and needs to freeze; project time is a costing record and often needs correcting weeks later when somebody works out which task the work actually belonged to. The problem is only that they look like the same thing from a distance, and a close process built on the assumption that locking covered both will not do what it was designed to do.
What a close process needs to add
- A named person who reviews project hours for the period before the payout is drafted — the lock will not do it for you.
- A cut-off communicated to the site, so late entries are an exception rather than a habit.
- A check on hours logged after the period ended but dated inside it, which is the entry pattern worth looking at.
- A rule about who may log time on behalf of somebody else, and whether that is allowed at all.
- A comparison between attendance days and project hours for the same people. Large divergence is not necessarily wrong, and it is always worth a question.
That last check is the most useful single thing on this list. A person showing twenty-two attendance days and two hundred and forty project hours in the same month is telling you something — possibly that the project log is generous, possibly that the attendance record is missing overtime, and it is worth knowing which.
What this does not fix
Paying from a log improves the arithmetic between the log and the payment. It does not improve the relationship between the log and reality, and it is worth being clear-eyed about that before treating it as a labour control.
If hours are entered by one person on behalf of a gang, the log inherits whatever that person decides. If entries are made weekly from memory rather than daily from observation, the log is a recollection with a timestamp on it. The system will pay faithfully from either, and it will do so with an audit trail that makes the payment look rigorous.
What actually improves the log is the same thing that has always improved it: entries made close to the work, by or in front of the person who did it, with somebody who was there confirming them. The software makes that record durable, attributable and payable. It does not make it true.
The certificate side of paying subcontractors is in subcontractors and certificates, the cost-versus-bill comparison in BQ versus actuals, and the standing-cost argument in preliminaries.
Our take
The payout mechanics are sound — drafts built from unpaid time, rates adjustable per line, approval enforced, and hours recomputed at posting so late entries are caught rather than lost. Two things to design around. The direct route records a payment rather than making one, so the transfer is still your separate act. And the attendance lock does not cover project time, which is the clock you are paying from — so put a named review of project hours into your close process rather than assuming the lock has done it.
See a payout built from logged time
Drafts assembled from unpaid hours, rates adjustable per line, approval enforced before posting, hours reconciled again at the moment of payment, and the cost landing in the Payments Register and the journals.
Explore project payoutsFrequently asked questions
How is a payout calculated?
A draft is built from the project's unpaid logged time — one line per person with hours outstanding, priced at the project cost rate. That rate is a starting point rather than a constraint: each line's rate is editable before approval, so a site agent and a labourer on the same project are not forced onto the same figure. Fixed lines can be added alongside the hours lines for subcontractor sums or one-off allowances.
What happens if hours are logged after the draft is prepared?
They are picked up. When the payout is posted, every hours line is reconciled again against that person's currently-unpaid time and the hours and amount are recalculated — the draft is a proposal, and the log at the moment of posting is what pays. That closes the most obvious gap in any pay-from-log system. It also means the figure you approved and the figure that posts can differ, which is worth knowing rather than discovering on a payment run.
Does posting a payout actually pay people?
Not on the direct route. The lines are recorded as paid and the accounting is correct — it lands in the Payments Register and posts to the journals — but the bank or mobile-money disbursement is a separate act you perform. Read the record as the instruction and the receipt rather than as the transfer. Employee lines routed through payroll are a different matter: those become a taxable payslip earning and follow your payroll cycle.
Can we lock a period so nobody changes the hours afterwards?
Partly, and the limit matters. An employee's calendar month can be locked, which prevents attendance edits, overtime and regularizations for that month — that is what makes a payroll run defensible after the fact. Project time entries are a separate clock and are not covered by that lock, so hours can still be logged against a locked month. Since project hours are what a payout is built from, your close process needs a named person reviewing them rather than an assumption that locking covered it.
Why are attendance and project time separate at all?
Because they are different records serving different purposes. Attendance is a payroll record and needs to freeze once a run has happened. Project time is a costing record and frequently needs correcting weeks later, when somebody works out which task a piece of work actually belonged to. Freezing that would make accurate job costing impossible. The difficulty is only that the two look alike from a distance, so it is worth being explicit internally about which one you are talking about.
Does paying from logged hours stop time being inflated?
It stops the arithmetic between the log and the payment from drifting, which is real and worth having. It does nothing about the relationship between the log and reality. If hours are entered weekly from memory by one person on behalf of a gang, the log is a recollection with a timestamp, and the system will pay from it faithfully and produce an audit trail that makes the payment look rigorous. What improves a log is entries made close to the work, in front of the person who did it, confirmed by somebody who was there.
