Product
Three mechanisms, and what each one is for.
Every connector in the marketplace syncs customers and invoices. These are the three things Handled does that the native connector cannot, described plainly enough that you can check them. Every figure below is from the demo company’s sandbox jobs.
1. Cost, attributed at line level
Handled reads QuickBooks® Online at bill-line granularity rather than bill level. A bill header is a vendor, a date and a total; it contains no job at all. The job coding lives one level down, on each line. Read the header and an $11,000.00 bill is attached to nothing. Read the lines and 1042 Birchwood Lane carries $6,100.00 while 88 Halsted Avenue carries $4,900.00.
Costs roll up by cost code onto the HubSpot deal alongside contract value, and the drill-down reconciles to the rollup to the cent.
Two margins, carried separately
Margin at completion assumes the job finishes as costed. Realised margin counts only money actually billed or received on the job — invoices, sales receipts and customer deposits, less credits and refunds — and stays withheld until there is some. A single margin figure that quietly counts unbilled work is a wrong number on a finance screen, so Handled refuses to compute one.
Unpriced labour is reported as a gap rather than costed at zero. A total that does not yet know something says so.
2. An approval gate on everything that posts
Handled computes a milestone invoice from the billing schedule and proposes it. Nothing reaches QuickBooks until a person approves that proposal, unless someone in your portal switches on automatic posting, which is off by default. Any user in your HubSpot portal who can open the card can do either. With it on, that standing rule is the approval, and invoices post without anyone reviewing them one by one. Either way, a changed amount requires a fresh approval rather than inheriting the old one.
The gate is in the database, not the interface. A proposal row cannot hold a status of approved, posting or posted unless it also carries an approval timestamp and a named approver, either a user id or an email address. It is a check constraint, so it is enforced by Postgres on every write, including ours. So every posted invoice carries an approval record: the person who approved it, or the automatic-posting rule that did.
This is the part that makes the rest safe to trust. A connector that writes to your accounting system without a checkpoint is a connector you have to audit.
3. One deal, one QuickBooks job
Contractors track a property as a sub-customer under a parent customer. Intuit’s API has always supported it. The native HubSpot connector cannot create one, so every job lands flat against the parent and job-level reporting in QuickBooks stops working.
Handled links each deal to the job you already keep in QuickBooks, so one homeowner can hold four properties and each one keeps its own costs, its own schedule and its own margin. Creating that job from the deal is marked Next: today you create it in QuickBooks, then link the deal to it from the deal’s card.
And then what happens to it
A posted invoice is mirrored back into HubSpot as a native invoice on the deal, with its line items, its associations and its real status. When QuickBooks records a payment, Handled reads it back and the deal follows. Deleting that payment in QuickBooks walks the deal back to unpaid, but HubSpot’s own payment record stays “succeeded”, so Handled flags the invoice for review; that walk-back is still in testing.
Delivery is reported honestly. If QuickBooks says an emailed invoice bounced, Handled shows that rather than claiming it was sent. A paid invoice locks: no edit, no recall.
Against the connector HubSpot ships
The native QuickBooks connector is free and, for contacts and simple invoices, genuinely fine. The differences that matter to a contractor are structural rather than a matter of polish. The full comparison runs row by row, with the capability status of every claim on our side.
What is built, and what is not
Some of what is described here runs and is verified, some ships but is still being proven, and some is next. The documentation marks every capability with its status, and nothing on this site claims a capability that does not exist.