KI-Belegerkennung für Schweizer Belege: QR-Rechnung, Quittungen, PDF-Rechnungen strukturiert erfassen

Worum es geht

Belegerkennung ist die Grundoperation fast jeder KI-Automatisierung in der Treuhand-Praxis. Bevor die KI klassifizieren, vorbuchen oder eine MWST-Abrechnung vorbereiten kann, muss der Beleg in strukturierte Daten verwandelt werden: Betrag, Datum, Lieferant, UID, MWST-Ausweis, IBAN/QR-IBAN, Referenznummer. Genau das leistet die OCR-Pipeline.

Für den Schweizer Kontext gibt es einen entscheidenden Anker: die QR-Rechnung. Seit dem 30. Juni 2020 ist sie das einzige Rechnungs-Format mit roten und orangen Einzahlungsscheinen vollständig abgelöst. Der QR-Code trägt bis zu 997 Zeichen strukturierte Daten - definiert durch den SIX-Standard "Swiss QR Code". Aus diesem Code lassen sich Begünstigter, IBAN/QR-IBAN, Betrag und Referenznummer mit nahezu 100% Genauigkeit lesen, ohne dass OCR im klassischen Sinn nötig wäre. Eine einfache QR-Decoder-Bibliothek (z.B. zbar oder zxing) liefert die strukturierten Daten direkt.

Für alles, was nicht QR-Rechnung ist - Restaurantquittungen, Tankstellen-Belege, Hotelrechnungen, PDF-Rechnungen aus dem EU-Ausland, handschriftliche Notizen - kommen klassische OCR-Modelle zum Einsatz: kommerziell AWS Textract, Azure Document Intelligence, Google Document AI, oder Open-Source surya-ocr, paddleocr, marker. Die Wahl hängt von Belegart, Volumen und Datenschutz-Anforderung ab.

Warum es wichtig ist

In einem 12-Personen-Treuhand-Buro mit 200 Mandanten und 4000-8000 Belegen pro Monat ist die manuelle Belegerfassung der grösste Zeitfresser. Eine Sachbearbeiterin braucht im Durchschnitt 45-90 Sekunden pro Beleg, je nach Qualität: QR-Rechnung mit klarem Layout schneller, Foto einer zerknitterten Quittung deutlich langsamer. Die KI-Belegerkennung dreht das Verhältnis um: 5-10 Sekunden pro Beleg, der Rest ist Prüfung.

Drei spezifisch schweizerische Aspekte machen die Belegerkennung 2026 wichtiger als noch 2020. Erstens: QR-Rechnungs-Pflicht. Seit Mitte 2020 alleinige Rechnungsform, seit 2023 mit klaren Compliance-Erwartungen der Banken (Reject von nicht-QR-konformen Aufträgen). Zweitens: Pflicht zur GeBüV-konformen Archivierung. Art. 957a OR plus die Geschäftsbücherverordnung (SR 221.431) verlangen unveränderbare Aufbewahrung der elektronischen Belege für zehn Jahre. Drittens: die zunehmende EU-Verbreitung des ZUGFeRD/Factur-X-Formats - PDF-Rechnungen mit eingebetteter XML-Struktur. Wer EU-Lieferanten hat, sieht solche Belege regelmässig und muss die XML-Datenstruktur lesen, nicht nur den Pixel-Layer.

Aus Daten-Sicht ist die Belegerkennung auch der "Eingangs-Punkt" für den ganzen Audit-Trail nach Art. 957a OR: das Original-Bild oder PDF wird unveränderbar archiviert (z.B. S3 Object-Lock, Wasabi mit Compliance-Lock, oder Schweizer Anbieter wie Infomaniak Swiss Backup). Hash-Signatur und Zeitstempel werden gesetzt. Erst danach läuft die OCR-Pipeline. Diese Reihenfolge - "archivieren vor verarbeiten" - ist die Grundbedingung der Revisionsfähigkeit.

Wie es funktioniert

Die Pipeline ist sechsstufig.

