Document Information Extraction auf der BTP
Ausgangslage
Eingangsrechnungen kommen über sieben Kanäle: E-Mail-PDF, eForm, EDI/IDoc, Lieferanten-Portal, gescanntes Papier, ZUGFeRD-Hybrid, Schweizer QR-Rechnung. Pro Kanal andere Layouts, andere Pflichtfelder, andere Sprache (DE/FR/IT/EN). Klassische Template-OCR liefert bei sauberen Belegen 80-90 % Treffer, aber sobald ein Lieferant das Layout ändert oder ein neuer Lieferant dazukommt, fällt die Quote.
Unser Stack
SAP Document Information Extraction (DIE)
Cloud-Service auf der BTP, der die initiale Extraktion macht:
- Modelle pro Beleg-Typ (invoice, payment_advice, purchase_order, delivery_note, supplier_quotation, contract, sales_order, bank_statement)
- Schweiz-Lokalisierung für QR-Rechnung, MWST-Sätze, Kantone
- Mehrsprachigkeit (DE, EN, FR, IT, ES)
- OCR-Qualitätsklasse als Confidence-Wert pro Feld
LLM-Augmentation
Für die letzten 10-20 % schwieriger Fälle setzen wir ein LLM via AI Hub als zweite Stufe ein:
- DIE liefert die Felder mit niedrigem Confidence
- LLM bekommt das Original-Bild + DIE-Output + Schema
- LLM darf korrigieren, ergänzen, Felder als "unknown" markieren
- Schema-Validator prüft jedes Feld gegen das erwartete Format (IBAN, MWST-Nummer, Datum, Betrag mit Komma vs. Punkt)
Routing-Logik
Auf Basis der Gesamt-Confidence:
| Confidence | Routing |
|---|---|
| ≥ 0.95 | Auto-Buchung in SAP, Stichprobe 5% |
| 0.80-0.95 | Sichtprüfung durch Sachbearbeitung, dann Buchung |
| 0.60-0.80 | Vollprüfung, manuelle Korrektur |
| < 0.60 | Klassisches Manual-Processing |
Diese Schwellwerte werden pro Beleg-Typ und pro Kunde feinjustiert.
Architektur
mermaid
flowchart TD
K["Eingangs-Kanäle<br/>E-Mail · Lieferanten-Portal · ZUGFeRD · Scan"]
I["Ingestion auf BTP<br/>CAP-Service"]
DOX["SAP Document Information Extraction"]
C{"Confidence-Bewertung"}
L["LLM-Augmentation<br/>via AI Hub"]
V["Schema-Validation<br/>BTP-Service"]
R{"Routing nach Confidence"}
AB["Auto-Buchung<br/>SAP S/4HANA FI/MM"]
SP["Sichtprüfung<br/>SAP Build Process Automation"]
MQ["Manual-Queue<br/>Fiori-App"]
K --> I --> DOX --> C
C -->|"hoch"| V
C -->|"niedrig"| L --> V
V --> R
R --> AB
R --> SP
R --> MQ
click K call mmdInfo() "Alle Wege führen in dieselbe Pipeline: E-Mail-Inbox, Lieferanten-Portal, ZUGFeRD-Hybridrechnungen und gescannte Papierbelege. Kein Kanal bekommt eine Sonderlocke."
click I call mmdInfo() "Ein schlanker CAP-Service auf der BTP nimmt die Dokumente an, normalisiert Formate und persistiert das Original revisionssicher, bevor irgendetwas extrahiert wird."
click DOX call mmdInfo() "Der SAP-Standard-Service extrahiert Kopf- und Positionsdaten. Für Schweizer QR-Rechnungen liest er die strukturierten QR-Daten direkt – das ist genauer als jede OCR."
click C call mmdInfo() "Jedes extrahierte Feld bekommt einen Confidence-Wert. Erst die Bewertung entscheidet, ob das Dokument automatisch weiterläuft oder ein Modell nachschärft."
click L call mmdInfo() "Bei niedriger Confidence ergänzt ein LLM über den AI Hub gezielt die unsicheren Felder – mit dem Dokument-Kontext als Grundlage, nicht als Ersatz für die Extraktion."
click V call mmdInfo() "Harte Schema-Prüfung gegen Stammdaten und Pflichtfelder: Kreditor bekannt, IBAN plausibel, Beträge konsistent. Was hier scheitert, geht nie automatisch ins Buchungssystem."
click R call mmdInfo() "Drei Ausgänge nach Vertrauensstufe: vollautomatische Buchung ins S/4HANA, kurze Sichtprüfung im SAP Build Process Automation Workflow oder die Manual-Queue in einer Fiori-App."
Schweizer QR-Rechnung – die wichtigen Punkte
Die QR-Rechnung ist seit 2022 Standard und vereinfacht den Extraktions-Job für die formal korrekten Belege erheblich. Aber:
- Nicht jeder Lieferant spielt nach Regeln. Atypische QR-IBANs, fehlende Referenznummern, manuell ergänzte Beträge.
- Hybrid-Belege: PDF mit eingebettetem QR-Code, aber zusätzlich relevante Informationen (z.B. Skonto-Hinweis) im Fliesstext.
- Mehrsprachige Beleg-Texte auf demselben Beleg (DE/FR/IT).
Unsere Pipeline berücksichtigt das: QR-Extraktion zuerst, dann Cross-Check mit OCR-Pfad, dann LLM-Sichtung der Diskrepanzen.
Realistischer Wert
| Kennzahl | Vorher (Template-OCR) | Nachher (DIE+LLM) |
|---|---|---|
| Auto-Buchungs-Quote | 35-50% | 70-85% |
| Manueller Aufwand pro Rechnung (Mittel) | 4-6 Min | 1-2 Min |
| First-Time-Right-Quote | 70-80% | 92-97% |
| Onboarding neuer Lieferant | 2-4 Std (Template) | 10 Min (Schema) |
| Anteil Sonderfälle (manuell) | 20-30% | 5-10% |
Die Spannen reflektieren: bei sauberen Lieferanten- und Beleg-Strukturen das obere Ende, bei Mischlandschaften das untere. Wir messen das in der ersten 4-Wochen-Phase und optimieren die Schwellwerte dann iterativ.
Lieferanten-Onboarding
Klassisch braucht ein neuer Lieferant ein neues OCR-Template (2-4 Std Aufwand). Mit DIE + LLM: keine Templates mehr, nur ein Schema. Onboarding eines neuen Lieferanten dauert dann das, was eine fachliche Stammdaten-Erfassung sowieso kosten würde.
Datenschutz
- Alle Belege bleiben in der gewählten Region (CH oder EU)
- LLM-Augmentation ist optional pro Mandant abschaltbar
- Bei Verträgen mit personenbezogenen Daten (Kreditoren-Stamm, Reisekosten-Belege) ist eine PII-Maskierung vor dem LLM-Call möglich
Was wir nicht versprechen
- 100 % Auto-Buchung. Belege mit handschriftlichen Korrekturen, ungewöhnlichen Layouts oder Sprache ausserhalb der unterstützten Sprachen werden weiterhin Sichtung brauchen. Realistisches Ziel ist 70-85% Auto-Quote nach 6-12 Monaten Pflege.
- Universal-Klassifikation. Die Beleg-Typen sind fix; bei neuen Beleg-Klassen müssen Schema und ggf. Modell-Auswahl angepasst werden.
- Kosten-Stabilität ohne Mengen-Steuerung. Bei stark schwankenden Volumina lohnt sich eine Tarif-Optimierung.
Stand: 2026-05-10
