Receipts leave the truck the day they're spent.

The same truck page carries the rest of the field's day — site check-in and the end-of-day log — so one sticker is the crew's whole interface, not a single-purpose gadget.

This is the rule every receipt app gets wrong, and your accountant already knows it: a company-card purchase is coming into QuickBooks anyway, through the card connection. So a receipt app that dutifully posts a Purchase has just created a duplicate — and the duplicate is invisible to the software and obvious to the human, which means she reconciles it by hand, every week, forever. That's a net loss versus the shoebox.

There's a second wrinkle that makes naive matching fail: bank-feed items are invisible to the API until she accepts them. Only once she accepts a line does it become a real transaction anything can see. So the receipt has to be patient.

What actually happens with a card receipt:

• It lands in awaiting match — no Purchase created, photo and details held.
• An hourly pass looks for a bank-feed purchase with the exact same total inside a tight date window — widened for older backlog receipts and after several failed tries, because a 2024 receipt needs a 2024 window.
• Candidates are filtered hard: our own field-receipt postings are excluded by marker, cash purchases are excluded, and anything another receipt already claimed is excluded. Two $47.12 Home Depot runs on the same day can't both grab the same line.
• One candidate → matched automatically. That line gets coded: a blank job or class is filled in, the expense account is replaced only if it's sitting on “Uncategorized”, and the photo is attached. Her coding is never overwritten.
• Several candidates → the office picks. The choice is shown with the amounts and dates, and a human decides in two seconds.
• And there's an explicit post anyway exit, because a rule that can strand a receipt isn't a rule you can run a company on. If the line genuinely never arrives, you say so and it posts.

Cash receipts are the simple case and are left alone: nothing else will ever bring them into QuickBooks, so they post as purchases. The whole behaviour is one setting — match mode or post mode — per company.

Every firm adopting this has a year of paper sitting somewhere. You scan the stack on the office copier — one big PDF, receipts in whatever order they were stacked — and upload it. In the browser, before anything is sent, that PDF is split into one single-page PDF per receipt. That split matters for a boring reason: the attachment that ends up on the QuickBooks transaction has to be that receipt, not page 34 of a 200-page scan that nobody will ever open.

Then each page is read. No OCR service in the middle and no image rendering step — the PDF pages go to the model directly, in small batches, and come back as structured fields: vendor, date, total. Reading a page costs a cent or two.

What happens next is the whole design: nothing auto-posts. Pages read confidently queue as extracted. Anything doubtful — a crumpled thermal receipt, a total that could be a subtotal — goes to needs review. A person approves every one, and approval is the only path into QuickBooks, idempotent on the page so a double-click can't double-post. A slice that fails mid-run is marked failed and retried on the next pass instead of quietly stalling the whole batch.

Backlog receipts carry their real date through, so a 2024 card receipt matches a 2024 bank-feed line rather than hunting for one near today.

We didn't invent a category taxonomy. The printed chart of accounts your bookkeeper works from is the list — the COGS block marked “all for projects”, Job Materials with its “incl. Lowes / Home Depot” note beside it. Each category maps to a QuickBooks account once, by the owner, and the “codes” she tags with are QuickBooks classes.

Vendor rules do the rest of the work: a fragment like “Lowes”, “Home Depot”, a fuel chain or a rental house maps to a category, and the longest matching rule wins, so a specific rule beats a general one without anyone ordering a list. Resolution order for a category is an explicit pick, then the job's default, then the vendor rule. The class comes from the job, falling back to the employee. If none of it is configured, receipts fall back to the single expense account the company was using before — turning the feature on can't change how yesterday's receipts behaved.

Coded spend is what makes the rest of the stack worth having: the same purchases flow on to Autodesk Cost Management for the PM to classify against the budget, and the field's time and drive time land next to them via travel pay. The wider picture is on the construction solutions page, and what connects to what is on integrations.