Delivery note OCR is step one. Checking every line is the part that saves time

OCR (optical character recognition), and the AI document readers that have largely replaced it, turn an image or PDF into data: supplier, date, document number and — in the better tools — each line with item, quantity and unit. Horizontal document-processing vendors do this well for many document types. Doxis (ex-Klippa), for example, offers delivery note OCR through an API and mobile SDK and says its data can be cross-checked against purchase orders or invoices (checked 2026-09-29).

On a job site the input is harder than a clean PDF: photos taken in the cab of a truck, creased paper, stamps and signatures over the lines, and layouts that change from supplier to supplier.

Once the note is digital, the questions that take the time are still open: which contract item is this line, is the quantity the same as on the invoice, is the unit the same, and is the price the agreed one? A generic OCR tool does not know your job site’s contract, and the description on the note rarely matches the contract text (“CONC C25/30 S3” vs “Concrete C25/30 XC2”).

That is why teams that add OCR on its own often find the spreadsheet is still there, just with fewer typed cells. The saving comes from the match and the checks, not from the reading alone.

• Capture where the team already is — the site team photographs the note in the chat group they already use; PDFs and supplier emails are added from the office.
• Any layout — reading does not depend on the supplier’s layout, so there is no template to set up per supplier.
• Two independent readings — two AI models read every document separately. When they disagree, the document goes to human review. This is a cross-check, not a guarantee; its job is to stop an uncertain reading from being approved.
• Every line — item, quantity, unit and price where the note carries one.
• Duplicates — the same note sent twice is caught by document number or ATCUD plus supplier.

The rest of the process is on delivery note and invoice reconciliation.

1. 01Each line is matched to the job site’s contract price list by meaning, not by identical text.
2. 02Ten deterministic checks (V1–V10) run: price against contract, totals against lines, units, item identity (e.g. D16 vs D22), supplier NIF, contract reference and more.
3. 03What matches is approved automatically. Differences go to the review queue with the exact amount.
4. 04The job site dashboard updates: contracted vs invoiced, pending exposure, alerts, monthly breakdown; data exports to CSV.

If you have developers, need extraction for many document types and want to build the matching logic into your own system, an OCR or document-processing API is usually cheaper and more flexible. If what you need is the checking itself — delivery notes against invoices against the contract — without building it, a reconciliation product fits better. We set out both cases in Audiree vs OCR APIs.

Audiree is not an ERP, an accounting system or AP payment software. It does not pay suppliers, does not issue delivery notes or invoices, is not a certified tax archive and does not submit anything to the Portuguese tax authority (AT). It does not validate ATCUD codes, QR codes or signatures with the AT — the document number and ATCUD are used to catch duplicates. It gives no tax advice: VAT rates and reverse-charge treatment stay with your accountant. There are no ready-made connectors to specific ERPs; checked data exports to CSV for Excel or for posting in the system you already use.

Audiree is built in Portugal and works today with Portuguese construction companies. Reading does not depend on a document’s layout, so delivery notes and invoices from suppliers in other countries can be read as they are. If you run projects outside Portugal, we run demos with your own documents — but we don’t claim local tax rules or integrations for your market.