Connecting JobTread to QuickBooks Online

If you run construction jobs in JobTread and your books in QuickBooks Online, you already know the shape of the problem. A job gets set up twice. Costs get entered twice. Somebody exports a spreadsheet at month-end to work out what a job actually made, and by the time the answer arrives the job is finished and the money is spent.

The usual response is to go looking for an integration. What most people find is either a generic connector that syncs the easy fields and quietly mangles the hard ones, or a quote from a developer who has never closed a construction month and doesn’t know which fields matter.

This is a walkthrough of what actually has to be decided, and where these projects go wrong. It is deliberately not a click-by-click tutorial, because the clicking is the easy part.

The real problem: two different models of your business

JobTread and QuickBooks are not two copies of the same data with different logos. They are two different opinions about how a construction business is structured, and the integration lives or dies on how you reconcile them.

JobTread thinks in	QuickBooks thinks in
Jobs	Customers, and optionally Projects or sub-customers
Cost Groups	Accounts, Classes, or Items — depending on how you set it up
Cost Items with a unit, quantity and unit cost	Line items on a bill or an expense
Estimates that evolve into budgets	No native budget concept at the job level
Documents attached to a job	Attachments on a transaction

Read that table again, because it contains the whole difficulty. JobTread has a first-class notion of a job with a budget broken into cost groups. QuickBooks has a first-class notion of a transaction that hits an account. Neither one is wrong. They are answering different questions.

The mapping decisions nobody warns you about

1. Jobs to Customers, or Jobs to sub-customers?

If a customer only ever has one job, mapping a job to a customer is tempting and fine. The moment a repeat client has three jobs running, that model collapses — you can no longer see profitability per job without manual filtering.

Sub-customers (or Projects, in newer QuickBooks plans) solve it, but they have to be created in the right hierarchy from the start. Retro-fitting this across two years of history is a genuinely miserable weekend.

2. Cost codes drift, and nothing tells you

Your JobTread cost groups will not stay identical to your QuickBooks chart of accounts. Someone adds a cost group for a one-off. Someone renames an account. Three months later a chunk of spend is landing somewhere nobody looks at.

A working integration needs an explicit mapping table — not implicit name matching — and it needs to fail loudly when it meets a code it doesn’t recognise. Silent fallbacks to a “Miscellaneous” bucket are how job costing quietly becomes fiction.

3. Which system is the source of truth?

For any given field, exactly one system wins. Write this down before anyone writes code:

• Budgets and estimates — JobTread. Accounting has no business setting a budget.
• Actual costs — QuickBooks, because that is where bills are paid and where the auditor looks.
• Job status and schedule — JobTread.
• Customer billing details — usually QuickBooks, but pick one.

Two-way sync on the same field is not a feature. It is a race condition with a marketing page.

4. The transactions that break everything

Straightforward bills sync fine. These are the ones that generate the support calls:

• Deposits and progress billing — money received before work is done isn’t revenue yet, and job-costing it as such inflates margin.
• Change orders — they change the budget, not just the invoice. If only the invoice syncs, budget-vs-actual silently drifts.
• Retainage — billed but not collectable yet. It belongs in a separate account, not in AR.
• Credit card and vendor credits — negative lines that many naive integrations skip entirely.
• Split bills — one supplier invoice covering four jobs. Common with lumber yards; a real headache if the integration assumes one bill equals one job.

What a good integration actually does

Once the mapping is settled, the mechanics are unglamorous and should be:

1. Sync on a schedule, not on every keystroke. Both platforms rate-limit. Batched, scheduled syncs are more reliable and far easier to debug than event-driven chatter.
2. Make every sync idempotent. Running it twice must not create two bills. This means storing a durable reference to the remote record, not matching on amount and date and hoping.
3. Keep an audit log. When a controller asks why a cost landed where it did, the answer should take thirty seconds, not an afternoon.
4. Surface exceptions to a person. Unmapped cost codes, failed pushes and ambiguous matches belong in a queue someone reviews — not buried in a log file.
5. Authenticate properly and store tokens encrypted. QuickBooks uses OAuth 2.0 with refreshing tokens. If your integration asks anyone to paste a password, walk away.

Do you need custom work, or will an off-the-shelf connector do?

Genuinely, sometimes a connector is enough. Use one if you run a simple chart of accounts, one job per customer, few change orders, and you mostly want costs to stop being typed twice.

You'll want something built if any of the following are true:

• You need budget-vs-actual per cost group, live
• Repeat customers run several concurrent jobs
• Retainage or progress billing is a normal part of your contracts
• Supplier invoices routinely cover multiple jobs
• You want the data to feed dashboards, not just the ledger

This isn’t theoretical for us

Everything above comes from running the function, not observing it. Buildology spent two years embedded at a Greenville contractor as fractional sales executive and CFO — closing the months, owning the cost codes, and building the software from inside the business when the market didn’t have what was needed.

That engagement was sales process, quoting and CRM rather than this particular integration — but it is the same discipline. You cannot map cost groups to a chart of accounts sensibly unless you have had to answer for the resulting margin report.

Where to start

Before anyone writes a line of code, put these on one page: your JobTread cost groups, your QuickBooks chart of accounts, and an honest note against each row saying which system owns it. Most of the value of an integration project shows up during that exercise, and it costs nothing but an afternoon.

If the two lists don’t line up — and they almost never do on the first pass — that gap is the actual project. The code is the easy part.