Looking for ideas to digitize quarry/gravel haul tickets (handwritten carbon copies from multiple suppliers)

Is there any chance that you can trust/require the drivers to transcribe the ticket into an app on the iphone? So you have an app and the driver fills out supplier/ticet/load/material etc and just attaches a pic of the receipt as evidence?

I'd think m365 Form would be ideal for this; phone is already likely signed in so it just works, and it can log the results to excel on SP for auditing and also email whomever actually processes.

This is the answer. Many trucks sit in a line waiting to load and that is a good time to catch up on this

We have this issue with two of our largest customers. We ended up custom building an app to handle them all. The back-office effort it replaced was substantial. We luckily have a dev department which made this possible, but it wasn't rocket science either. DM me if you want a basic outline of how we did it.

the drivers are already stopping to get the paper ticket anyway, so adding 30 seconds to snap a photo and punch in 5 numbers is not a big ask. we did similar thing with a courier company few years ago, made a simple form in power apps that saves straight to sharepoint list. drivers hated it for first week then it just became part of the routine. the real trick is you need the office to stop entering the data manually at same time. if they keep doing double entry as backup, drivers will notice and stop caring about accuracy. gotta rip the bandaid off and trust the system. maybe have one person spot check 10% of tickets for first month to build confidence.

Best option, as you say, is a completely different workflow. However, there are tools that can work around it. It's been a couple of years since I trialed it, so I don't know current costs or performance (but this was before the AI boom, so I can't imagine it's done anything but get better) - one example is Microsoft's Power Automate (Premium) invoice OCR tool. It requires AI credit consumption. But basically you train it on a batch of invoices, highlighting the fields on the invoices and how you want to ETL them into your system/destination (from a CSV that gets emailed, to a sharepoint Excel table, to an Azure SQL database, or even API calls to whatever tooling you want). I never had a use case where I had to implement it, but it's an example of a great solution for bad (paper) workflows that you can't rectify. Your users could snap a pic and email it to the billing mailbox to kick off the automation.

we've solved this a long time ago with back office people, which is really what's happening right now but they have to foster a cleaner version of it with internal policies. Back office clerical/admin people with dual screens and a clean input and output workflow is the best thing since as you pointed out the formats are inconsistent and OCR really can't do it. take a photo into app, office gets it in near realtime, puts it into quickbooks or whatever. bonus points the back office can sanity check it without asking questions, Like if it looks like 23 tons its probably 2.3 tons gravel based on realistic vehicle capabilities. email, texting or an app.. This will sound strange but the Trello (kanban) app is weirdly compatible with connecting office and field workers. each board is a truck. One electrical contractor still using this method for truck tool load outs.

If you still want to try AI OCR, you could use the iPhone camera to take a picture and process it. If you are really set on automating it, you might need a custom app. I would use GPS and other data to fill in supplier/quarry/truck/driver/customer/jobs. Then it's a matter of trying to verify with AI OCR and filling in the more variable costs, tonnage, and material. And at a minimum, having a picture on file with the record. AI is good at self-diagnosing when it's not sure and can flag when a human needs to check it. But as others have suggested, this isn't much data for a driver to fill out on a form on their iPhone.

Do they need all information from.every ticket? If they dont, you make a way for them (the drivers) the information from the ticket into your system. They still turn in the paper ticket to rectify discrepancies but should increase accuracy and lessen yhe need tor labor at the office.

As they already have iPhones, FileMaker could be a way to go. They offer an iOS app that could be used offline or online. (I am a certified developer.) It would be custom-developed, but it sounds like an easy one to do.

Can a PO coming out of your system, have everything that those tickets would have except maybe the exact weight and time of day, before the trucks make the pickups?

I'd certainly look at the workflow. Ideally you'd seek to eliminate that handwritten stuff. Happy to chat privetely about it if you want.

I would stop trying to make OCR the primary system. Use the photo as evidence, not as the source of truth. The driver form should capture the few fields you actually need while the driver still has context: supplier, truck, job or customer, material, ticket number, tonnage, and a photo. Then the office only reviews exceptions: unreadable photo, missing tonnage, supplier mismatch, duplicate ticket number, or weird cost. Start with one simple mobile form into a list or spreadsheet before buying heavier document AI. The win is not perfect handwriting recognition; it is moving data capture to the moment the ticket is received while keeping the paper slip attached for audit.

The OCR keeps disappointing because you are asking it to read seven fields when only two are actually unknown. Supplier can come from Geotab since the truck was physically at that quarry at that timestamp, truck and driver and job come from dispatch, and cost comes from each supplier's rate card. That leaves ticket number and tonnage, which the driver keys in ten seconds at the scale, with the photo kept for audit. Validation then becomes deterministic: tonnage against vehicle capacity, ticket number against per supplier duplicates, cost against the rate card, and the office only touches exceptions. Have you checked how cleanly the Geotab timestamps line up with ticket times? If they match, this is a join problem, not a handwriting problem.

Disclosure: I build custom ops software for a living, and this exact pattern - OCR failing on structurally inconsistent source documents - comes up constantly with clients trying to bolt automation onto a process that was never standardized upstream. The comments here calling it a "join problem, not a handwriting problem" (Geotab timestamp + rate card + dispatch record) are exactly right, and it's worth generalizing: any time you're integrating data from a party you don't control (different quarry, different format, different handwriting every time), treat OCR as best-effort evidence capture, not the source of truth for anything that needs to reconcile against your own books. We wrote up a similar pattern a while back (QuickBooks silently dropping unmapped fields on sync rather than erroring loudly) - happy to share if useful: selfhostederp.com/blog/integration-debt-part-1. Same root cause here: the "clean" data path only works when every party plays by the same rules, and quarries obviously won't. The deterministic-fields approach (letting Geotab/dispatch/rate-card supply what you already know, and only asking the driver for the 1-2 fields nobody else has) is the right shape - it turns "extract 7 unreliable fields" into "confirm 2 reliable ones," which is a much smaller ask of both the OCR and the driver.

You've already spotted the real answer in your last line, it's a workflow problem, not an OCR problem. Handwritten carbon copies in a dozen formats with dozens of handwritings is about the worst possible input for extraction, and no amount of better OCR makes that hands-off. The move is to capture the data structured at the source instead of deciphering it after the fact. Drivers have iPhones, so at pickup the driver snaps the ticket and confirms the handful of fields that matter right there: supplier as a dropdown of your known quarries, then ticket number, material, tonnage, truck, job. OCR still runs, but only to pre-fill those fields for the driver to correct in ten seconds while the paper's in their hand and they remember the context. That's a completely different accuracy problem than the office reverse-engineering a smudged slip three days later. The photo stays attached to the record as your audit trail, so you keep the paper's evidentiary value without keying from it. The office goes from entering everything to reviewing only the exceptions the driver flagged or that fail a sanity check, like tonnage over truck capacity or an unknown supplier. You can't get the quarries onto one system, but you don't need to. You only control your own capture point, and that's the driver's phone, not the incoming paper.

Hi — this is a common choke point: dozens of handwritten tickets from many suppliers. A lean intake fix can unlock real gains. If you want, I can draft a starter two-sheet tracker and one-page checklist to test this week.