MIC

Etablierte Firma

Alle Videos anzeigen

AI-based document processing

Maximilian Sandberger von MIC demonstriert in seinem devjobs.at TechTalk die Funktionsweise der automatischen Rechnungserfassung und erklärt die Grundgedanken bei der Entwicklung dieses Features.

Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.

Video Zusammenfassung

In AI-based document processing erklärt Maximilian Sandberger (MIC), wie MIC Handelsdokumente mit generativer KI automatisiert verarbeitet, um manuelle Dateneingaben zu reduzieren. Kern ist eine Multi-Provider‑Vision API für „structured output“ nach JSON (inkl. OCR, Klassifikation, Dokument-Splitting/Streaming) sowie eine UI (MicDoc/DocFlow) mit Validierungen, manueller Korrektur und Übergabe an Zoll-Module. Das Demo zeigt den Upload von PDFs/Bildern, das Extrahieren von Positionen und Summen, das Beheben von Fehlern bei schwacher Bildqualität und wie Teams von Human‑in‑the‑Loop zur Vollautomatisierung übergehen können.

KI-gestützte Dokumentenverarbeitung bei MIC: Strukturierte Ausgaben, Vision API und DocFlow für Zoll- und Handelsprozesse

Einleitung: Was wir aus „AI-based document processing“ mit Maximilian Sandberger (MIC) mitgenommen haben

Bei DevJobs.at verfolgen wir besonders aufmerksam, wie KI in reale Produktivprozesse wandert. In der Session „AI-based document processing“ gab Maximilian Sandberger, Data Scientist bei MIC, einen kompakten, aber dichten Einblick in genau so ein Vorhaben: die Automatisierung der Erfassung und Verarbeitung von Handelsdokumenten. MIC – ein globaler Anbieter von Software für Zoll und Trade-Compliance – hat seit 2022 ein eigenes AI- bzw. Data-Science-Team aufgebaut, um KI-gestützte Funktionen in bestehende Produkte zu integrieren.

Der geschilderte Use Case ist auf den ersten Blick klar, in der operativen Tiefe aber technisch anspruchsvoll: Dokumente wie Rechnungen, Packlisten und Excel-Dateien kommen in der Praxis meist als PDF oder Anhang per E‑Mail – nicht über strukturierte Schnittstellen. Rund „80% der Geschäftsdokumente sind noch PDFs“ und erfordern manuelle Eingabe in die Software. Ziel: diese Eingaben automatisieren, ohne das Qualitätsniveau oder regulatorische Anforderungen zu verletzen.

Der Kernansatz im Vortrag: „strukturierte Ausgaben“ (Structured Output) mit generativen Modellen, die auf vordefinierte Schemata mappen und die Ergebnisse als gültiges JSON ausgeben. MIC hat dafür eine eigene Vision API und eine UI namens MicDoc/DocFlow aufgebaut, die von der Ingestion über OCR, Klassifikation, Chunking, Extraktion und Validierung bis zur Übergabe an weitere MIC-Module (etwa für Zollanmeldungen) reicht.

Im Folgenden fassen wir das technische Vorgehen, die Architekturentscheidungen und die praktischen Learnings aus der Session zusammen – fokussiert auf das, was für Entwickler:innen und Tech-Teams übertragbar ist.

Das Geschäftsproblem: Manuelle Eingaben dominieren die Trade-Dokumente

Dokumente kommen überwiegend als PDF, E‑Mail-Anhang oder Bild herein; auch Excel ist üblich.
Strukturierte EDI/API-Schnittstellen sind nicht der Regelfall; stattdessen landet vieles im Posteingang.
Resultat: Benutzer:innen tippen Inhalte händisch in die Zielsysteme – fehleranfällig, zeitintensiv, schwer skalierbar.

Die Chance für KI liegt in der Brücke zwischen unstrukturierten (oder halbstrukturierten) Eingaben und strukturierten Datenfeldern in den MIC-Modulen. Handelsdokumente folgen zwar Mustern (z. B. Rechnungsnummer, Betrag, Positionen), aber Format, Layout, Sprache und Qualität variieren stark – insbesondere bei Scans oder Fotos. Jede robuste Lösung braucht daher:

eine breite Ingestion-Pipeline (E‑Mail, FTP, manueller Upload),
OCR für Bilder/Scans, die keinen eingebetteten Text haben,
ein Verfahren zur Dokumenttyp-Erkennung (z. B. Rechnung vs. Packliste),
eine Extraktion mit Schema-Garantie (JSON mit festgelegten Feldern),
Validierungen (z. B. Summenprüfung),
und ein UI für Human-in-the-Loop.

Structured Output als Hebel: Vordefinierte JSON-Schemata für stabile Extraktion

