RECEIPT OCR · USE CASE

AI receipt recognition for Swiss documents: structured capture of QR-bills, receipts and PDF invoices

OCR extracts structured fields from QR-bills, restaurant receipts and PDF invoices, validates IBAN and UID, and hands off to the ERP.

Researched & fact-checked by: DuneDive LLC · As of: 2026-05

What it is

Receipt recognition is the foundation of almost every AI automation in fiduciary work. Before AI can classify, pre-book or prepare a VAT return, the receipt must be turned into structured data: amount, date, supplier, UID, VAT disclosure, IBAN/QR-IBAN, reference number. That is what the OCR pipeline does.

For the Swiss context there is a decisive anchor: the QR-bill. Since 30 June 2020 it has fully replaced the red and orange payment slips. The QR code carries up to 997 characters of structured data - defined by the SIX standard "Swiss QR Code". From this code, recipient, IBAN/QR-IBAN, amount and reference number can be read with near 100% accuracy, no classical OCR needed. A simple QR decoder (zbar or zxing) delivers structured data directly.

For everything that is not a QR-bill - restaurant receipts, fuel slips, hotel bills, EU PDF invoices, hand-written notes - classical OCR models are used: commercial AWS Textract, Azure Document Intelligence, Google Document AI, or open-source surya-ocr, paddleocr, marker. The choice depends on receipt type, volume and privacy requirements.

Why it matters

In a 12-person fiduciary office with 200 mandates and 4,000-8,000 receipts per month, manual receipt capture is the biggest time sink. A case handler needs 45-90 seconds per receipt on average, depending on quality: QR-bill with clear layout fast, photo of a crumpled slip much slower. AI receipt recognition reverses the ratio: 5-10 seconds per receipt, the rest is review.

Three Swiss-specific aspects make receipt recognition more important in 2026 than in 2020. First: QR-bill obligation. Sole invoice form since mid-2020, with clear compliance expectations from banks since 2023 (rejection of non-QR-compliant orders). Second: GeBüV-compliant archival obligation. Art. 957a CO and the business-records ordinance (SR 221.431) require immutable retention of electronic receipts for ten years. Third: rising EU adoption of ZUGFeRD/Factur-X format - PDF invoices with embedded XML structure. Whoever has EU suppliers sees such bills regularly and must read the XML data, not only the pixel layer.

From a data angle, receipt recognition is the "entry point" of the entire audit trail under Art. 957a CO: the original image or PDF is archived immutably (S3 Object Lock, Wasabi with Compliance Lock, or Swiss providers like Infomaniak Swiss Backup). Hash signature and timestamp are set. Only then does the OCR pipeline run. This sequence - "archive before processing" - is the precondition for audit-readiness.

How it works

The pipeline has six stages.

Stage 1 - intake and archival: The receipt arrives by email attachment, Dext/Pleo connector, client-portal upload or scanner drop. n8n writes the original immediately into the GeBüV-compliant archive bucket with Object Lock and computes a SHA-256 hash. Only after successful archival does processing begin.

Stage 2 - document-type detection: A lightweight classifier (small vision model or PDF-metadata heuristic) decides: is this a QR-bill (CH cross marker bottom right), a PDF invoice with ZUGFeRD XML, a restaurant receipt, a hotel bill, a fuel slip, a hand-written note, something else. Routing follows.

Stage 3 - QR decode or classical OCR: For QR-bills the QR block is decoded with zbar/zxing - 30 structured fields immediately available, including QR-IBAN (CH-formatted), recipient, amount, 27-character reference (QR-IID checksum compliant). For ZUGFeRD PDFs the embedded XML part is extracted. For everything else classical OCR runs: AWS Textract under US-tolerated hosting, Azure Document Intelligence eu-central-1 for revDSG preferences, Google Document AI for high accuracy on mixed receipts. Open source: surya-ocr for layout-aware reading, marker for Markdown conversion of complex PDFs, paddleocr for broad language coverage.

Stage 4 - validation: Several hard checks now run. UID format: CHE-xxx.xxx.xxx, check digit per UIDV algorithm. IBAN: CH format, check digit per ISO 13616 (mod-97). QR-IBAN: a Swiss variant with its own logic. Date: plausible (not in the future, not before client foundation)? Amount: line items sum correctly? VAT disclosure: rate matches date (8.1% after 1.1.2024, 7.7% before)?

Stage 5 - AI enrichment: With structured OCR output in hand, a language model fills the "soft" fields: business purpose of the line (entertainment, office supplies, hosting, travel), allocation key on mixed use, presumed cost centre. Optional; typically consumed by the downstream VAT preparation pipeline.

Stage 6 - ERP handoff: Structured data go via API to the firm's ERP (Abacus REST, Bexio API, Sage 200 API, Topal API) as a draft entry. The case handler reviews, corrects, approves. Audit log records: original hash, OCR engine, OCR result, validation result, final entry, approver.

Pipeline in 7 steps

