Project payroll
Payroll on the project that paid for it: labour cost allocation
Site staff are the largest cost most construction projects never see. Payroll is paid from head office, posted as one company expense, and the project profit and loss quietly omits it. Allocating labour cost to the project that employed it is what makes a project result complete — and it has to survive the person being moved next month.
Last revised
The cost the project P&L usually misses
Contractor bills are attributed to a project because they cannot be anything else — the contract names it. Payroll is different. Employees are paid by the company, from one bank account, in one run, and the natural posting is one salary expense against the company. Every site engineer, supervisor and storekeeper then disappears from the project they were working on, and the project profit and loss reports a margin that does not exist.
The fix is not a second payroll. It is an allocation: a statement, per employee, of which project or projects their cost belongs to, that the payroll run reads when it posts.
The allocation: effective-dated, by percentage, per employee
In BuilderOne’s HR & Payroll module an employee carries an allocation history: from a given date, this employee’s cost belongs to these projects in these proportions. Three shapes cover almost every case:
| Situation | Allocation | Effect on a payroll run |
|---|---|---|
| Dedicated to one site | One project at 100% | The whole employer cost of that employee posts to that project. |
| Shared between sites | Two or more projects by percentage (60% / 40%) | Each expense line is split in those proportions, each carrying its own project. |
| Transferred | Project A until a date, Project B from the next day | Runs before the date post to A, runs after to B; the history is preserved, never overwritten. |
| Head office | An explicit non-project allocation | Cost posts with the company’s department dimension and a stated “no project” scope — a decision, not an omission. |
The last row is the one that matters most. An employee with no allocation at all is not quietly treated as head office: the payroll run refuses to post until somebody has decided. That is the difference between “this cost belongs to no project” and “nobody has said” — and the project result is only complete when the second state no longer exists.
The run snapshots the allocation — so history stays put
Allocations change: people move between sites, sometimes with a back-dated instruction. If the payroll posting read the allocation live, changing an employee’s project today would silently rewrite the project profit and loss for every month already posted. So the run takes a snapshot. The allocation effective on the run’s period is copied into the run when it is calculated, and that copy is what posts.
The test of this is simple and was performed on the product: change an allocation with an effective date back inside an already-posted month, and the posted month’s project profit and loss is unchanged. The change applies to the next run. A closed accounting period would refuse the posting anyway; the snapshot means it never has to.
Which parts of payroll become project cost
Not every line of a payslip is a cost to the employer. The allocation applies to the lines that are:
- Employee earnings — base salary and every earning component — are expense, attributed to the project(s).
- Employer-side contributions are expense, attributed the same way.
- Employee-side deductions are not an employer expense at all. They reduce what is paid to the employee and create a liability to whoever the deduction is owed to; they carry no project.
- The net payable to employees, and the statutory or other liabilities, are credit lines. They carry neither a project nor a department: paying people is not a project cost — employing them was.
So project-attributable labour cost is exactly gross earnings plus employer contributions, split by the allocation. When the run is later settled — cash leaves the bank — that posting clears the payable and touches no project, so paying wages late or early never moves a project’s result.
Two dimensions on every expense line
Each payroll expense line in the general ledger carries both a department and a project. The department is mandatory on expense lines — a run with an employee in no department will not post — and the project comes from the allocation. The two are independent: a site engineer in the Engineering department on Project A is reported under Engineering in the company view and under Project A in the project view, from the same line.
The consequence that finance teams check first: the company profit and loss does not change. Allocation redistributes the same expense across projects; the company total salary expense for the run is exactly the run’s gross, whether or not a single employee is allocated. Project reporting gains a cost; company reporting loses nothing.
What this does to project profitability — and what it does not claim
With labour allocated, a project’s cost position and profit and loss include the people who built it, at their actual employer cost, in the month they worked. For the Construction module that means a contractor-heavy project and a self-performed project become comparable; for Investor Management it means a certified project profit that has not quietly excluded the site team.
Where this lives in BuilderOne
See it on your own numbers
The fastest way to judge whether this is how your software should work is to put a real project through it. Tell us what you run and we will set your company up.
