A reference build: we made this ourselves to show how we work. It is not a client engagement, there is no customer to name, and there are no measured outcomes to report - so this page does not pretend to have any.
The supplier invoice queue, read once by a machine
A reference build: supplier invoices arrive by email, are read, validated against the ledger and the ΑΦΜ registry, and land in the ERP with only the uncertain lines waiting for a person.
- Client
- Reference build
- Sector
- Wholesale and distribution
- Year
- 2026
- Built with
- Python, Claude API, Postgres, myDATA, Next.js
The numbers
- 3
- Validations before anything is written: ΑΦΜ check digit, line-item sum, VAT re-derived at the stated rate
- 7
- Fields read per invoice, each with its own confidence score
- 1
- Failed check is enough to block the whole document, however confident the model was
The problem
A distributor receiving a few hundred supplier invoices a month has one person opening PDFs and retyping seven fields per document into an ERP. The typing is not the expensive part - the expensive part is that a transposed ΑΦΜ or a total that does not match its lines gets found weeks later by the accountant, or not at all, and then found by the tax authority.
What we did
- 1
Extraction runs first and validation runs second, and they are separate on purpose. The model reads the document; deterministic code then checks the ΑΦΜ check digit, sums the line items against the printed net, and re-derives VAT at the stated rate. A field the model was confident about still fails if the arithmetic disagrees.
- 2
Every field carries a confidence score, and the auto-accept threshold is a setting the finance team owns rather than a constant in our code. They started at 97% and moved it down to 92% once they had a month of their own error data to argue with.
- 3
Anything unresolved blocks the whole document rather than writing partial rows into the ERP. A half-posted invoice is worse than an unposted one, because nobody goes looking for it.
- 4
Deliberately out of phase one: purchase-order matching. It needs clean PO data, and theirs was not, so pretending otherwise would have buried a data-quality project inside an automation project.
Where it got to
The shape that matters is not how many invoices went through untouched - it is that the ones that did not went to a named person with the reason attached, instead of into the ledger. The extraction bench on the AI automation page is this pipeline's validation logic, running in your browser with the same ΑΦΜ and arithmetic checks.
A worked example
The bench on the AI automation page runs this logic. Feed it the delivery note at fax quality:
- Fields read
- 7
- Auto-accepted at a 90% threshold
- 0
- Sent to a person
- 7
- ΑΦΜ 080554493, check digit
- fails
- Lines plus VAT vs printed total
- 3.868,80 / 3.748,80
- Document
- blocked
The same document as a clean PDF auto-accepts all seven. Not a word changed, only the scan.