Der zentrale technische Hebel ist die Fähigkeit moderner generativer Modelle, strukturierte Ausgaben zu liefern. Sandberger beschreibt, wie man dem Modell (er nennt u. a. „JGPD“) ein vorab definiertes Formular bzw. Datenmodell vorgibt – beispielsweise für eine Rechnung: Rechnungsnummer, Gesamtbetrag, Positionen, Merkmale pro Position. Das Modell erhält den Dokumentinhalt (Text, Bild oder aus PDF extrahiierter Text) und soll das Ziel-Schema ausfüllen.

Wichtig daran:

Das Ergebnis ist ein „gültiges JSON“, das direkt in nachgelagerte Schnittstellen fließt.
Durch die Schema-vorwärts-Strategie wird verhindert, dass das Modell freiformatierte, schwer parsbare Texte liefert.
Das gleiche Prinzip funktioniert mit Textdateien (HTML, XML, JSON), PDFs mit Textlayer und – in Grenzen – auch mit Bildern.

Dieser Schema-First-Ansatz reduziert Integrationsaufwand, Fehlertoleranz im Parsing und beschleunigt die Überführung in die operativen Module. Gerade im regulierten Kontext (Zoll) sind deterministische Schnittstellenformate eine essenzielle Voraussetzung.

Die MIC Vision API: Provider-agnostisch, multimodal und schemaorientiert

Um Structured Output produktiv nutzbar zu machen, hat MIC eine eigene Vision API entwickelt. Sie dient als Extraktionsdienst, der:

diverse Eingaben akzeptiert (Text, Excel, PDFs, Bilder),
relevante Informationen anhand eines vorgegebenen Schemas extrahiert,
und als strukturiertes JSON zurückliefert.

Warum eine eigene API?

Modellvielfalt: „Es gibt viele AI-Modelle.“ Große Anbieter sind laut Sandberger „OpenAI und Dropic“. Kunden haben oft bereits Verträge mit bestimmten Providern – deshalb ist Wahlfreiheit wichtig (z. B. OpenAI, Mistral).
Hosting-Optionen: MIC kann auch eigene Modelle hosten – genannt werden das „Alibaba crane model“ und „Meta Llama“. Allerdings ist Self-Hosting teuer (GPU-Knoten) und häufig weniger kosteneffizient und performanter als externe Provider.
Abstraktion: Die Vision API kapselt die Unterschiede und erlaubt, Provider transparent zu wechseln bzw. auszuwählen.

Das Ergebnis ist eine technische Entkopplung: Kunden können den Provider wählen, MIC kann Modelle vergleichen, aktualisieren oder fallbacken, ohne die produktnahe Oberflächenlogik neu zu bauen.

MicDoc/DocFlow: Die UI-Schicht für Upload, Review und Übergabe

Die UI (von Sandberger als „MicDoc“ bezeichnet, in der Demo als „DocFlow“ gezeigt) bildet den operativen Rahmen:

Dokumenteingang: Upload per Dateiupload, FTP oder E‑Mail.
Extraktion: Übergabe an die Vision API, Anzeige der extrahierten Felder.
Validierung: Summenprüfungen, Plausibilitätschecks; manuelles Korrigieren möglich.
Übergabe: Export an weitere MIC-Module, z. B. zur Zollanmeldung.

Wichtig ist der Human-in-the-Loop-Ansatz. Zwar kann die gesamte Kette automatisiert werden (etwa wenn „die Summen passen“), aber der empfohlene Startmodus nutzt manuelle Prüfung und Upload – um Vertrauen in Datenqualität und Prozessstabilität aufzubauen.

Der End-to-End-Prozess: Von der Ingestion bis zur Zollanmeldung

Sandberger legt den Ablauf als Sequenz dar. Aus unserer Sicht hilft dieser Bauplan, ähnliche Pipelines in Produktivsysteme zu bringen.

1) Ingestion: E‑Mail, FTP, Upload

Eingangskanäle sind breit aufgestellt, um realistische Workflows abzudecken.
Ziel ist, Dokumente schnell in die Verarbeitung zu bringen, unabhängig von Quelle und Format.

2) OCR: Text aus Scans/Fotos gewinnen

Nicht alle PDFs enthalten echten Text (viele sind nur Bilder von Text). Ohne OCR „kann man den Text nicht extrahieren“.
Ein vorgeschalteter OCR-Schritt hebt den Textlayer, sodass die nachgelagerte Extraktion mit strukturiertem Output greifen kann.

3) Klassifikation: Dokumenttyp bestimmen

