Wie funktioniert die Beleganalyse? Ein Blick in Yomios OCR-Pipeline (AWS + Azure)

Wie funktioniert die Beleganalyse? Ein Blick in Yomios OCR-Pipeline (AWS + Azure)

Wenn du einen Beleg in Yomio scannst, passiert eine Menge zwischen dem Drücken des Auslösers und dem Anzeigen der kategorisierten Transaktion in deinem Dashboard. Dein Belegfoto durchläuft eine mehrstufige OCR-Pipeline, die den Rohtext extrahiert, normalisiert und in strukturierte Finanzdaten anreichert.

Dieser Artikel führt durch das, was in dieser Pipeline passiert. Er ist technisch – aber auch nützlich, um zu verstehen, warum einige Belege perfekt gescannt werden und andere Korrekturen benötigen, und wie wir daran arbeiten, diese Lücke zu schließen.

Wichtige Erkenntnisse

• Yomio verwendet sowohl AWS Textract als auch Azure Document Intelligence – Dual-Provider-Architektur für Redundanz und Genauigkeit
• Pipeline hat 5 Stufen: Erfassung, OCR-Extraktion, Normalisierung, Kategorisierung, Anreicherung
• Positionenextraktion ist das schwierigste Problem – Belege haben kein Standardformat
• Konfidenzbewertung markiert Felder mit niedriger Konfidenz für manuelle Überprüfung
• Multimodale Unterstützung – nimmt Bilder, PDFs und strukturierte Daten entgegen
• Aktuelle Genauigkeit: 94,7 % Positionenextraktion, 99,3 % Gesamterfassung
• Verarbeitungszeit: 2–6 Sekunden pro Beleg vom Scan bis zum kategorisierten Eintrag

Pipeline-Übersicht

Die OCR-Pipeline besteht aus fünf Stufen:

1. Erfassung – Bildvorverarbeitung und Formatvalidierung
2. OCR-Extraktion – Text- und Strukturextraktion über AWS Textract / Azure Document Intelligence
3. Normalisierung – Händlernamensabgleich, Datumsformatierung, Währungserkennung
4. Kategorisierung – Kategorienzuweisung auf Positionsebene und Gesamtebene
5. Anreicherung – Barcode-Nachschlag, Produktdaten, Benutzerkontenverknüpfung

Jede Stufe hat eingebaute Fallbacks. Wenn eine Stufe eine Ausgabe mit niedriger Konfidenz produziert, markiert die Pipeline dies, anstatt schlechte Daten weiterzuleiten.

Stufe 1: Erfassung – Bildvorverarbeitung

Bevor OCR-Engines den Beleg berühren, durchläuft das Bild eine Vorverarbeitung:

Formatnormalisierung:

• Fotos werden auf maximal 2048px an der längsten Kante skaliert
• JPEG-Komprimierung wird angewendet (Qualität 85 %) für Speichereffizienz
• PDF-Seiten werden mit 300 DPI als Bilder gerendert

Qualitätsprüfungen:

• Unschärfeerkennung – wenn das Bild zu unscharf ist (Laplacian-Varianz unter Schwellenwert), wird der Benutzer aufgefordert, es erneut aufzunehmen
• Schrägstellungserkennung – Belege, die in extremen Winkeln aufgenommen wurden, werden durch Perspektivtransformation korrigiert
• Kontrastnormalisierung – Belege mit niedrigem Kontrast (verblasstes Thermopapier) erhalten eine adaptive Histogrammentzerrung

Mehrseitenunterstützung:

• Belege, die länger als eine Seite sind, werden automatisch erkannt (Seitenwechselmarkierungen, gefaltete Kanten)
• Mehrseitige Belege werden zu einem einzigen Dokument für die Verarbeitung zusammengefügt

Stufe 2: OCR-Extraktion – AWS Textract und Azure Document Intelligence

Dies ist der Kern der Pipeline. Yomio verwendet zwei OCR-Anbieter:

AWS Textract:

• Primärer Anbieter für Standardbelege
• Branchenbeste Extraktion von gedrucktem Text
• Receipt API (Expense) speziell für Beleglayouts trainiert
• Erkennt: Händlername, Transaktionsdatum, Gesamtsumme, Zwischensumme, Steuer, Positionen, Zahlungsmethode

Azure Document Intelligence (Form Recognizer):

• Sekundärer Anbieter für Belege mit komplexen Layouts
• Besser geeignet zur Erkennung von Tabellenstrukturen in Belegen
• Wird als Fallback verwendet, wenn Textract-Konfidenzwerte unter dem Schwellenwert liegen
• Bessere Handschrifterkennung für handschriftliche Belege

Logik der Anbieterauswahl:

1. Primärer Versuch: AWS Textract
2. Wenn Textract-Konfidenz < 70 % bei Schlüsselfeldern: auch Azure Document Intelligence ausführen
3. Ausgaben vergleichen – das Ergebnis mit der höheren Konfidenz für jedes Feld auswählen
4. Wenn beide unter dem Schwellenwert: Beleg für manuelle Überprüfung markieren

Diese Dual-Provider-Architektur bedeutet, dass wenn ein Anbieter einen blinden Fleck für ein bestimmtes Belegformat hat (häufig bei nicht-englischen Belegen oder ungewöhnlichen Layouts), der andere Anbieter dies kompensieren kann.

Was jeder Anbieter extrahiert

Beide Anbieter extrahieren ähnliche Felder, jedoch mit unterschiedlichen Stärken:

Stufe 3: Normalisierung – Daten konsistent machen

Die rohe OCR-Ausgabe ist genau, aber chaotisch. "Starbucks Coffee #4521" und "Starbucks" müssen als derselbe Händler erkannt werden. "05/08/2026" und "8. Mai 2026" müssen dasselbe Datum sein. Diese Stufe übernimmt diese Transformationen.

Händlernormalisierung:

• Unscharfer String-Abgleich gegen eine Händlerdatenbank (über 50.000 Händler)
• Gruppierung auf Markenebene: "Starbucks Coffee #4521" → "Starbucks"
• Kettenidentifikation: lokale Franchises werden ihrer Muttermarke zugeordnet
• Benutzerdefinierte Aliase: wenn du einen Händler einmal umbenennst, lernt das System dies

Datumsnormalisierung:

• Erkennt das Datumsformat vom Beleg (US: MM/TT/JJJJ, EU: TT/MM/JJJJ, ISO: JJJJ-MM-TT)
• Löst Mehrdeutigkeiten durch Kontext (ein Beleg eines britischen Händlers vom 03/04/2026 → 3. April 2026)
• Zeitzonenerkennung vom Standort des Händlers

Währungsnormalisierung:

• Erkennung von Währungssymbolen ($, €, £, ¥, usw.)
• Drei-Buchstaben-Code-Erkennung (USD, EUR, GBP)
• Mehrdeutigkeitsauflösung ($ könnte USD, CAD, AUD, MXN sein – gelöst über Händlerstandort)

Betragsvalidierung:

• Gegenprüfungen: Zwischensumme + Steuer = Gesamtsumme? Gegen die Summe der Positionen verifiziert
• Rabatterkennung: wenn Positionssumme minus Gesamtsumme > Schwellenwert, wurde ein Rabatt gewährt
• Trinkgelderkennung (Restaurantbelege): Differenz zwischen Zwischensumme und Gesamtsumme, wenn eine Trinkgeldzeile vorhanden ist

Stufe 4: Kategorisierung – Intelligentes Tagging

Extrahierte Positionen müssen Budgetkategorien zugewiesen werden. Dies geschieht über ein zweischichtiges System:

Schicht 1: Händlerbasierte Regeln

