ELONIQ / ELONIQ Handbuch
Deutsch English Français
Übersicht / Verarbeitung / Document Classifier

Document Classifier

Sieben-Stage-Klassifikations-Pipeline mit Strategien für ERP und DATEV

Der Document Classifier ist die zentrale Klassifikations-Engine in ELONIQ. Er analysiert eingehende Dokumente, erkennt ihren Typ, extrahiert Metadaten und schlägt — über austauschbare Strategien — auch konkrete Buchungssätze vor. Sieben Pipeline-Stages (OCR, Regex, LLM, SmartDB, Lernen, Heuristik, E-Rechnung) arbeiten kaskadiert und können einzeln aktiviert oder übersprungen werden.

Übersicht

Der Document Classifier verarbeitet eingehende Dokumente in einer mehrstufigen Pipeline. Jede Stage kann einzeln konfiguriert, aktiviert oder deaktiviert werden — und liefert ihre Ergebnisse mit einer Konfidenz, die in den nachfolgenden Stages weiterverwendet wird.

Pipeline-Stages
  • OCR — Texterkennung. Erste Stage, immer obligatorisch. Tesseract (lokal) oder Azure (Cloud).
  • Regex — deterministische Feldextraktion über PCRE-Muster. Schnell und billig, ideal für strukturierte Felder.
  • LLM — KI-basierte Klassifikation und Extraktion. Teuer, dafür flexibel bei freien Texten.
  • SmartDB — Stammdaten-Lookup. Validiert extrahierte Felder gegen die ERP-DB und reichert sie an (Mandant, Kreditor, Debitor).
  • Lernen — sammelt manuelle Korrekturen und schlägt sie als Lernregel vor.
  • Heuristik — Regelbasierte Fallbacks für Felder ohne klares Pattern.
  • E-Rechnung — Sonderbehandlung für ZUGFeRD/XRechnung-Dokumente (strukturierte XML-Daten überschreiben OCR-Ergebnisse).
Strategie-System

Die SmartDB-Stage delegiert die eigentliche Lookup-Logik an eine Strategie. Drei Strategien sind verfügbar:

  • default — einfacher Tabellen-Lookup ohne Buchungslogik. Für eigene SQL-Joins über die SmartDB-Tables.
  • erp — generische ERP-Strategie. Drei logische Tabellen (Client/Vendor/Customer), Single- oder Multi-Tenant. Funktioniert mit jedem ERP, dessen Schema sich darauf abbilden lässt.
  • datev — DATEV-Integration mit Mandanten-Logik. Erfordert aktivierte DATEV-Integration.

Strategien sind über das StrategyWithUI-Interface auch in der Test-Page mit eigenem Renderer ausstattbar (siehe DATEV-Renderer als Beispiel).

Trigger

Die Klassifikation kann auf zwei Wegen gestartet werden: über Watchfolder (Dateisystem-Scan) oder über Workflow-Knoten in ELO. Beide Trigger-Typen können parallel betrieben werden.

Funktionen

  • Sieben-Stage-Pipeline — OCR · Regex · LLM · SmartDB · Lernen · Heuristik · Elektronische Rechnung. Jede Stage hat eine eigene Konfigurationsseite und Stage-Farbcodierung.
  • Multi-Engine OCR — Tesseract (lokal, kostenlos), Azure Document Intelligence, Azure F1.
  • Regex-Stage — deterministische Feldextraktion über PCRE-Muster, deutlich schneller und billiger als LLM.
  • LLM-Klassifikation — OpenAI, Azure OpenAI, Ollama (lokal), Anthropic. Promptbasierte Klassifikation und Feldextraktion.
  • SmartDB-Lookup — beliebige Datenbanken anbinden, Stammdaten matchen (exact, fuzzy, contains).
  • Strategie-System — austauschbare Klassifikationsstrategien: default (Standard-Lookup), erp (eingebaute generische ERP-Strategie für Client/Vendor/Customer), datev (DATEV-Integration mit Mandanten-Logik).
  • Single- und Multi-Tenant — ERP-Strategie unterstützt sowohl Mittelstand (ein Mandant) als auch Steuerkanzleien (n Mandanten).
  • Lernsystem — sammelt manuelle Korrekturen und schlägt sie automatisch beim nächsten ähnlichen Beleg vor.
  • Watchfolder + Workflow-Trigger — Klassifikation per Dateisystem-Scan oder ELO-Workflow-Knoten.
  • Test-Page mit Modal-Ergebnis — beliebige Datei hochladen, alle Stages live durchlaufen, Strategie-Resultat in einem dedizierten Bootstrap-Modal anzeigen.
  • Privacy-Modus — komplett lokale Pipeline ohne Cloud-Calls für sensible Belege.
  • Diagnose-Page — letzte N Klassifikationen mit Stage-Trace, Konfidenzen, OCR-Text und LLM-Antwort.
  • Stage-Konfidenzschwellen — pro Stage und global feinjustierbar.

