Removing manual invoice entry for a building materials distributor
Two full-time roles spent their mornings retyping supplier invoices into an ageing ERP. We replaced the typing with an extraction pipeline and a review queue — keeping the humans, moving them to the exceptions.
- Organization
- Building materials distributor
- Construction supply · ~140 staff · 3 depots
The shape of the system
What this demonstrates
Text-native invoices parse directly from the embedded text layer; only scans and photographs go through the vision pipeline
Arithmetic and duplicate checks run before anything posts to the ERP
A reviewer sees only documents that failed a check, are from an unfamiliar supplier, or fall below the confidence threshold
The existing accounts-payable inbox keeps working unchanged — suppliers change nothing about how they send invoices
01/The problem
Around 1,900 supplier invoices arrived every month, in every format a supplier could think of: text PDFs from the larger merchants, flatbed scans from the mid-sized ones, and phone photographs of paper delivery notes from the two-person outfits. Every one of them was opened, read, and retyped into the ERP by hand.
The cost was not only the two roles doing it. Because entry ran behind, the purchasing team never had a current picture of committed spend, early-payment discounts were routinely missed, and disputes over line-item pricing took days to resolve because nobody could find the original document quickly.
The company had trialled an off-the-shelf OCR product the previous year. It handled the clean text PDFs adequately and fell apart on everything else, which was most of the volume — so it was quietly abandoned after four months.
02/Approach
We started by asking for six months of historical invoices rather than a specification. That sample gave us the real distribution — a large share of text-native PDFs, a larger share of scans of varying quality, a meaningful minority of phone photographs, and a long tail of genuinely difficult cases including multi-page invoices stapled out of order.
That sample set the architecture. Text-native PDFs bypass OCR entirely and parse from the embedded text layer, which is both exact and effectively free. Only the scans and photographs go through the vision pipeline, which removed a whole class of OCR transcription errors from the majority of volume.
We built the pilot against the historical set before touching live data, which meant we could measure accuracy against known-correct ERP records rather than arguing about it. That measurement became the acceptance criterion.
03/What we built
- 01
An ingestion service watching the existing accounts-payable mailbox, so suppliers changed nothing and nobody had to be trained on a new submission process.
- 02
A dual-path parser: direct text extraction for native PDFs, layout-aware OCR for scans and photographs, with automatic deskew and page-order recovery for multi-page documents.
- 03
Field extraction returning supplier, invoice number, dates, per-line descriptions, quantities, unit prices, tax and totals — each with an independent confidence score, and each normalised against the existing supplier master and GL code list.
- 04
A validation layer that checks arithmetic before anything is trusted: line items must sum to the subtotal, tax must reconcile against the rate, the total must match. It also flags duplicate invoice numbers, which turned out to catch a genuine double-payment in the first month.
- 05
A review queue showing only documents that failed a check or fell below threshold, with the source page rendered beside the form and the extracted region highlighted. Reviewers correct in place; corrections are logged as training signal.
- 06
A write-back integration into the ERP, plus a searchable archive linking every posted record to its source image — which is what actually fixed the supplier dispute problem.
04/Outcome
Most invoices now post without anyone touching them. What a reviewer sees is deliberately narrow: documents that failed a check, are from an unfamiliar supplier, or fell below the confidence threshold — roughly the set a careful human would also flag for a second look.
Neither of the two data-entry roles was made redundant. Both moved onto supplier relationship and purchasing work, which was the client's stated intent from the first conversation and, in our experience, the version of these projects that actually sticks.
The unplanned win was the archive. Resolving a pricing dispute went from a depot visit and a filing cabinet to a search box, which the finance director cited as the more valuable half of the project.
05/What went wrong
The first production month ran noticeably below the pilot's accuracy. One supplier's invoices used a two-column layout that our historical sample happened to under-represent, and confidence thresholds set on clean data were too aggressive against live noise. Both took about a week to fix — but it is why we now hold back a portion of production volume for a supervised ramp rather than switching straight over.
Every engagement has one of these. A case study without it is a brochure.
06/Detail
Stack and services drawn on
Built with
- PaddleOCR
- PyTorch
- FastAPI
- Postgres
- n8n
- Docker
Recognise this problem?
We start every engagement by measuring what the manual process actually costs. That first week tells you whether the rest is worth doing.