Manuell oder automatisiert: „Sie sagen, dieses Dokument ist eine Rechnung … oder Sie lassen die KI wählen.“
Einfache Heuristiken („Invoice“ im Dokumentkopf) genügen oft, um Rechnungen vs. Packlisten zu unterscheiden.

4) Splitting & Chunking: Kontextlimits und Ausgabebegrenzungen berücksichtigen

Generative Modelle haben Kontextgrenzen. 500-seitige PDFs „kann man nicht auf einmal einfügen“.
Auch die Ausgabemenge ist begrenzt. Beispiel: Excel mit 5.000 Zeilen – Input geht, aber die Ausgabe „kann nicht so viel Text auf einmal generieren“.
Lösung: Dokumente in Abschnitte teilen, schrittweise extrahieren und Ergebnisse streamen/zusammenführen.

5) Extraktion via Vision API: Strukturierte Ausgaben in JSON

Eingaben: Text, Excel, PDFs, Bilder (Bilder eher „separater Use Case“, aber unterstützt).
Vorgaben: Ein fixiertes Schema (z. B. Rechnung mit Feldern und Positionen) wird ans Modell übergeben.
Ergebnis: „gültiges JSON“, das die Zieloberfläche füllt oder in APIs weitergegeben wird.

6) UI-Validierung: Prüfen, korrigieren, freigeben

Die UI zeigt Dokument und extrahierte Felder nebeneinander.
Es gibt Validierungen (z. B. Summenprüfung). Fehler werden sichtbar und können manuell korrigiert werden (z. B. fehlender Einzelpreis bei schwacher Bildqualität).
Nach Freigabe geht es in die MIC-Module „um das an den Zoll zu deklarieren“.

7) Optionale Automatisierung: Regeln für Dunkelverarbeitung

Wenn bestimmte Bedingungen erfüllt sind (etwa Summen stimmen), kann der Transfer automatisch erfolgen – „man kann den gesamten Prozess automatisieren“.
Für den Start empfiehlt Sandberger „menschliche Überprüfung und manuellen Upload“, um ein Gespür für das System zu bekommen.

Die Demo: Von der Test-Transaktion zur validierten Rechnung

In der Live-Demo zeigt Sandberger den Durchstich:

Aufruf des Launchpads und von DocFlow.
Anlegen einer neuen Transaktion (z. B. Import) mit Referenz („test“ oder „demo“).
Auswahl des Dokumenttyps (z. B. Rechnung) und Upload vorbereiteter Dokumente (PDFs, ein Bild).
Start der Extraktion („Extract“) – die Dokumente gehen an die Vision API.
Anzeige: Rechts das jeweilige Dokument, links die extrahierten Felder.

Zur Illustration nutzt er eine Fotografie einer Rechnung (Spar), „ein schlechtes Foto, aber als Beispiel“. Die Positionen sind zu erkennen; die Hoffnung: ausreichend gute Extraktion. Ergebnis:

Für eine Rechnung werden zwei Positionen extrahiert. Abgleich mit dem Dokument: „eine Position, zwei Positionen“. Die Summen passen – „Validation successful“.
Bei der Bildrechnung ist die Extraktion spärlicher, es fehlen u. a. Einzelpreise. Folge: Validierungsfehler, die im UI sichtbar sind. Die Werte lassen sich manuell ergänzen; danach kann freigegeben werden.

Abschließend zeigt Sandberger, wie die freigegebenen Daten „an die MIC-Module übertragen“ und im nächsten Schritt „an den Zoll deklariert“ werden.

Architekturentscheidungen und technische Implikationen

Die Session war bewusst praxisnah. Einige Entscheidungen stechen aus Engineering-Sicht hervor:

Provider-Agnostik als Produktfeature

Kund:innen bringen oft bestehende AI-Verträge mit. Die Vision API abstrahiert Anbieterunterschiede und erlaubt es, OpenAI, Dropic oder auch Mistral einzubinden. So kann MIC je nach Kundenvorgaben oder Modellgüte unterschiedliche Backends nutzen. Das ist gerade in Enterprise-Setups mit Compliance- und Vertragsbindung relevant.

Self-Hosting: Möglich, aber kostspielig

MIC kann offene Modelle wie „Alibaba crane model“ und „Meta Llama“ selbst hosten. Praxisfazit: GPU-Knoten sind teuer; externe Provider sind oft „kosteneffektiver und performanter“. Diese nüchterne Kosten-Nutzen-Abwägung hilft beim Sizing von Betriebsmodellen.

Schema-First und Validierungen: Robustheit schlägt Generativitätsfreiheit

