Our own tool · Wholesale and distribution · 2025
The supplier invoice queue, read once by a machine
Somebody in accounts opens a few hundred PDFs a month and retypes seven fields out of each one. The expensive part is not the typing - it is the transposed ΑΦΜ that nobody catches until ΑΑΔΕ does. This is the queue that reads them and refuses to guess.
3
Validations before anything is written: ΑΦΜ check digit, line-item sum, VAT re-derived at the stated rate
- Python
- Claude API
- Postgres
- myDATA
- Next.js
Try it here
This is the same code that runs on the sector page, not a recording of it. Put your own numbers in.
- Pick a document and run the extraction.
- Switch the scan to a phone photo or a fax and run it again.
- Accept or correct a field from the review queue.
0/3
Runs entirely in your browser. Nothing you click here is sent anywhere. The ΑΦΜ and totals checks are computed for real; the confidence scores are a simulation of the real pipeline's behaviour, not a live model call.
The numbers
- 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
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.
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. Where to set it is not a decision anyone can make for you in advance: it depends on what a wrong row costs, and that only becomes visible after a month of your own error data.
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.
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.
Try it hereWant something like this for your business?
A 20-minute call with the two people who would build it. You tell us what you need; we tell you whether it is worth building and roughly what it costs.
The full page: Business automation