QuickBooks Online project labour costs: two methods, one timing trap
QuickBooks Online offers two ways to cost labour on a project, and each posts at a different time; here is how to set them up and read the result.
A familiar complaint reaches the desk from QuickBooks Online users who have switched on Projects: the report shows income, purchased costs sit in place, and labour is either missing or thin. The question of how to track hourly labour costs per project has a formally accepted answer. That answer treats the gap as intended behaviour rather than a fault. It comes down to two costing methods that post at different moments.
Two costing methods, two clocks
Payroll expenses are the first method. They capture the true cost of running payroll: gross wages, employer taxes, and additions such as workers’ compensation cover. There is no rate to configure for this method; the amounts draw on the wage and tax accounts already in your books. The catch is timing. With QuickBooks Online Payroll, those amounts attach to a project only after you run payroll. A report taken mid-month will understate what a job really costs.
Estimated hourly costs are the second method. You set a fixed rate per employee, and the software multiplies that rate by the hours logged on each timesheet. The numbers appear immediately, which makes them useful between payroll runs. They can also absorb costs payroll never touches, like office electricity or site consumables. The trade-off is precision: an estimate stays an estimate.
Neither method needs the other, and you can switch the report between them whenever it helps.
Does the payroll method work with payroll run elsewhere?
The accepted answer opens by saying both methods suit you whether payroll runs inside QuickBooks or elsewhere. Its own detail narrows that claim. Only payroll processed through QuickBooks Online Payroll posts to a project automatically. If wages are calculated by another provider, nothing flows into the project report on its own. In that situation the hourly estimate is the practical method, or you record the payroll costs against the project yourself.
How do you set an hourly cost rate?
Order matters here. A rate applies only to time tracked after you save it, so set rates before anyone logs hours. Hours already on the books keep no estimated cost, and there is no backfill.
Open Projects from the All apps menu in QuickBooks Online. If the app is missing, add it from that menu first. Select Hourly cost rate, then Add hourly cost rate. Pick the employee, type the rate, and save. Repeat for every person who will bill time to projects.
Building the rate is your call. Take the hourly wage, add the hourly share of taxes and insurance, and fold in overhead if you want it reflected. QuickBooks does no maths of its own here; it simply multiplies your rate by tracked hours.
Timesheets carry the hours to the project
Both costing routes follow time, so timesheets are the engine of the whole exercise. Open Timesheets from the All apps menu and start a timesheet for the week. Choose the employee, tag the entry to the project, and record the hours worked. This tracked time is what the rates multiply against. It is also what payroll matches to when it later posts real costs.
Where do the labour costs finally appear?
Go back to Projects and open the report for the job. A Project costs menu on that report switches the view between hourly cost and payroll expenses. That single toggle explains most of the confusion. The two figures differ by design, and each shows whichever method you last selected.
Profitability sits in the project overview beside those costs. Once income, supplier costs, and labour all attach to the project, the report surfaces hours worked, income against costs, and a gross margin. Between paydays the hourly-cost view gives the honest interim picture. After payroll runs, the payroll-expense view becomes the accurate one.
The two traps worth remembering
First, rates are never retroactive. Time logged before a rate existed carries no estimate, so set rates early on every project. Second, timing drives the payroll view. Labour posts only after payroll is processed, so the same report can look different on consecutive days for no visible reason.
Users who absorb those two points stop treating Projects as broken and start using it as designed: an estimate during the month, and the real payroll numbers after it.