Das Festlegen von Zielstrukturen (z. B. Rechnungsschema) und die Ausgabe als valides JSON schaffen eine deterministische Grundlage – im Gegensatz zu freiem Text. Ergänzt durch Validierungen (Summen, Pflichtfelder) entsteht ein belastbares Verarbeitungssystem, das Domainfehler früh abfängt und im UI adressierbar macht.

Chunking und Streaming: Praktikable Antwort auf Kontext- und Output-Limits

Kontextfenster und Response-Limits sind harte Randbedingungen. Der Workaround ist architektonisch: Splitting großer Dokumente, iterative Extraktion, Zusammenführen in der UI/Backend-Logik. Die Session zeigt damit eine praxistaugliche Blaupause für großvolumige Belege (mehrseitige PDFs, umfangreiche Excels).

Human-in-the-Loop: Von Assisted zu Automated

Der Weg zur vollautomatischen Verarbeitung führt über manuelle Review: Erst wenn Validierungsregeln zuverlässig greifen und typische Fehlerfälle im UI adressiert sind, lohnt sich die Dunkelverarbeitung (z. B. „wenn die Summen passen“). Der iterative Übergang reduziert Betriebsrisiken und beschleunigt Akzeptanz bei Fachanwender:innen.

Praktische Leitlinien für Engineering-Teams

Basierend auf der Session lassen sich mehrere übertragbare Leitlinien formulieren – ohne Spekulation, strikt entlang der Inhalte:

Definiert klare Zielschema pro Dokumenttyp. Je präziser die Struktur (inkl. Positionen, Beträge, Metadaten), desto stabiler die Ausgabe.
Plant OCR als Pflichtschritt ein. Scans ohne Textlayer sind häufig; ohne OCR ist die Extraktion blockiert.
Entkoppelt die Modellauswahl. Eine API-Schicht, die unterschiedliche Provider einbindet, unterstützt Kundenanforderungen und Technologiewechsel.
Beachtet Kontext- und Ausgabelimits. Implementiert Splitting/Chunking und ein Verfahren zum Zusammenführen der Ergebnisse.
Etabliert Validierungsregeln nahe am Geschäftsziel. Summenchecks und Pflichtfield-Validierungen sorgen für Qualität und bieten klare Signale für Automatisierungsfreigaben.
Bietet Review-UI und einfache Korrekturpfade. Sichtbare Fehler (z. B. fehlender Einzelpreis in einer Bildrechnung) müssen schnell behebbar sein.
Startet bewusst mit Human-in-the-Loop. Mit wachsendem Vertrauen lassen sich Automatisierungsregeln sukzessive aktivieren.

Status und Ausblick innerhalb des Gezeigten

Sandberger schildert, dass die Produktivsetzung beim ersten zahlenden Kunden „letzte Woche“ erfolgt ist und MIC daran arbeitet, die Lösung „in alle Produkte zu integrieren“. Der Use Case ist generisch für viele Kund:innen: Dokumente erfassen, strukturieren, validieren, an Zoll- und Compliance-Module übergeben. Genau hier liefert die Kombination aus Vision API, Structured Output und DocFlow einen kohärenten End-to-End-Prozess.

Fazit: Ein belastbarer Bauplan für KI in dokumentlastigen Prozessen

„AI-based document processing“ mit Maximilian Sandberger (MIC) zeigt, wie sich generative Modelle in produktionsreife Datenpipelines integrieren lassen – ohne Magie, dafür mit konsequenter Architektur:

Schema-first statt Freiformtext
OCR und Typklassifikation als Pflichtschritte
Chunking/Streaming gegen Kontext- und Outputgrenzen
Provider-Agnostik für Enterprise-Flexibilität
UI-gestützte Validierung als Basis für spätere Dunkelverarbeitung

Besonders prägnant ist der Fokus auf „strukturierte Ausgaben“: Die Möglichkeit, Modelle zu validem JSON zu veranlassen, macht den Unterschied zwischen einer hübschen Demo und einer anschlussfähigen Enterprise-Lösung. Gepaart mit einer UI wie DocFlow und der Vision API entsteht ein Workflow, der sowohl von der operativen Seite (Fachanwender:innen) als auch von der technischen Seite (APIs/Module) getragen wird.

Für Teams, die mit ähnlichen Herausforderungen ringen – PDFs, E‑Mails, Scans, Excel – liefert die Session einen kompakten Leitfaden: Baue die Pipeline vom Ende her (Zielschema, Validierung, Übergabe), integriere OCR und Klassifikation früh, kapsle die Modellebene, und nutze Human-in-the-Loop als Stabilisator, bevor du die Automatisierung hochfährst. Genau so wird aus KI ein produktives Werkzeug im Tagesgeschäft von Trade-Compliance und Zollprozessen.

Weitere Tech Talks

Weitere Tech Lead Stories