Stufe 1 - Eingang und Archivierung: Der Beleg trifft per E-Mail-Anhang, Dext/Pleo-Connector, Mandantenportal-Upload oder Scanner-Direkteinwurf ein. n8n schreibt das Original sofort in den GeBüV-konformen Archiv-Bucket mit Object-Lock und berechnet einen SHA-256 Hash. Erst nach erfolgreicher Archivierung beginnt die Verarbeitung.

Stufe 2 - Belegart-Erkennung: Ein leichtgewichtiger Klassifikator (z.B. ein kleines Vision-Modell oder eine einfache Heuristik auf PDF-Metadaten) entscheidet: ist das eine QR-Rechnung (rechts unten der CH-Cross-Marker), eine PDF-Rechnung mit ZUGFeRD-XML, eine Restaurantquittung, eine Hotelrechnung, ein Tankstellen-Beleg, ein handschriftlicher Beleg, etwas anderes. Die Routung hängt davon ab.

Stufe 3 - QR-Decode oder klassische OCR: Bei QR-Rechnung wird der QR-Block mit zbar/zxing dekodiert - 30 strukturierte Felder direkt verfügbar, inklusive QR-IBAN (CH formatiert), Begünstigter, Betrag, Referenznummer (27-stellig QR-IID-Prüfziffer-konform). Bei ZUGFeRD-PDF wird der eingebettete XML-Teil extrahiert. Bei allem anderen läuft klassische OCR: AWS Textract bei US-akzeptiertem Hosting, Azure Document Intelligence eu-central-1 bei revDSG-Wunsch, Google Document AI bei hoher Genauigkeit auf gemischten Belegen. Open-Source: surya-ocr für Layout-aware Lesen, marker für Markdown-Konvertierung komplexer PDFs, paddleocr für breite Sprachunterstützung.

Stufe 4 - Validierung: Mehrere harte Prüfungen laufen jetzt. UID-Format: CHE-xxx.xxx.xxx, Prüfziffer nach UIDV-Algorithmus. IBAN: CH-Format, Prüfziffer nach ISO 13616 (Mod-97). QR-IBAN: spezielle Schweizer Variante mit Prüfziffer-Logik. Datum: ist es plausibel (nicht in der Zukunft, nicht vor Gründung des Mandanten)? Betrag: passt die Summenrechnung der Positionen? MWST-Ausweis: passt der ausgewiesene Steuersatz zum Datum (8.1% nach 1.1.2024, 7.7% vorher)?

Stufe 5 - KI-Anreicherung: Wenn der reine OCR-Text strukturiert vorliegt, kann ein Sprachmodell die "weichen" Felder nachfüllen: Geschäftszweck der Position (Bewirtung, Büro-Material, Hosting, Reise), Verteilschlüssel bei gemischter Verwendung, vermutete Kostenstelle. Das ist optional und wird typischerweise im Anschluss von der MWST-Vorbereitungs-Pipeline genutzt.

Stufe 6 - Übergabe an ERP: Die strukturierten Daten gehen via API in das ERP-System des Buros (Abacus REST, Bexio API, Sage 200 API, Topal API), als Entwurfs-Buchung. Der Sachbearbeiter prüft, korrigiert und gibt frei. Audit-Log dokumentiert: Original-Hash, OCR-Engine, OCR-Resultat, Validierungs-Ergebnis, Endbuchung, Freigeber.

Pipeline in 7 Schritten

1. 01Eingang: Beleg trifft per E-Mail, Dext/Pleo, Portal-Upload oder Scanner ein. n8n vergibt eine Eingangs-ID und Zeitstempel.
2. 02Archivierung: Original geht unverändert in den GeBüV-Bucket (S3 Object-Lock, Wasabi Compliance-Lock, Infomaniak Swiss Backup). SHA-256 Hash wird berechnet.
3. 03Belegart-Erkennung: Vision-Modell oder PDF-Metadaten-Heuristik unterscheidet QR-Rechnung, ZUGFeRD-PDF, Quittung, handschriftlicher Beleg.
4. 04Strukturextraktion: QR-Decoder für QR-Rechnungen (zbar), XML-Parser für ZUGFeRD, klassische OCR (Textract EU, Azure EU, Document AI, oder surya-ocr lokal) für den Rest.
5. 05Validierung: UID-Prüfziffer (UIDV), IBAN-Prüfziffer (ISO 13616), QR-IID-Prüfziffer, Datum-Plausibilität, Summen-Plausibilität, MWST-Satz-Datum-Konsistenz.
6. 06Optional KI-Anreicherung: Sprachmodell füllt Geschäftszweck und Kostenstelle vor. Bei Unsicherheit Markierung "Prüfung Mensch".
7. 07ERP-Übergabe: Strukturierte Daten als Entwurfs-Buchung in Abacus, Bexio, Sage oder Topal. Sachbearbeiter prüft, korrigiert, gibt frei. Audit-Log schliesst die Spur.

