Inside the Build: How We Extract Data From Supplier Documents

Here is how we extract data from supplier documents for a logistics and freight business where delivery notes and invoices arrived as PDFs and scans in a shared mailbox. Staff opened each one and typed the reference numbers, quantities and totals into the operations system by hand, and mismatches only surfaced weeks later, at month-end reconciliation, when they were far more expensive to untangle.

This is the story behind one of the case studies on the case studies page. What the mailbox looked like before, what got built, and why nothing gets written into the system without a check first.

Why Month-End Was the Worst Possible Time to Catch a Mistake

By the time a mismatch surfaced at month-end reconciliation, the original document, the actual order it should have matched, and the memory of what was actually delivered had all drifted further apart than they were on the day it arrived. Catching an error the same day it comes in is a five-minute fix. Catching it three weeks later is a genuine investigation.

How We Extract Data From Supplier Documents in Practice

An intake workflow reads each document as it arrives and extracts the fields that matter: reference numbers, quantities, totals. Before anything gets written anywhere, those extracted fields are validated against the open orders they should match. A clean match writes the record straight into the operations system automatically. Anything that does not line up goes into a short review queue with the original document attached, rather than being written in on faith.

Why the Review Queue Is Not a Failure Case

A document intake system that tries to auto-approve everything, including the genuinely ambiguous cases, is optimizing for the wrong thing. The review queue is not a sign the automation is incomplete, it is the deliberate boundary between what a machine should decide on its own and what a person should look at, and it is exactly what keeps the automated records trustworthy enough that nobody has to double-check the clean ones.

Why This Generalizes Past Delivery Notes

Document AI extraction of this kind, using services like Google Cloud’s Document AI, works the same way regardless of whether the document is a delivery note, an invoice, or a supplier form, because the pattern is always the same: extract, validate against something you already know to be true, and only write in what actually matches. The same idea, letting software render structured output from a document while a defined check decides what is trustworthy enough to accept, is also what runs the rental contract generator built for a property law firm, just applied to legal clauses instead of order quantities, and it is the same pattern behind accounts payable automation, applied to vendor invoices instead.

What Changed Once Documents Stopped Piling Up

The clearest change was not a single dramatic fix, it was the disappearance of the month-end scramble. Documents get processed the day they arrive instead of in a Friday batch, and a discrepancy gets caught while the order is still fresh in everyone’s memory instead of three weeks later during reconciliation.

Why Extraction Alone Was Never the Real Goal

Being able to extract data from supplier documents is a solved technical problem on its own. The genuinely useful part is what happens immediately after: checking that extraction against something already known to be true, the open order, before trusting it enough to write it anywhere at all. A system that only extracts, without that validation step, would just be moving the retyping work from a person to a machine that can also make mistakes, only faster and with less obvious signs anything went wrong.

Getting this right the first time matters more than getting it fast, since a business running on the extracted numbers has no easy way to notice a quiet, confident mistake until it shows up somewhere expensive.