Per-person detail
Gross, employer taxes, benefits, and deductions per person per period, which is what makes any subsequent allocation possible.
Services · integration
For most companies people cost is between forty and seventy percent of the P&L, and it arrives in the ledger as a handful of summary journal lines with no department, no project, and no way to answer what a team or an engagement actually costs.
Tell us your payroll provider and how labour is currently posted. We will scope it.
The situation
Per-person, per-pay-period detail with the dimensions attached, rather than a summary journal you cannot decompose.
Gross, employer taxes, benefits, and deductions per person per period, which is what makes any subsequent allocation possible.
Department, location, entity, and where time data exists, project — so labour cost lands where it was incurred rather than in a single overhead pool.
Salary plus employer taxes, benefits, and a configured overhead allocation, per person, which is the number every margin calculation actually needs.
Payroll accrual for the days between the last run and period end, computed from actual pay data rather than estimated from last month.
Where you run Harvest, Jira, or a timesheet system, hours are joined to cost so project margin becomes computable rather than approximate.
Individual compensation is field-level restricted. Most people who need departmental labour cost should not see individual salaries, and the model enforces that rather than trusting it.
Payroll providers post a summary journal because that is what the accounting integration was designed to do a decade ago, and because most accounting systems could not usefully receive anything richer. The result is that the single largest cost in the business is the least analysable thing in the ledger.
Everything downstream inherits that. Department P&L is an allocation guess. Project margin uses a blended rate. Headcount planning runs off a spreadsheet maintained separately from the actual payroll. None of those are hard problems once the underlying data is not flattened.
A blended rate applied across a team systematically misrepresents both directions: work staffed with juniors looks less profitable than it is, senior-heavy work looks better. For a services business, where staffing mix varies by engagement, the distortion is large enough to change which clients you would want.
Per-person loaded cost — salary, employer taxes, benefits, and a stated overhead basis — is more setup and it is the input every honest margin figure requires.
When a pay period does not align to month end, somebody estimates the accrual, and next month somebody reverses it and estimates again. Derived from actual per-person pay data and days elapsed, it is exact and it stops being a recurring judgement.
Payroll integration is where field-level permissions stop being a checkbox. Department heads need departmental labour cost and should not see individual salaries. Project managers need project cost and should not see rates by name.
Because exposure is enforced in the data layer rather than in the interface, that separation holds through reports, exports, and the copilot rather than only on the screen it was configured on.
Where to start
What arrives in the ledger today, at what grain, and what dimensions exist upstream but are being discarded. Usually more than expected.
Employees and contractors mapped to departments, entities, and where relevant projects, including the ones who genuinely split across several.
Employer taxes, benefits, and the overhead basis agreed and applied. The basis is a decision your controller makes and we record on every report.
Twelve to twenty-four months loaded and reconciled to the summary journals already posted, so history becomes analysable rather than starting from now.
Questions
Tell us your payroll provider and how it posts today. We will scope it in a week.