Reading Supplier Invoices Automatically – Without AI

A supplier invoice arrives as a PDF. Invoice number, issue date, due date, net, VAT, gross, currency, IBAN, reference, company name, street, postcode, town, VAT number – roughly twenty fields for someone to retype. At fifty invoices a month that is half a working day, every month, with an error rate nobody enjoys measuring.

The reflex in 2026 is: this calls for AI.

It does not. For the vast majority of supplier invoices the answer is already sitting in the document in machine-readable form. It just has to be read instead of guessed.

That is exactly what Saldio now does: incoming supplier invoices are parsed on upload – from the embedded e-invoice XML or from the Swiss QR code. The supplier is identified, the fields come pre-filled, and a supplier that does not exist yet can be created straight from the invoice data. No AI. No data sent to third parties.

The reflex says AI. The answer is structure.

A language model that “understands” an invoice is fundamentally making a probability statement: that looks like an issue date. That is probably the gross amount. Usually it is right. Sometimes it is not, and you do not notice straight away.

A parser that reads an XML element called IssueDate makes no probability statement. It reads a date, or it finds none and says so.

This is not an argument against AI. It is an argument for using it where it is actually needed – and not where an international standard has already solved the problem.

Two standards that did the work long ago

Factur-X / ZUGFeRD is a hybrid invoice: an ordinary PDF that also carries a complete XML invoice conforming to the European EN 16931 norm. Humans read the PDF, software reads the XML. One document, two ways of reading it. Saldio already sends its own invoices in this format – now it reads them too.

The Swiss QR-bill is the everyday Swiss case. Since the old payment slip was retired for good on 30 September 2022, virtually every Swiss invoice carries a QR code – containing the creditor, address, IBAN, currency, amount and reference in structured form. In Switzerland an XML attachment is the exception and a QR code is the rule, which makes it the more important of the two sources for Swiss SMEs.

What Saldio reads from a PDF

For an e-invoice (Factur-X, ZUGFeRD or XRechnung) the yield is complete:

Units of measure arrive as UN/ECE Recommendation 20 codes (HUR, H87, KGM) and are mapped back onto Saldio’s own units – hours, pieces, kilograms.

For the Swiss QR code the dividing line is clean: whatever the standard mandates is always there. Whatever Swico S1 adds shows up when the issuer set it.

Two honest caveats belong here. First, the amount is optional per the specification. If it is missing, Saldio says so instead of booking a zero. Second, the QR code carries only the gross amount. With exactly one VAT rate present, Saldio calculates net and tax back out of it; with several rates it stays at gross – with a clear note to split it yourself. Splitting it wrongly would be worse than not splitting it at all.

How the document is read

Extraction runs as a chain. Each stage only starts if the previous one found nothing – and the order is not merely the cheaper one, it is the professionally correct one: exact sources beat approximate ones.

1. E-invoice XML. If the PDF carries an embedded invoice in Factur-X, ZUGFeRD or XRechnung form, it is read. The profile is detected and shown too – MINIMUM, BASIC, EN 16931 or XRechnung – so you know how complete the document can possibly be.
2. Swiss QR code. No XML in the PDF? Then the QR code is located.
3. Nothing found. Even then you get a draft with the PDF attached and a clear note about which fields are missing. Not an error, not a dead end – just manual work instead of automation.

Locating the QR code is the unglamorous part with the most day-to-day value. It runs in three stages by rising cost: first the images embedded in the PDF, then the bottom third of the page – where the payment part sits at a standardised 105 mm – and only then the full page.

From issuer to supplier

Extracting data is one half. The other half is the question: who is this, exactly? Saldio checks in order, descending by certainty – only within your tenant and only against active suppliers.

The IBAN leading this list is no accident: it is the only signal a QR-bill always carries – VAT number and invoice number only arrive with the optional Swico add-on. And an IBAN belongs to exactly one company.

Name similarity, by construction, can never reach the level of an exact match. It appears as a scored suggestion, never as a done deal.

Inconspicuous but load-bearing is normalisation: the QR code delivers CHE-123.456.789 MWST while your master data holds CHE123456789. Without normalising both sides – separators out, the MWST, TVA and IVA suffixes out – the VAT and UID rules would essentially never fire.

Creating the supplier straight from the invoice

The most interesting case is the new supplier. Until now that meant: abort the import, create a contact, retype the address, return to the import.

Now a single click opens the familiar contact form – pre-filled from the invoice data: company, street and house number separately, postcode, town, country, VAT number, UID. And, since it belongs there anyway, a payment account with IBAN and BIC. You review, correct, save – and the new supplier is linked to the document immediately. No blind creation, but no retyping either.

If similar companies appear in the suggestion list, Saldio flags that before you create a new one. A supplier duplicated in your master data costs more than ten seconds of checking.

On top of that comes a learning effect that needs no model at all: on save, a valid creditor IBAN that is not yet attached to the supplier is stored as a payment account. The next document from the same issuer then matches immediately via the strongest rule. The import gets better with every invoice – not because a model is training, but because master data is becoming more complete.

And because separating street from house number causes more trouble in practice than one would expect: Blattenackerweg 15a is split correctly, Chemin des Vignes 7bis too, and Postfach 1234 deliberately is not – the number behind it is a box number, not a house number.

What does not happen

This list is the actual point of this article.

• No data sent to third parties. The service that reads your PDFs has no outbound network access. Not “we choose not to use it” – it does not exist.
• No OCR service. No text is recognised from images, because it is not necessary. Structured data does not need to be seen, it needs to be read.
• No language model. No prompt, no tokens, no vendor, no additional data processing agreement.
• No surprises in the result. The same document yields the same output tomorrow as today. No model upgrade quietly shifting your figures.
• No surprises in the cost. A parser costs development once and compute time afterwards. It does not get more expensive when a vendor adjusts its pricing.

Plus the ordinary precautions you should expect around file uploads: PDF only, verified by file signature rather than the declared content type, a maximum of 25 MB per file and 20 files per run, staging storage cleaned up automatically, strict tenant separation, and duplicate detection across supplier and invoice number that can be deliberately overridden.

Saldio also verifies the payment data itself – the IBAN checksum per ISO 13616, the QR-IBAN against the reserved bank range, the 27-digit QR reference via its recursive modulo-10 check digit, including the rule that a QR-IBAN and a QR reference may only appear together. Arithmetic instead of enquiry.

And where AI does make sense

Not every document is structured. The parking receipt, the scanned contractor’s report, the PDF from a point-of-sale system without a QR code – there is nothing to read there, someone genuinely has to look. That remainder is exactly what AI is earmarked for on the Saldio roadmap: as a third stage behind XML and QR code, not as a replacement for them.

The order stays the same as today – exact, then exact, then estimated. And whatever is estimated gets labelled as such and needs approval before it is posted.

The point is not that AI is bad. The point is that you do not solve a solved problem twice – and certainly not in a way that is more expensive, slower and raises more privacy questions than before.

Conclusion

Automation does not need a model. It needs data that someone structured properly – and the willingness to actually use that structure.

For Swiss supplier invoices that structure has been in place for years: across Europe as Factur-X and ZUGFeRD, across Switzerland as the QR-bill with by now near-complete coverage. Read it, and you get exact data, instantly, at zero cost per document – and without a single invoice ever leaving the building.

Rarely the most spectacular kind of automation. But the most dependable.

From order to balance.