Job costing that runs between Autodesk Build and QuickBooks.

Spend lands in QuickBooks, coded by a bookkeeper against a printed chart of accounts, with the job carried as a customer and the cost bucket carried as a class. Budgets and actuals live in Autodesk Cost Management, where PMs work. Both true, both fine. The gap is everything that starts in a truck: a crew lead buys lumber, keeps the receipt in the cab, and two weeks later someone tries to remember which job it was for. Meanwhile the job's hours are on a paper sign-in, the day's work is in a text message, and the guys who rode as passengers to a site 90 minutes away are paid by whatever gets remembered.

So the build is deliberately parasitic on what already worked. One-way sync, existing chart of accounts, existing project list, existing QR sign on the job. Nothing asks the bookkeeper to change her workflow, and nothing asks a PM to leave Autodesk.

Every vehicle has a QR code. A crew member scans it, enters their PIN, snaps the receipt, picks the job, types the total and the vendor, taps card or cash, and they're done — four screens, no app install, no login. That posts a purchase into QuickBooks pre-tagged with the job as customer and the coded category and class, with the receipt photo attached to the transaction itself.

The rule that shaped the whole receipts build came from the accountant: company-card purchases already reach QuickBooks through the card connection, so posting our own transaction for the same receipt just creates a duplicate she has to reconcile by hand. Worse, bank-feed items are invisible to the API until she accepts them. So a card receipt doesn't post. It waits, and every hour it tries to match a bank-feed line by exact amount inside a date window, excluding cash purchases, our own field-posted transactions, and anything already claimed. One candidate matches automatically; several and the office picks from the list; there's an explicit “post it anyway” exit when the receipt genuinely has no line. A match then fills the blank customer and class fields and only touches the account if it was uncategorized — it never overwrites her coding. Cash receipts, which the card feed will never carry, post directly as before.

The backlog was its own problem: a scanned stack of old receipts in one PDF. The importer splits it in the browser into one single-page PDF per receipt, so the attachment in QuickBooks is exactly that receipt and not a 40-page scan. Each page is read by a model, but nothing posts without a person: confident pages land as extracted, anything doubtful lands as needs-review, and approval is the only path to QuickBooks — idempotent, so an impatient double-click can't post twice. A failed slice is marked failed and retried on the next pass instead of stalling the queue. Cost works out to roughly a cent or two per page, which is cheaper than the alternative by a wide margin.

Site check-in rides the QR sign the job already has — no new signage, no new hardware. A crew member scans it, and because a phone that's been used once is remembered, the next visit is one tap. Employees identify by PIN and are never asked for their name or phone; subcontractors have no login at all, so they give a name, a phone, and a selfie, with headcount if they've brought a crew. There's a Spanish toggle throughout, because a check-in flow nobody can read is a paper sign-in sheet with extra steps. Per-job requirements override the company default, so a job that needs a selfie can ask for one without making every job do it.

Check-in isn't just attendance — it's the day model. One primary button changes with state: I'm here, then Moved if they go to a second site, then Done for the day. That writes the time clock: an in punch on arrival, an out-then-in when they move sites, an out at the end. The job itself comes from the site card, or from the phone's GPS ranked against the job geofences, or from a truck's trip ending inside one — so nothing depends on somebody having been assigned in advance, and the assignment board follows what actually happened. Geofences are geocoded once when an address is saved; the nearest fence wins.

Travel pay is the part crews notice. Telematics trips are pulled on a schedule, and a trip ending inside a job's geofence pays everyone who checked in at that job within the arrival window — passengers included, at each person's own rate, by hours or by miles depending on how they're set up. Legs are ledgered per person per trip so a re-run can never double-pay, amounts freeze the moment they're approved, unusually long legs are flagged for review, and a trip whose driver can't be identified is written with no employee attached rather than being silently dropped.

At the end of the day, the foreman opens a daily log from the same QR menu: crew (prefilled from that day's check-ins), work done, photos, send. It syncs into the Autodesk Daily Report — the form ID is stamped the moment Autodesk returns it, before the values are filled, so a failed fill retries the same form instead of creating a second one.

They were leaving Buildertrend, and the export was what it was: users, client contacts, and subs — with a title banner on the first row and the real headers on the second. 87 user records came across as 80 new people plus 7 matched to people already in the system by normalized name, with inactive users imported as terminated and the Buildertrend role kept as their title. All 208 subcontractor and vendor records came in, deduplicated by name.

Then the honest part: roughly a third of the “subs” weren't subs. Gas stations, grocery stores, a hardware chain filed under an equipment division. They were reclassified by division into subcontractors and vendors, and the People tab carries separate views for each with a one-click flip, because that judgement call is the client's and it will need correcting occasionally. Buildertrend also exported no schedule, daily-log, or to-do data, so those modules started empty here — which is worth saying plainly rather than letting someone discover it after cutover.

The telematics endpoint in the docs didn't exist on their account. The modern fleet trips endpoint returned a 404 with a valid token. The older per-vehicle endpoint answered fine — but with no trip identifier at all, so the dedupe key had to be synthesized from vehicle plus start time. Field names have also moved between API versions, so trip times are read in both shapes. None of that was discoverable from documentation; it took a live token and a probe against the real fleet, which is exactly why we ask for one before claiming an integration works.

The trucks weren't assigned to drivers. Every trip came back with a driver ID of zero, because nobody had linked vehicles to people in the telematics system — the driver's name was in the vehicle name. Asking the client to go re-key their fleet would have been the lazy answer. Instead we added a usual-driver mapping per vehicle, set once in the Travel screen, and attribution now runs: whoever was signed in to the truck, else the crew who checked in at that job, else the truck's usual driver. One more honest flag: first-leg pay needs a yard address on file and theirs isn't set yet, so that rule is inert until it is.

Access to Autodesk wasn't a code problem, and then it was a scope problem. A valid token returning an empty hub list means the integration isn't approved in the account — so the diagnostic says that, by name, instead of reporting a mysterious empty list. Once it was approved, all 37 projects listed and imported. Creating new projects from our side needs a write scope the existing token wasn't issued with, so that one action waits on an account admin reconnecting once. Reading and importing works today; we say which is which rather than shipping a button that 403s.