One connection to your own QuickBooks company. Send an invoice and it lands in your books. Countersign a contract and the job lands there too, ready for job costing. A payment your bookkeeper records comes back and marks the invoice paid here. Switch on Send bills to QuickBooks and the other side of the ledger follows: an accepted sub PO or a supplier's bill becomes a QuickBooks bill against the job, split by cost code, and its payments go both ways. And QuickBooks being down never blocks you — every step is best-effort. Everything else about the post-frame business runs in one place; your bookkeeper keeps the books where she already keeps them.
Also called: quickbooks · QBO · connect my accounting · sync with my bookkeeper · accounting software
Your bookkeeper never has to open this software
One connection, made once, to your own QuickBooks company — and after that the invoices, the customers and the jobs arrive in the books without anybody typing them again. QuickBooks sits on the same tab as your CRM, your estimating tool and your card processor, and the tab, the stored keys and the PIN on them are covered on the integrations tab.
You bought field software and the bookkeeper still wants it her way, so the last Friday of every month somebody sits re-typing eleven invoices into QuickBooks off a printout.
Your bookkeeper is not switching — and shouldn't have to. So the accounting side is an extra on top of a system that already works without it: connect it and the typing stops; leave it off and nothing is missing.
Sending an invoice puts it in your QuickBooks company, once
The invoice is copied into your own QuickBooks file with the same number, due date, memo and total, posted against the item and income account you mapped. It records that it has been pushed, so it never happens twice, however many times a send gets retried. Building the bill off the estimate and the draw schedule, picking the lines, and fixing a wrong one all happen on the invoicing screen — this page picks up from where you press send.
A send times out, somebody presses it again, and the customer gets a second copy of a $51,000 draw invoice — then rings to ask which one he owes.
A customer should never get two copies of a $51,000 draw because a send timed out. The QuickBooks id is stamped on the invoice the moment it lands and every later push checks it first — the copy in the books is the invoice as it was sent.
Your lines here, one total line in the books
The invoice carries its own lines here — draw, change order, services. QuickBooks receives one line for the total, described by the invoice title and posted against the item and income account you picked in the mapping panel. Until an item is mapped, the push refuses and says so by name rather than guessing.
An import writes eleven made-up income accounts into the books, and the accountant spends the close unpicking your naming out of a P&L he has to file.
The chart of accounts belongs to your bookkeeper, and she will thank you for not filling it with ours. One item and one income account is a decision she makes once and can check in a minute; per-line categories stay where your cost coding already lives.
A payment your bookkeeper records in QuickBooks marks the invoice paid here
Try itQuickBooks tells us the moment an invoice or a payment changes, the balance is copied onto the matching invoice — part paid, or paid in full — and the job moves with it. The figure is set outright, never added to, so a repeated message cannot apply twice.
The cheque is deposited and posted on Tuesday, and on Thursday somebody rings the customer about an invoice he has already paid.
Nobody should ring a customer about a bill he paid on Tuesday. Once the invoice is in the books, the books are the authority on money — the balance is read whole from QuickBooks, so a repeated message can never apply twice.
A message that never arrives is not how you find out you were paid
Try itAlongside the live notification, every invoice carrying a QuickBooks id has its balance re-read on a schedule — paid ones included, because a refund or a deleted payment puts a balance back. An invoice you recorded by hand is never touched.
One notification is lost during a deploy, the invoice sits at 'sent' for a month, and the collections call goes to the man who paid in full three weeks ago.
You should never find out you were paid by noticing a message didn't arrive. Alongside the live notice, every invoice with a QuickBooks id is re-read on a schedule, so a lost notification can't leave a paid bill reading unpaid.
You can see whether a job actually reached QuickBooks, and retry it
A chip on the job reads Synced, Syncing, or Sync failed — with a Retry beside it — and names what was made in the books: a project, a sub-customer, or the customer alone. A scheduled sweep re-drives anything that errored, was never synced, or was left half-done by a process that died.
A worker dies mid-sync, the job never reaches the books, and nobody finds out until the accountant asks in January where the Route 372 shop went.
The office wants to know, without asking, whether a job made it into the books. The state is written on the record — Synced, Syncing or Sync failed — with Retry beside it and an automatic re-drive for anything stuck.
QuickBooks being down costs you a warning, not a blocked invoice
Every QuickBooks step is best-effort. If the push fails, your send to the customer has already succeeded, the reason is stored on the invoice, and you get a warning rather than a failure. The platform runs with or without QuickBooks connected — which is also what makes it safe to be halfway through switching.
Intuit has an outage on the 30th, and the delivery draw that pays for next week's steel cannot leave the building.
A customer waiting on a bill should never wait on your accounting software. The customer-facing send runs first and the books second; if QuickBooks is down you get a warning beside the invoice, not a blocked send.
Customers get matched before they get created
Try itIt checks what it already knows first — no call at all — then the email address, then the display name, which is what catches customers your bookkeeper created directly in QuickBooks. Only then is a new one made. It works off the billing block on the invoice, so a customer with no contact record of their own still matches.
The books grow three Brad Garbers, and the aged receivables report splits one man's money across all of them.
Duplicate customers in the books are a bookkeeper's nightmare. Matching runs on what we already know, then email, then name — because the bookkeeper types customers straight into QuickBooks and always will.
Countersigning a contract puts the job into QuickBooks for job costing
Where your plan allows it, the job becomes a real QuickBooks project whose status moves when the build is started. Where it does not, it becomes a sub-customer — and failing that, the customer alone. Counter-signing itself belongs to the contract engine; this page picks it up at the moment the document goes fully executed and the job lands in your books.
The lumber bills for the Route 372 shop land in the books with nothing to code them against, and job costing for that build becomes a spreadsheet somebody builds in March from memory.
Job costing starts when the job is real — the moment you countersign. The job lands in QuickBooks then, so the bookkeeper can code costs to it from day one without asking you to set it up.
Works on any QuickBooks plan — and says what your plan keeps in QuickBooks
The card reads back the company you are attached to, the plan it detected, and when it last moved anything. On a Simple Start or Essentials file it says plainly that per-job profit reports and change orders inside QuickBooks itself need QuickBooks Plus — and that everything in Leads 2 Build works on any QuickBooks plan, so nothing quietly does nothing.
A feature that fails silently on your plan is worse than one that says so: you find out in the reports, in a quarter you cannot go back and re-run.
You shouldn't have to know which QuickBooks plan you're on for this to work. The plan is inferred and treated as a floor, never a reason to switch something off — the better option is tried first, and QuickBooks is allowed to say no.
They pay through your books without leaving your page
Try itThe Pay button sits on your own branded invoice page, and the money runs through your QuickBooks. You choose bank transfer only or bank transfer and card, because card is a percentage of the whole invoice. QuickBooks emailing its own copy is off unless you switch it on, so the customer gets one bill from you rather than two within a minute of each other.
The customer presses Pay on a $51,000 invoice and lands on a page that does not exist, and now your bill looks broken.
A customer who can pay the moment he reads the bill usually does. The pay button only shows when QuickBooks has a real payments account behind it — checked when the link is stored and again when it's shown — so nobody presses a dead link.
Outstanding here means outstanding there
Outstanding, overdue and paid on this screen are built from balances QuickBooks set, not from a status somebody remembered to change. The draw schedule decides what gets billed; the books decide what has been collected.
The receivables number on your screen and the one your accountant reads out on the phone are four thousand dollars apart, and neither of you can say which is wrong.
Two systems that each keep their own opinion of who has paid will disagree within a month. Once an invoice is in the books this side stops keeping an opinion, so what's outstanding here is what's outstanding there.
Sub and supplier bills go to QuickBooks only when you switch it on
Try itIn Settings → Subs & Purchasing, QuickBooks bills stays off until you switch on Send bills to QuickBooks — and it does nothing unless QuickBooks is connected too. Pick the default expense account the bills post to and the bank account payments come out of. Invoices sync exactly as before either way.
A new setting starts posting bills into the books the day it appears, against accounts your bookkeeper never picked.
A bookkeeper should never find bills in the books that nobody told her were coming. Off until the owner switches it on means the day it starts is a decision, made once, with the accounts she chose.
A line per cost code, against the job
When a sub accepts their subcontract PO — or any purchase order is marked invoiced — it becomes a QuickBooks bill to that vendor, with one line per cost code, each tagged to the job's customer. Each code posts to the account you map — 03 Concrete to Concrete Subs here — or to your default. The sub or supplier is matched to a vendor by name or added as one, and tax and freight get a line of their own. It's what keeps job costing the same story in both places.
Your bookkeeper types every sub's bill into QuickBooks by hand, guesses the job, and by spring the two sets of job costs disagree.
Job costing only agrees when the bill lands on the right job, in the right bucket. Splitting each bill by cost code and tagging it to the job means QuickBooks' job reports and the committed cost here tell the same story without anyone re-keying it.
See which POs made it into the books
On the job's Subcontracts card, each PO says In QuickBooks once its bill is there — or, if QuickBooks turned it down, the reason in plain words. A PO still awaiting the sub has no bill yet, because nothing is owed until they accept.
Nobody knows whether the concrete sub's bill is in the books until the bookkeeper asks at month end.
The office shouldn't have to open QuickBooks to know whether a bill made it. One line on the PO row answers it, on the job where the question comes up.
Pay it here or pay it there — it shows in both
Record a payment on the PO and it goes to QuickBooks as a bill payment from the account you picked. Pay the bill in QuickBooks instead and, within the hour, it appears on the PO marked made in QuickBooks. Delete a payment here and its QuickBooks copy goes too — but a payment made in QuickBooks is never deleted from this side. If QuickBooks refuses a bill, the PO says why, with Update in QuickBooks beside it.
The office cuts a check for the concrete sub while the bookkeeper pays the same bill online, and nobody notices until the sub calls about the extra money.
Paying a sub twice is the most expensive mistake an office makes. When payments from both places land on the same list, "what do we still owe Cornerstone" has one answer, whoever entered the money.
- 1Connect your QuickBooks company once, from settings.
- 2Map the item and income account your invoices should post against.
- 3Send an invoice and it appears in your books, same number, same total.
- 4Your bookkeeper records a payment there, and it marks paid here.
- 5A chip on the job reads Synced, Syncing or Sync failed — with Retry beside it.
- 6Switch on Send bills to QuickBooks and an accepted subcontract PO, or a purchase order marked invoiced, goes across as a bill to the vendor — a line per cost code, against the job.
- 7Payments follow the bill both ways — recorded here they post as bill payments; paid in QuickBooks, they show up on the PO within the hour.
Builders already run their books in QuickBooks, and their bookkeeper is not switching. But a platform that demands it locks out everyone who does not use it. So everything works with or without it connected — and when it is connected, a QuickBooks problem shows up as a warning, not a failed send: the invoice still reaches your customer. It is also pinned to one published version of the QuickBooks interface, because otherwise behaviour changes without warning on somebody else's release schedule. The same went for the other side of the ledger. The bookkeeper was re-keying every sub and supplier bill into QuickBooks against the right job, so job costing there would agree with job costing here. Now an accepted subcontract PO, or a purchase order marked invoiced, becomes the bill — one line per cost code, against the customer's job — and the payments follow it. It stays off until the owner switches it on, because new entries appearing in somebody's books should always be a decision.
- Double data entry between the field system and the books.
- Customer records diverging between two systems.
- An accounting outage blocking day-to-day work.
- Sub and supplier bills keyed into QuickBooks a second time, against a guessed job.
Connect and disconnect QuickBooks
The standard QuickBooks sign-in. Your company name and plan come back with it. Disconnect revokes at Intuit first, then clears everything on our side. Project tracking is asked for separately, on purpose.
QuickBooks emails the invoice with its own pay link
A follow-up send from inside QuickBooks. If you have QuickBooks Payments turned on, that email carries their pay button — bank debit or card — alongside your own invoice link. If the email hiccups, the invoice still exists in your books; only the email is retried.
Sync status, retry, and an automatic re-drive
Two halves. The chip turns an otherwise silent background job into something you can see, with a manual retry sitting on it. The sweep independently picks up anything that errored, never synced, or was left half-done by a process that died.
Sub and supplier bills to QuickBooks, against the job
Opt-in from Settings → Subs & Purchasing. The sub or supplier is found or created as a Vendor; each cost code posts to the default expense account or one you map; the bill lines carry the project's customer:job. Payments recorded here become bill payments from the bank account you pick, and payments made in QuickBooks against the bill are mirrored back every hour. Every QuickBooks id is stored, so nothing is sent twice.
