Bestellmails auslesen: lokale KI mit Ollama vs. Python-Parser

Jeder Lieferant schickt zu jeder Bestellung eine Auftragsbestätigung per E-Mail – mit allen Positionen, Mengen und Preisen. Diese Mail kommt ohnehin jeden Tag ins Haus. Die Frage ist nur: Wie holt man die Daten da automatisch und zuverlässig heraus, um sie ins ERP zu übernehmen?

In diesem Artikel zeige ich die zwei Wege, die wir dafür gebaut und gegeneinander getestet haben: eine lokale KI auf Basis von Ollama und einen regelbasierten Parser in Python. Beide lösen dasselbe Problem, gehen es aber völlig unterschiedlich an.

Das Problem: gleiche Daten, fünf verschiedene Mails

Wir haben mit fünf typischen Lieferanten gearbeitet: Phoenix Contact, Rexel, Würth, ABB und Siemens. Inhaltlich steht in jeder Mail dasselbe – Artikelnummer, Menge, Einzelpreis, Gesamtpreis, oft auch GTIN/EAN. Nur sieht jede Mail komplett anders aus:

• Phoenix als gut lesbarer Text mit Staffelpreisen („327,42 € für 100 Stück")
• Würth als HTML-Tabelle mit Verpackungseinheiten (Menge × VE = echte Stückzahl)
• Rexel mit Hersteller- und Rexel-Artikelnummer plus Metallzuschlägen
• ABB mit den eigentlichen Positionen im PDF-Anhang, davor zwei Seiten AGB
• Siemens mit zwei Preisspalten (Listenpreis und „Ihr Preis")

Diese Vielfalt ist der eigentliche Knackpunkt. Eine einzelne Mail auszulesen ist leicht. Fünf grundverschiedene zuverlässig auszulesen, jeden Tag, ohne dass jemand kontrolliert, ist die Kunst. Dafür haben wir zwei Ansätze gebaut.

Weg 1: Lokale KI mit Ollama

Die Idee hat etwas Bestechendes. Ein Sprachmodell liest die Mail wie ein Mensch und gibt die Daten strukturiert als JSON zurück, egal wie die Mail aufgebaut ist. Man muss kein Muster pro Lieferant hinterlegen.

Damit das DSGVO-konform bleibt, läuft das Modell vollständig lokal auf dem Server des Kunden. Es verlassen keine Bestelldaten das Haus. Die Bausteine dafür:

• Ollama – eine schlanke Laufzeitumgebung, die lokale Sprachmodelle bereitstellt und über eine einfache Schnittstelle ansprechbar macht. Quasi der „Motor", der das Modell betreibt.
• Das Sprachmodell – in unseren Tests Qwen 2.5 (ein quelloffenes Modell), in zwei Größen: die kleinere 7B-Variante und die größere, präzisere 14B-Variante.
• Strukturierte Ausgabe per JSON-Schema – wir geben dem Modell ein festes Zielschema vor (Positionen mit Artikelnummer, Menge, Preis …). Das erzwingt eine maschinell verwertbare Antwort statt Fließtext.

Der große Vorteil: Flexibilität. Die KI braucht kein festes Muster und kommt auch mit einer Mail klar, die sie noch nie gesehen hat.

Drei Dinge, die wir in der Praxis gelernt haben – und die man wissen sollte, bevor man sich auf reine KI verlässt:

Die Modellgröße muss zum Server passen. Das 14B-Modell (rund 9 GB) wurde auf einer Maschine mit knappem Arbeitsspeicher schlicht vom System beendet – Absturz mitten im Lauf. Das 7B-Modell lief stabil. Lektion: Bei lokaler KI ist der Arbeitsspeicher der Engpass, nicht die Modellqualität. Ein brauchbares Modell braucht einen entsprechend dimensionierten Server.

Die KI ist gut bei Summen, schwächer bei Detailfeldern. Die Gesamtsummen stimmten in unseren Tests durchweg. Bei einzelnen Feldern – etwa der Preiseinheit „pro 100 Stück" – ließ das kleinere Modell aber immer wieder Werte aus.

Bei PDFs muss der relevante Teil ins Sichtfeld. Ein Sprachmodell sieht immer nur einen begrenzten Textausschnitt. Beim ABB-PDF standen die Positionen erst hinter zwei Seiten AGB, also außerhalb dieses Fensters. Ich saß davor und dachte zuerst: super, alles erkannt, saubere Artikelliste. Bis ich gemerkt habe, dass keine einzige dieser Artikelnummern im PDF vorkam. Das Modell hatte die Lücke einfach mit plausibel klingenden, frei erfundenen Positionen gefüllt. Erst als wir das Sichtfeld vergrößert haben, las es die echten Daten.

Lokale KI ist also ein starkes Werkzeug. Aber sie braucht passende Hardware, etwas Feinjustierung und vor allem jemanden, der nachprüft.

Weg 2: Regelbasierter Parser in Python

Der zweite Weg geht das Problem von der anderen Seite an. Statt die Mail „verstehen" zu lassen, beschreiben wir pro Lieferant einmal präzise, wo welche Information steht. Ein Python-Programm liest sie dann exakt nach diesen Regeln aus.

Entscheidend ist, wo diese Regeln liegen: Die lieferantenspezifische Logik steckt nicht im Programmcode, sondern in einer schlanken Konfiguration pro Lieferant. Dort ist hinterlegt, woran man den Lieferanten erkennt, wo die Bestellnummer steht, wie die Positionstabelle aufgebaut ist und welche Besonderheiten gelten. Bei Würth zum Beispiel ist die echte Stückzahl Menge × Verpackungseinheit, bei Siemens wird der Listenpreis ignoriert und stattdessen „Ihr Preis" genommen.

Die Vorteile in der Praxis:

• Exakt und vollständig. Was in der Mail steht, wird zu 100 % korrekt übernommen – inklusive GTIN, Preiseinheit und echter Stückzahl.
• Reproduzierbar. Dieselbe Mail führt immer zum exakt gleichen Ergebnis. Keine Überraschungen, keine Halluzinationen.
• Eingebaute Plausibilitätsprüfung. Das Programm rechnet jede Position nach (Einzelpreis × Menge = Gesamtpreis) und vergleicht die Summe mit der vom Lieferanten ausgewiesenen Nettosumme. Stimmt etwas nicht, fällt es sofort auf.
• Schlank und schnell. Keine GPU, kein großes Modell, kein hoher Speicherbedarf. Läuft auf nahezu jedem Server.
• Nachvollziehbar. Jeder Lauf erzeugt eine Ergebnis- und Protokolldatei – jede verarbeitete Bestellung ist dokumentiert.

Einen Nachteil hat der Weg, und den will ich nicht verschweigen: Ändert ein Lieferant das Layout seiner Mail grundlegend, muss die Konfiguration für diesen Lieferanten angepasst werden. Verbucht wird dann aber nie etwas Falsches. Die Mail landet in einer Fehlerliste statt im ERP, und wir passen die Regel nach.

Neuer Lieferant? Konfiguration erweitern, fertig

Ein Punkt, der den regelbasierten Weg im Alltag so praktisch macht: Kommt ein neuer Lieferant hinzu, wird einfach eine neue Konfiguration ergänzt – ohne Eingriff in die Programmlogik. Das System wächst mit, Lieferant für Lieferant. Gestartet wird mit dem häufigsten Lieferanten als Pilot, der Rest folgt schrittweise.

Beide Wege schließen sich nicht aus

In der Praxis muss man sich gar nicht entscheiden. Der regelbasierte Parser bildet den verlässlichen Kern. Die lokale KI kann als Auffangnetz danebenstehen, für Formate, die noch keine Regel haben, oder wenn ein Lieferant seine Mail umbaut. Beides läuft beim Kunden im Haus, beides DSGVO-konform.

Welcher der beiden Wege sich am Ende im direkten Vergleich durchgesetzt hat, und warum das Ergebnis deutlicher ausfiel als gedacht, darum geht es im zweiten Teil.

Wiederkehrende E-Mails automatisch ins ERP?

Sie möchten Bestellungen, Rechnungen oder andere wiederkehrende E-Mails automatisch in Ihr ERP übernehmen? Sprechen Sie uns an – wir schauen uns Ihre Lieferantenmails an und sagen Ihnen ehrlich, was sich automatisieren lässt.

Erstgespräch unverbindlich vereinbaren – wir melden uns innerhalb eines Arbeitstages.