Built for small businesses in general — not a sector list.
Version history
v1.0 · 2026-08-18 — First release. Built on the fact that half the comparison became free: Belgium's domestic B2B e-invoicing mandate (1 January 2026, Peppol BIS Billing 3.0 / EN 16931, tolerance period ended 31 March 2026, penalties from EUR 1,500) means supplier invoice lines now arrive machine-readable. Only the delivery note is still paper. Deliberate design line: a local model reads the document, plain arithmetic does the matching, a human decides - an LLM asked 'do these match?' will agree, and a false clean is silent.
Since January 2026 your supplier invoices arrive as structured data. The delivery note they should be checked against is still a photo of a crumpled piece of paper — so this blueprint reads the paper and lets plain arithmetic do the matching.
The architecture
the same flow as text
[ Delivery at the door ] → phone photo of the note
▼ (mailed to a fixed address, or dropped in a shared folder)
[ Docling — reads the page ]
│ photo/PDF → text + table structure, OCR for scans
▼
[ Ollama, local model — turns the table into lines ]
│ supplier · date · item code · description · quantity · unit
▼
[ Grist — the open-deliveries register ] ← the thing you actually look at
▲
│ invoice lines
[ n8n — the matcher ] ← Peppol UBL/XML in, or Paperless-ngx for legacy PDFs
├─ quantities agree, price agrees → cleared for payment
├─ invoiced more than delivered → flagged, photo attached
├─ price above your price book → flagged
└─ delivered, never invoiced → still open after 60 days, listed
A model reads the paper. Arithmetic does the matching. You make every call.
That last line is the whole design, and it is worth being blunt about why. If you hand both documents to a language model and ask "do these match?", it will tell you they match. Models are agreeable, and agreeing is the failure mode that costs you money here, because a false clean is silent and a false flag is not. So the model is confined to one job it is genuinely good at — turning a photographed table into structured lines — and the comparison is done in code that subtracts one number from another. Boring on purpose.
The problem
Almost nobody checks a supplier invoice against what actually came off the van. The delivery arrives mid-service, someone signs the note without counting, the note goes in a drawer, and three weeks later an invoice turns up with 30 lines on it. Nobody is going to walk back through a drawer to verify line 17. So it gets paid.
I am not going to hand you a percentage here. Every "X% of invoices contain errors" figure I could find traces back to a vendor selling accounts-payable software, and I do not trust a single one of them. What I will say is the mechanism, because the mechanism is not in dispute: short shipments, items delivered once and invoiced twice, and prices that quietly drifted above what you agreed are all invisible unless somebody compares two documents. In most small businesses nobody ever does.
What changed is that half the comparison became free. Belgium made structured e-invoicing mandatory for domestic B2B transactions on 1 January 2026 — Peppol BIS Billing 3.0 (UBL 2.1) against the EN 16931 standard, with a tolerance period that ran out on 31 March 2026 and penalties starting at €1,500. PDF and paper are no longer compliant for those invoices. That means the invoice side already lands on your doorstep as a machine-readable file with every line, quantity, unit and price in it. You do not have to read it. You already have it.
The delivery note is the half that is still paper. Close that, and the check becomes arithmetic.
Tool choices — and why
Docling
(MIT, 65k stars, pushed 17/08/2026) does the document reading. It was built for exactly this — PDFs and images in, text and table structure out — and the table part is what matters, because a delivery note is a table and a plain OCR dump of one loses which number belongs to which row. It runs locally, calls an OCR engine for photographed or scanned pages, and it is under active daily development by a serious team.
Ollama
(MIT, 179k stars, pushed 16/08/2026) runs the small local model that turns Docling's output into clean line items and normalises the descriptions. A model in the 7–8B class on a machine with 16 GB of RAM is enough for this; you are asking it to tidy a table, not to reason. Nothing leaves your building, which for supplier pricing is the point — your negotiated rates are commercially sensitive and there is no reason to post them to anyone's API.
Grist
(Apache-2.0, 11.5k stars, pushed 17/08/2026) holds the register. A spreadsheet with real formulas, real column types and an API, self-hosted. The open-deliveries table is the surface you look at on a Friday afternoon, so it has to be something you can sort and filter without asking anyone. If you already run NocoDB or Baserow, use that instead — the register is 4 tables and nothing here is Grist-specific.
n8n
(fair-code Sustainable Use License — free to self-host for your own business, 189k stars) is the plumbing and the matcher. It watches the mailbox, calls Docling, writes to Grist, parses the incoming UBL, runs the comparison and sends you the flags. Same instance as your other automations.
Paperless-ngx
(GPL-3.0, 44k stars, pushed 17/08/2026) is optional, and only for suppliers still sending PDFs — cross-border suppliers outside the Belgian mandate, or the ones you buy from twice a year. If you already run it for the receipt intake blueprint, point this at the same instance.
Monthly cost
Software: €0, all five. If it runs on a box you already own, that is the whole bill. On a rented VPS with enough RAM for a local model, budget €10–15/month, and check the current rate rather than trusting this sentence in six months. There is no per-document charge, no per-user seat, and no API bill, which is the difference between this and the accounts-payable products that start around €200/month and assume you have an accounts-payable department.
Setup outline
1. Start with one supplier. The one you buy from weekly, with the most lines per invoice. Do not start with all of them.
2. Build the price book first: item code, description, agreed unit price, and the unit you buy in. Without this the price check has nothing to compare against. If you already built the price book from the quoting blueprint, reuse it.
3. Set up the intake: one email address like levering@yourbusiness.example, and whoever signs for a delivery photographs the note and sends it there before the van leaves. That habit is the hard part of this whole build — everything downstream is software.
4. Wire Docling behind n8n, feed it three real delivery notes from that supplier, and look at the output yourself. Fix the extraction prompt until the quantities are right on all three.
5. Create the Grist tables: Suppliers, Items (your price book), Deliveries, Delivery lines, Invoices, Invoice lines. Every delivery line starts as open.
6. Point n8n at the Peppol inbox or the mailbox your e-invoices land in and parse the UBL. The quantities and prices are named fields in EN 16931 — no reading required.
7. Write the matcher as arithmetic: for each invoice line, find open delivery lines for that supplier and item code, compare quantity and unit price, and mark matched, short, over or price-mismatch. Nothing clever.
8. Run it in shadow mode for a month. It flags, you check the flags against reality, and you find out where the units are wrong. Do not connect it to anything that pays money.
9. Add the ageing report last: delivery lines still open after 60 days, and invoice lines that never found a delivery.
Pitfalls — the real ones
Units will break this before OCR does
The note says 1 box, the invoice says 12 pieces, and your matcher declares an 11-unit shortfall on every single line. This is the failure that kills these projects, and it is not solvable in the prompt — it needs a per-supplier, per-item conversion factor in the price book. Budget real time for it and expect to keep finding new ones for months.
Partial deliveries are normal and one-to-one matching is not
One invoice routinely covers three deliveries; one delivery covers two orders. If you match at document level it collapses the first time a supplier back-orders something. Match at line level and let a delivery line be consumed partially.
Signing "received in good order" without counting
No software fixes this. If the person at the door signs for 20 boxes and 18 arrived, the delivery note says 20 and your matcher will happily agree with the invoice. The automation makes the check cheap; the counting is still human. Be honest with yourself about whether that habit will hold.
Thermal paper fades
Delivery notes printed on till-roll are unreadable within a year, sometimes months in a warm van. The photo is not just input to the pipeline, it is your evidence in a dispute — so keep the original image, not only the extracted numbers.
Flag, never block
It is tempting to stop payment automatically on a mismatch. Do not. A false flag that silently delays a supplier payment costs you a relationship and a late fee, and you will have false flags for the first few months. The output is a list for a human, full stop.
If a Belgian supplier still emails you a PDF for a domestic B2B invoice, that is their compliance problem, not your parsing problem
Since the tolerance period ended on 31 March 2026 those invoices are not compliant. Raise it with them rather than building a scraper around it.
Check your own VAT position before relying on any of this for bookkeeping
This register tells you what arrived. It is not an accounting record and it is not tax advice — your accountant still owns that.
Verified repos
Docling — MIT, 65k stars, active (August 2026) Ollama — MIT, 179k stars, active (August 2026) Grist — Apache-2.0, 11.5k stars, active (August 2026) n8n — Sustainable Use License (free self-hosted internal use), 189k stars, active Paperless-ngx — GPL-3.0, 44k stars, active (August 2026) — optional, for legacy PDF suppliers
Get the next blueprint as it publishes — free, practical, verified tooling only.