Verwendung

1. Pipeline-Reihenfolge planen

Welche Stages sind für meine Belege relevant? Strukturierte Rechnungen brauchen meist nur OCR + Regex + SmartDB. Freie Texte (Verträge, Mails) brauchen LLM. ZUGFeRD-Rechnungen profitieren von der E-Rechnungs-Stage.

2. Masken und Entitäten kennen

Unter Daten → Masken die ELO-Masken durchsehen, auf die klassifiziert werden soll. Unter Daten → Entitäten logische Gruppierungen anlegen, wenn z.B. mehrere Masken denselben Belegtyp repräsentieren.

3. OCR konfigurieren

Tesseract für lokal/günstig, Azure für höhere Erkennungsrate. Mit der Test-Page einzelne Belege durchlaufen lassen und das OCR-Ergebnis prüfen.

4. Regex-Patterns schreiben

Für die deterministischen Felder (Rechnungsnummer, Datum, Betrag) PCRE-Patterns hinterlegen. Mit der Test-Page validieren und Konfidenz anpassen.

5. LLM-Provider anbinden (optional)

Erst aktivieren, wenn Regex und SmartDB allein nicht reichen. stoponfirstsuccessful aktivieren, damit LLM bei sicheren Regex-Treffern übersprungen wird — spart Kosten.

6. SmartDB-Strategie wählen

Bei Stammdaten-Anbindung an ein ERP: ERP-Strategie aktivieren, Client/Vendor/Customer-Tabellen mappen, mit 'Verbindung testen' validieren. Bei DATEV-Kanzleien stattdessen die DATEV-Integration nutzen.

7. Trigger einrichten

Watchfolder für Datei-basierte Quellen (Scanner, Mailimporter), Workflow-Trigger für ELO-interne Posteingangs-Prozesse.

8. Test-Page laufen lassen

Vor Produktivnahme einen festen Belegsatz (5–10 typische Belege) über die Test-Page laufen lassen. Strategie-Ergebnis im Modal prüfen, Konfidenzschwellen feinjustieren.

9. Diagnose im Betrieb

Im ersten Monat täglich, danach wöchentlich die Diagnose-Page prüfen. Korrekturen der Sachbearbeiter bei aktiviertem Lernsystem fließen automatisch in Lernprofile.

Best Practices

Stage-Reihenfolge denken

OCR ist immer obligatorisch — ohne Text kann keine andere Stage arbeiten. Danach hat sich diese Reihenfolge bewährt: Regex zuerst für die deterministischen Felder (Rechnungsnummer, Datum, Beträge), LLM nur wenn Regex nicht reicht (Beschreibungstexte, weiche Klassifizierung), SmartDB ganz am Ende als Validierung gegen Stammdaten. LLM ist die teuerste Stage, deswegen Stop on first successful aktivieren — sobald Regex eine hohe Konfidenz erreicht, wird LLM übersprungen.

Konfidenzschwellen kalibrieren

Die zwei globalen Schwellen unter Basis entscheiden über die Pipeline:

  • maskconfidencethreshold (Default 0.65): unter diesem Wert wird die erkannte Maske als unsicher markiert. Lieber konservativ — eine falsch erkannte Maske produziert falsche Felder.
  • fieldconfidencethreshold (Default 0.5): unter diesem Wert wird ein extrahierter Feldwert verworfen. Bei vielen False-Positives runter, bei vielen verlorenen Werten hoch.

Werte schrittweise in 0.05-Schritten anpassen und mit der Test-Page gegen einen festen Belegsatz prüfen.

Privacy-Modus für sensible Belege

