Most construction software integrates with QuickBooks. The sales page says so. The demo shows a button labeled “Export to QuickBooks.” The implementation consultant nods.
What the demo doesn’t show is what happens when a specialty sub with 22 cost codes, three active jobs, and a payroll that runs every Friday tries to reconcile his field time tracking data with his QuickBooks job cost report at month end. The integration that looked clean in the demo is exporting hours by employee to a payroll file. The PM’s phase-level cost data — ELEC-ROUGH at 140% of budget on the hospital job, ELEC-PANEL tracking clean on the school — isn’t flowing anywhere. It’s sitting in the time tracking system, separate from QuickBooks, readable only in the field tool.
The construction QuickBooks integration that matters for a specialty sub isn’t payroll export. It’s job costing: hours by cost code, by job, by phase, flowing into QuickBooks so the controller sees actual vs. estimated without a manual reconciliation every month.
Those are two different integrations. Most tools only do one.
The Two QuickBooks Integrations — and Why Most Tools Only Deliver One
Payroll export. Hours by employee, by pay period, in a format that loads into QuickBooks Payroll or flows to the payroll processor. The office manager approves and the crew gets paid. This is the integration most field tools deliver. It’s straightforward: total hours, overtime flag, job if the tool supports it.
Job costing integration. Hours by cost code, by job, mapped to the cost items in QuickBooks so the job cost report shows actual vs. estimated by phase. This is the integration that helps the PM run the job. It requires that the field tool captures cost codes at clock-in — and that those codes map cleanly to the QuickBooks item list or class structure.
A specialty sub needs both. Most field tools deliver payroll export and call it a QuickBooks integration. The job costing piece — the one that tells the PM whether PLMB-UG is 12% over budget before the slab pours — requires a tool that captures cost codes in the field and maps them to QuickBooks job cost items on export.
What the Cost Code → QuickBooks Flow Actually Looks Like
When the integration works, here’s what runs:
Step 1: Cost code assignment at clock-in. The foreman clocks in his crew and assigns the phase code for the day’s work — MECH-PIPE for piping rough-in, MECH-COMM for commissioning, ELEC-ROUGH for electrical rough-in. One step, at the point of work, before the crew disperses to the building. The code is attached to every hour logged that day.
Step 2: PM reviews and approves. At the end of the week, the PM reviews the time entries by cost code. He can see that MECH-PIPE has logged 280 hours this week against a weekly budget of 240 — 17% over. He approves the entries and flags the variance before the payroll runs.
Step 3: Export to QuickBooks. The approved hours export to QuickBooks in two formats simultaneously: a payroll file with hours by employee (for QuickBooks Payroll or the external payroll processor) and a job cost file with hours by cost code mapped to QuickBooks items (for the job cost report). The controller imports both. The crew gets paid. The job cost report updates.
Step 4: Actual vs. estimated by phase, visible in QuickBooks. The controller — or the PM, if he has QuickBooks access — can pull the job cost report and see that MECH-PIPE is at $42,800 actual against a $38,000 estimate: 12.6% over. The MECH-COMM (commissioning) phase is at $8,200 actual against a $15,000 estimate: running ahead. The mechanical PM knows where the job stands by phase, in his accounting system, without a separate reconciliation.
When the integration is payroll-only, Step 3 produces the payroll file. The job cost file doesn’t exist. The controller has hours by employee in QuickBooks. The PM has cost codes in the field tool. Nobody has actual vs. estimated by phase in one place, and reconciling them requires a manual export, a spreadsheet, and someone’s Friday afternoon.
What Breaks Without the Job Costing Integration
The PM can’t see the job in QuickBooks. The controller’s QuickBooks shows total labor cost by job. The PM’s field tool shows hours by cost code. They’re looking at the same job through different windows that don’t connect. The PM trusts his field tool. The controller trusts QuickBooks. At closeout, they reconcile, find the gap, and neither one can explain it.
The next bid is a guess. Job costing at the phase level is how a specialty sub builds a real productivity database. If ELEC-ROUGH ran at 1.4 hours per circuit on the hospital job, the electrical PM knows his estimate for the next hospital job. If electrical labor is tracked as a single number — total electrical hours, total electrical cost — the next bid gets a percentage adjustment and a prayer. The job costing data that would tighten the estimate stays trapped in a field tool that doesn’t talk to QuickBooks.
Change order conversations go wrong. The PM wants to submit a change order for the conduit reroute on Floor 4. His field tool shows ELEC-ROUGH on Floor 4 is 340 hours over the estimate for that zone. His QuickBooks shows nothing — just total electrical labor is over budget, with no zone breakout. The change order conversation with the GC is about a number the PM can explain but can’t show in his accounting system. The GC’s accountant asks for the job cost backup. The PM’s backup is a screenshot from a field tool the GC has never seen.
How to Evaluate a Field Tool’s QuickBooks Integration
Ask what exports to QuickBooks — hours by employee, or hours by cost code mapped to items? If the answer is only employee hours, it’s a payroll integration. Job costing is separate.
Ask how cost codes map to QuickBooks items. In QuickBooks, job costing runs through the Items list (for service-item-based job costing) or the Class list (for class-based tracking). The field tool’s cost codes have to map to one of those. If the vendor can’t tell you which QuickBooks structure their export targets, the integration probably requires manual remapping every time.
Ask what happens when you add a cost code mid-job. You’re three months into a 12-month job and you realize you need a separate code for the mechanical room piping. You add MECH-MROOM in the field tool. Does the QuickBooks integration pick it up automatically, or do you have to map it manually? A job that runs 12 months will have code additions. The integration that requires manual remapping for each new code gets abandoned by month four.
Run a test export before committing. Have the vendor create a test job with three cost codes, log an hour to each, and export to a demo QuickBooks account. Look at the QuickBooks job cost report. Does it show three line items by cost code? Or one line item for total labor? The answer tells you whether the integration is what they described.
The Accounting System as a PM Tool
The specialty sub PM who has phase-level job cost data in QuickBooks — not just in a field tool — is running his job from his accounting system. He sees that ELEC-PANEL is at 138% of budget in week 35 of a 38-week job. He has three weeks to submit a change order while the job is still open. The sub whose electrical panel labor is buried in a total — visible in QuickBooks only as “electrical labor, $142,000” against a budget of $103,000 — finds out at closeout and has nothing to submit.
The difference between those two PMs isn’t accounting sophistication. It’s whether the QuickBooks integration captures cost codes or just payroll hours.
See how LogLoon’s QuickBooks integration handles cost codes for specialty contractors, or check the pricing — it’s on the website.