The problem
Every supplier invoice on the project had been attached to a Procore direct cost record, but only as a PDF. The line items, quantities and unit prices were never keyed anywhere. Answering "what did we pay per cubic metre of concrete last year" meant opening a few hundred PDFs.
Worse, nobody had checked the PDFs against what Procore said was paid. The direct cost total was typed in by hand at the time. Some were wrong.
What we built
A reader that pulls each attachment from Procore, extracts every line with a vision-capable model, and returns a structured record: supplier, invoice number, date, each line with quantity, unit and price ex GST, and the invoice total.
Then three checks per invoice:
- Do the extracted lines add up to the invoice total? If not, the supplier's own arithmetic is wrong, or the extraction missed a line.
- Does the invoice total match the Procore direct cost amount? If not, someone keyed it wrong at the time.
- Is the scan readable at all? Photos of dockets and faxed statements get flagged rather than guessed.
Every invoice gets one of five stamps: matched, Procore mismatch, bad total, unreadable, no attachment. The stamped list is the work queue for the finance manager.
What it found
Eighty-one invoices where the amount in Procore did not match the PDF. Most were small keying errors. A few were not small. Twelve invoices where the supplier's own lines did not add up to their total.
Thirty-seven attachments the model could not read with confidence. Rather than guess, it said so. Thirty-two direct cost records with no attachment at all, which is its own finding.
What it cost
$40.55 in model usage for the whole run, about 90 minutes of wall time. The builder had been quoted a per-invoice fee by a data entry service that would have come to several thousand dollars, without the checks.
What happens now
The same reader runs on new invoices as they arrive. Matched ones go into Procore for approval. Mismatches go to a person. The three-year backlog became the cost catalog.