Construction and trades blueprint
Site photographs read, priced against the customer's agreed rates, held for one approval screen, then raised as invoices with the original sheet attached.
Job sheets come off site as photographs and somebody types them in
Mobile upload or shared folder · Document reader · Accounts system · Price list · Team chat
10, of which 1 stay with a person
Three to four weeks
Free to use, adapt and build from. No email needed and no attribution asked for.
Every step, in order, including where it forks and where a person stays.
From a phone, into a form, an email address, or a shared folder. Whichever the crews already use, because changing what the crews do is where these projects die.
Text recognition on the image, then a model pulls out the customer, site, date, hours worked, parts used and any notes. Handwriting is the hard part and the workflow is built expecting it to be.
Each extracted field carries a confidence score, checked individually rather than as an average.
Matched on name and site, with fuzzy matching for the ways a crew might write it.
Hours at the rate agreed with that customer, not the standard rate. Parts at the current price list. Both come from the accounts system, so there is one set of prices rather than two.
Compared against previous jobs of the same type for that customer. Catches a decimal point in the wrong place, which is the expensive mistake.
One screen, every pending sheet, the photograph beside the numbers. Most are approved in a batch in a few minutes. This step stays because an invoice going out wrong costs more than the minute it saves.
Created as a draft in the accounts system, with the line items the sheet described and the original photograph attached to the record.
Some firms invoice as they go, some on a weekly run. The workflow does whichever the firm already does rather than changing how it bills.
The sheet is marked done, the photograph is attached to the invoice, and the crew's app shows it went through. The query six weeks later takes ten seconds to answer.
Every one of these has happened. A workflow that has not been designed against them is a demo rather than a system.
A sheet filled in on a bonnet in the rain is not going to be legible, and any system claiming otherwise is guessing.
Held with the photograph and the doubtful field highlighted. Never estimated. A wrong number on an invoice costs the relationship, and the relationship is worth more than the minute.
Vendors ship changes without much warning, and a field that quietly becomes null writes an empty line rather than failing.
The response shape is checked before anything is written. A mismatch halts the run, alerts the office, and leaves the queue intact rather than raising a batch of broken invoices.
Crews resend when they are not sure it went through, which is sensible of them.
The image is hashed and the job number matched. The second upload attaches to the first rather than becoming a second invoice.
Somebody bought something at a merchant that morning.
Held for review with the description as written. The reviewer prices it once and the workflow remembers it for next time.
Typing time
About 12 hours a week back
Assuming 60 sheets a week at roughly 12 minutes each, less the few minutes a day of approving the queue. Your numbers will differ; put them in the ROI calculator.
Time from work to invoice
Same day
Mechanical. The sheet is processed on upload rather than waiting for somebody to reach it in a pile.
Sheets findable later
Every one
The photograph is attached to the invoice record at the moment it is raised, rather than living in a phone.
Three weeks or so, then a flat monthly fee to run it. Or take the specification above and build it yourself, which is genuinely fine and is why it is up here.