Wann einsetzen

Belegerkennung ist die wirtschaftlichste KI-Investition in jedem Treuhand-Buro mit über 1000 Belegen pro Monat. Anders gesagt: ab dieser Schwelle ist die Frage nicht ob, sondern welche OCR-Engine.

Konkrete Konstellationen: Treuhand-Buros mit hohem KMU-Anteil (viele Klein-Belege), Buros mit grossen E-Commerce-Mandanten (täglich hunderte Belege), Buros mit Mandanten im Gastrogewerbe (extreme Belegfrequenz, viele kleine Quittungen), Buros mit Bauunternehmen-Mandanten (viele Materialrechnungen).

Besonders wirtschaftlich, wenn (a) der Mandant Dext, Pleo oder eine andere Receipt-App nutzt - dann ist der Eingangskanal schon strukturiert; (b) das Büro ein modernes ERP wie Abacus 2024, Bexio oder Topal Solution nutzt - die API-Anbindung ist Standardware; (c) die Belege überwiegend QR-Rechnungen sind - die Pipeline kann für 60-80% der Belege auf reine QR-Decodierung setzen und nur den Rest klassisch OCRen.

Wann NICHT

Nicht einsetzen bei extrem kleinen Volumen (< 200 Belege pro Monat) - die Einrichtung amortisiert sich nicht.

Nicht einsetzen ohne GeBüV-konformes Archiv. Wer die Originale nur in Cloud-Speichern ohne Object-Lock ablegt, riskiert eine Beanstandung der Revisionsstelle und in schweren Fällen die Verwerfung der Buchhaltung im Steuerverfahren. Erst Archiv, dann OCR.

Nicht einsetzen ohne Datenschutz-Prüfung. Belege enthalten regelmässig Mandantendaten, manchmal Gesundheitsdaten (Arztrechnungen), oft Bankverbindungen. Wer Belege an US-OCR-Anbieter (AWS Textract us-east-1, Google Document AI global) ohne Transfer-Impact-Assessment schickt, verstösst gegen revDSG. Lösung: EU-Region (Azure Document Intelligence eu-central-1, AWS Textract eu-central-1), Schweizer Region wo verfügbar, oder lokale Open-Source-OCR (surya-ocr, paddleocr) auf eigener Hardware.

Nicht einsetzen ohne Validierung. Eine OCR-Engine, die "ungefähr richtig" liest, ist gefährlich. Eine UID-Prüfziffer-Validierung muss zwingend laufen; eine IBAN-Prüfziffer-Validierung ebenso. Sonst wandern Tippfehler aus dem OCR-Layer als "korrekte Daten" weiter und werden zur Quelle teurer Korrekturen.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. SIX - Swiss QR-Bill Implementation Guidelines v2.3 (QR-IBAN, QR-IID, Referenznummer) · 2025-09
2. marker - PDF to structured Markdown (Open Source OCR pipeline) · 2026-03
3. surya-ocr - layout-aware multilingual OCR (Open Source) · 2026-04
4. Azure AI Document Intelligence (eu-central-1) - Layout and Invoice models · 2026-04
5. GeBüV - Geschäftsbücherverordnung (SR 221.431), digitale Aufbewahrung · 2024-01
6. ZUGFeRD/Factur-X - Hybrid PDF/A-3 Invoice Format (UN/CEFACT CII) · 2025-10