• Bekannte Händler haben Standardkategoriezuordnungen
• "Kroger" → Lebensmittel (Standard), "Shell" → Transport (Standard), "Netflix" → Unterhaltung (Standard)
• Benutzer können pro Händler überschreiben: "Ich möchte Shell als Transport kategorisiert haben"

Schicht 2: KI-Kategorisierung auf Artikelebene

• Für unbekannte Händler oder Belege mit gemischten Kategorien (Target mit Lebensmitteln und Elektronik)
• Jede Position wird basierend auf Produktname, Preis und historischen Daten separat kategorisiert
• Kategorien umfassen: Lebensmittel, Essen, Transport, Einkaufen, Unterhaltung, Gesundheitswesen, Versorgung, Wohnen, Bildung, Körperpflege und 12+ Unterkategorien

Der Kategorisierungs-Konfidenzwert bestimmt, ob die Zuordnung automatisch oder zur Überprüfung vorgeschlagen wird. Bei 90 %+ Konfidenz wird die Kategorie stillschweigend angewendet. Darunter wird sie zur Benutzerbestätigung hervorgehoben.

Stufe 5: Anreicherung – Verbindung zu deinem Konto

Die letzte Stufe verbindet den verarbeiteten Beleg mit deinem Yomio-Konto:

• Benutzerzuweisung – der Beleg wird mit deinem Konto verknüpft (oder Familiengruppe, wenn Freigabe aktiviert ist)
• Bestandsaktualisierung – Positionen, die bekannten Bestandsartikeln entsprechen, lösen Mengenaktualisierungen aus (siehe unseren Bestands-Tiefgang)
• Abonnementerkennung – wiederkehrende Händler mit regelmäßigen Beträgen werden als potenzielle Abonnements markiert
• Barcode-Auflösung – gescannte Barcodes werden mit Open Food Facts und Produktdatenbanken zur Anreicherung abgeglichen
• Serienaktualisierung – der tägliche Serienzähler wird erhöht
• XP-Prämie – Scan-XP wird deinem Konto gutgeschrieben

Verarbeitungszeit und Skalierbarkeit

• Durchschnittliche Verarbeitungszeit: 2–6 Sekunden pro Beleg
• Spitzendurchsatz: Tausende von Belegen pro Minute (Lambda-basierte automatische Skalierung)
• Speicherung: Belegbilder in S3, strukturierte Daten in PostgreSQL
• CDN: Belegbilder werden über CDN für schnellen Abruf bereitgestellt

Genauigkeitsbenchmarks

Wir messen kontinuierlich die Pipeline-Genauigkeit anhand eines manuell zusammengestellten Testsatzes von 10.000 Belegen:

Wo noch Fehler auftreten:

• Handschriftliche Belege (30 % geringere Genauigkeit als gedruckte)
• Stark beschädigtes Thermopapier (verblasst, gewellt, zerrissen)
• Belege mit nicht standardmäßigen Rabattstrukturen (BOGO, Treuepunkteinlösungen)
• Mikrogedruckte Allgemeine Geschäftsbedingungen (OCR ignoriert diese bewusst)

Zukünftige Verbesserungen

Die Pipeline wird aktiv in drei Bereichen verbessert:

1. Handschrifterkennung. Die aktuelle Handschriftgenauigkeit ist die größte Lücke. Wir trainieren benutzerdefinierte Modelle auf belegspezifische Handschrift (Trinkgeldbeträge, handschriftliche Händlernamen, persönliche Notizen auf Belegen).

2. Abdeckung von Belegformaten. Internationale Belege haben unterschiedliche Layouts, Steuerstrukturen und Sprachen. Wir erweitern die Trainingsdaten der Anbieter, um mehr regionale Formate abzudecken.

3. Echtzeit-Korrekturvorschläge. Anstatt manuelle Korrekturen nach dem Scannen zu erfordern, wird die nächste Pipeline-Version Korrekturen während des Scanvorgangs vorschlagen – bevor der Beleg finalisiert wird.

Häufig gestellte Fragen