01Intake: receipt arrives via email, Dext/Pleo, portal upload or scanner. n8n issues an intake ID and timestamp.
02Archival: original goes unchanged into the GeBüV bucket (S3 Object Lock, Wasabi Compliance Lock, Infomaniak Swiss Backup). SHA-256 hash computed.
03Document-type detection: vision model or PDF-metadata heuristic distinguishes QR-bill, ZUGFeRD PDF, receipt, hand-written note.
04Structure extraction: QR decoder for QR-bills (zbar), XML parser for ZUGFeRD, classical OCR (Textract EU, Azure EU, Document AI, or local surya-ocr) for the rest.
05Validation: UID checksum (UIDV), IBAN checksum (ISO 13616), QR-IID checksum, date plausibility, sum plausibility, VAT-rate-date consistency.
06Optional AI enrichment: language model fills business purpose and cost centre. On uncertainty mark "human check".
07ERP handoff: structured data as draft entry in Abacus, Bexio, Sage or Topal. Case handler reviews, corrects, approves. Audit log closes the trail.

When to use

Receipt recognition is the most economic AI investment in any fiduciary with more than 1,000 receipts per month. Put another way: above that threshold the question is not whether but which OCR engine.

Concrete constellations: firms with a high SME share (many small receipts), firms with large e-commerce mandates (hundreds of receipts daily), firms with hospitality clients (extreme frequency, many small slips), firms with construction clients (many material invoices).

Especially economic when (a) the client uses Dext, Pleo or another receipt app - the intake is already structured; (b) the firm uses a modern ERP like Abacus 2024, Bexio or Topal Solution - API integration is commodity; (c) receipts are predominantly QR-bills - the pipeline can rely on QR decoding for 60-80% of receipts and run classical OCR only on the remainder.

When not to use

Not for very small volumes (< 200 receipts per month) - setup does not pay off.

Not without a GeBüV-compliant archive. Storing originals in cloud storage without object lock risks an audit-firm finding and, in serious cases, rejection of the bookkeeping in tax proceedings. Archive first, OCR second.

Not without a privacy check. Receipts routinely contain client data, sometimes health data (medical bills), often bank details. Sending receipts to US OCR providers (AWS Textract us-east-1, Google Document AI global) without a transfer-impact assessment breaches revDSG. Remedy: EU region (Azure Document Intelligence eu-central-1, AWS Textract eu-central-1), Swiss region where available, or local open-source OCR (surya-ocr, paddleocr) on own hardware.

Not without validation. An OCR engine reading "approximately right" is dangerous. UID checksum validation must run; so must IBAN checksum validation. Otherwise OCR-layer typos travel onward as "correct data" and become the source of costly corrections.

Trade-offs

STRENGTHS

Capture time per receipt drops from 45-90 seconds to 5-10 seconds
QR-bill at near 100% accuracy via decoder library, no cloud provider needed
ZUGFeRD/Factur-X is read structurally without OCR work
Art. 957a CO audit trail fully recorded: original hash, OCR result, validation result, final entry

WEAKNESSES

OCR quality on thermal receipts and skewed photos varies - manual review remains necessary
Validation layer must be cleanly implemented - UID, IBAN, QR-IID checksum algorithms are specialised work
EU/CH hosting of cloud OCR engines is mandatory; US region without TIA breaches revDSG
GeBüV-compliant archive is non-trivial - object-lock configuration must be set up properly

FAQ

How high is the recognition rate on QR-bills?

On legible print or PDF nearly 100% - the QR code is ECC-encoded and reads reliably even with minor damage. Harder with photos that have glare or sharp folds. There the pipeline falls back to the OCR layer, reading amount and IBAN conventionally - on a photo receipt accuracy drops to 85-95% depending on engine.

Which OCR engine for a 5-person Swiss fiduciary?

Pragmatic choice: Azure Document Intelligence eu-central-1 (Frankfurt) as the commercial base for all non-QR receipts - very good layout detection, clear revDSG hosting, DPA with Microsoft Switzerland in the standard. For highly sensitive items (legal/medical bills): local surya-ocr on a small GPU machine at Hetzner Falkenstein. For QR-bills: zbar or zxing-cpp locally - no external provider needed.

How does this relate to ZUGFeRD/Factur-X from the EU?

ZUGFeRD (DE) and Factur-X (FR) are the same format: a PDF/A-3 with embedded XML per UN/CEFACT Cross Industry Invoice. Since 2024 it is progressively mandatory in German B2B (e-invoicing duty). Swiss fiduciaries with EU suppliers see these regularly. The pipeline detects the ZUGFeRD conformance level in PDF metadata and extracts the XML directly - no OCR needed. The XML provides supplier VAT ID, line items with rate, due date and bank details in structured form.

How is professional secrecy preserved in receipt recognition?

Three layers. Layer one: before each cloud OCR call, client-specific context (booking text, client number, margin notes) is stripped - the OCR model sees only the actual invoice content. Layer two: EU/CH region is mandatory (Azure eu-central-1, AWS eu-central-1) or a local open-source solution. Layer three: audit log records each external OCR call with hash of input receipt and hash of result - on request it is provable what was sent and what came back.

Sources

FITS YOUR STACK?

What this looks like in your business – a 30-minute intro call.

Book a call