Aktiviere privacysensitive (Datenschutzmodus) für Mandanten mit besonders schützenswerten Daten (HR, Gesundheit, Geheimhaltungsvereinbarungen). Cloud-OCR und Cloud-LLM werden dann komplett übersprungen, nur lokale Provider laufen. Performance leidet, Compliance gewinnt.

Watchfolder vs. Workflow-Trigger

Watchfolder eignen sich für 'Push'-Szenarien (Mailimporter, Scanner, FTP-Ablagen). Workflow-Trigger eignen sich für ELO-interne Prozesse (Posteingangs-Workflow, Genehmigung). Beide können parallel laufen, ohne sich zu stören — der Job-ID-Logger verhindert Doppelverarbeitung.

Lernsystem von Anfang an aktivieren

Das Lernsystem zahlt sich erst nach einigen Wochen aus, weil es die manuellen Korrekturen der Sachbearbeiter sammelt. Je früher es läuft, desto besser werden die Vorschläge — auch wenn die ersten Wochen wenig sichtbarer Effekt da ist.

SmartDB-Lookups nur mit ERP/DATEV-Strategie

Die Standard-SmartDB sucht nach Stammdaten ohne Buchungslogik. Für tatsächliche Buchungssatz-Vorschläge braucht es eine Strategie — entweder die mitgelieferte ERP-Strategie (generisch, drei Tabellen Client/Vendor/Customer) oder die DATEV-Integration für DATEV-Kanzleien. Ohne Strategie liefert die SmartDB nur isolierte Felder ohne Mandanten-Kontext.

Diagnose nutzen, nicht ignorieren

Die Diagnose-Page zeigt die letzten Klassifikationen mit Stage-Trace und Konfidenzen pro Feld. Auch wenn alles 'läuft', regelmäßig reinschauen — ein leiser Drift in den Konfidenzwerten (z.B. nach einem LLM-Modellwechsel) wird hier sofort sichtbar.

Beispiele

Eingangsrechnung — Regex + ERP-Strategie

Eine Eingangsrechnung wird per Watchfolder importiert.

  1. OCR liest den PDF-Text aus.
  2. Regex extrahiert RechnungsNr, Datum, Betrag und USt-IdNr mit hoher Konfidenz.
  3. Maske EingangsRechnung wird sicher erkannt (Konfidenz 0.92).
  4. SmartDB mit ERP-Strategie sucht über USt-IdNr und IBAN den Kreditor in der ERP-DB.
  5. Mandant und Kreditor werden ins Ergebnis übernommen (KREDITOR_GUID, KREDITOR_NAME, MANDANT_NR …).
  6. Workflow-Trigger startet den Posteingang in ELO mit allen Feldern vorbelegt.
Vertrag — LLM-Klassifikation

Ein PDF-Vertrag aus dem Posteingang.

  1. OCR liefert den Volltext.
  2. Regex findet kein passendes Muster (Vertragsformate sind individuell).
  3. LLM klassifiziert auf Vertrag und extrahiert Vertragspartner, Laufzeit, Kündigungsfrist.
  4. SmartDB validiert den Vertragspartner gegen Stammdaten.
  5. Lernsystem merkt sich die manuelle Bestätigung des Sachbearbeiters — beim nächsten ähnlichen Vertrag wird der Vorschlag direkt übernommen.
Multi-Tenant DATEV-Kanzlei

Eine DATEV-Kanzlei verarbeitet Belege für 50+ Mandanten in einer gemeinsamen DB.

  1. Beleg wird per Mailimporter importiert.
  2. DATEV-Strategie ermittelt den Mandanten aus dem Beleg (Empfänger-Anschrift, USt-IdNr).
  3. Anschließend wird der Kreditor unter diesem Mandanten gesucht (mandantenscharf).
  4. Buchungskonto und Steuerschlüssel werden aus den Stammdaten übernommen.
Single-Tenant Mittelstand

Ein mittelständischer Betrieb hat genau einen Mandanten.

  1. ERP-Strategie im Single-Tenant-Modus konfiguriert.
  2. Mandant ist statisch (MANDANT_NR 1000, MANDANT_NAME 'Acme GmbH').
  3. Bei jedem Beleg wird der statische Mandant gesetzt, Kreditor/Debitor-Suche ignoriert die Mandanten-Spalte.