Ein Lieferantenverzeichnis aus Rechnungsfotos: 3 579 Positionen, 184 Zeilen

Ein Lieferantenverzeichnis gab es in diesem Betrieb nicht, und die einzige verfügbare Quelle waren fotografierte Papierrechnungen: Ein Lebensmittelhersteller mit eigenem Filialnetz führt seinen Betrieb über unser Panel nach Zahlen, und im Bereich „Lieferanten“ der Filialen stand nichts. Wie aus fotografierten Papierrechnungen ein belegbares Verzeichnis wurde, steht hier.

Das Lieferantenverzeichnis begann mit einem leeren Bereich

Ein leerer Bereich ist schlimmer als eine unvollständige Liste. Der Inhaber konnte nicht erkennen, ob die Arbeit noch aussteht oder ob sie jemand vergessen hat. Beides ist unangenehm; das Zweite kostet Vertrauen in das ganze System, denn ein Panel, dem man an einer Stelle nicht glaubt, wird auch an den anderen geprüft.

Für die Fabrik desselben Unternehmens gab es eine gepflegte Lieferantentabelle, die sich importieren ließ. Für das Filialnetz gab es sie nicht: keine Tabelle, keine Exportdatei aus einer Warenwirtschaft, keine Liste in einer Mail. Die Frage „Woher kommt das Verzeichnis?“ hatte zunächst keine Antwort – und genau deshalb blieb der Bereich leer.

Die klassische Lösung wäre, jemanden tagelang Rechnungen abtippen zu lassen. Diese Tabelle wäre am Tag ihrer Fertigstellung veraltet, und niemand könnte eine Zeile zu ihrem Ursprung zurückverfolgen.

Die einzige Quelle: fotografierte Papierrechnungen

Was es gab: Papierrechnungen der Lieferanten, die in den Filialen fotografiert werden und die ein bestehender Prozess nachts ausliest. Ein Vision-Modell erkennt Lieferant, Rechnungsnummer, Datum und die einzelnen Positionen mit Preis; wie diese Erkennung von Belegen technisch funktioniert, steht im Lexikon. In der Datenbank lagen dadurch bereits 3 579 Rechnungspositionen, ursprünglich für die Einkaufsauswertung erfasst.

Die Entscheidung war deshalb einfach: Das Lieferantenverzeichnis wird nicht gepflegt, sondern abgeleitet – aus dem, was real existiert. Jede Zeile muss auf eine konkrete Rechnung zeigen, und die Rechnung muss als Foto aufrufbar sein. Kein Datensatz ohne Beleg.

Eine Zeile = Firma × Artikel × letzter Preis

Die Ableitung selbst ist eine Abfrage in PostgreSQL und etwas TypeScript im Backend – keine neue Datenhaltung. Eine Zeile im Verzeichnis ist eine Kombination aus Lieferant und Artikel, dazu der zuletzt gezahlte Preis. Darunter steht „aus Rechnung Nr. … vom …“, ein Klick öffnet das Foto. Wer eine Zahl anzweifelt, sieht sofort das Original.

Zwei Regeln haben wir bewusst festgelegt:

• Nichts wird gelöscht. Zeilen, die nicht ins Verzeichnis gehören – etwa Speditionen, die keine Ware liefern –, bleiben vorhanden und nennen den Grund, warum sie ausgeblendet sind.
• Alles ist von Hand korrigierbar. Die Ableitung liefert einen Vorschlag; das letzte Wort hat der Mensch.

Am Ende standen aus 3 579 Rechnungspositionen 184 Zeilen bei 24 Lieferanten, und 100 % der Zeilen zeigen ihren Quellbeleg. Die Aktualisierung hängt am bestehenden nächtlichen Rechnungslauf: Neue Rechnung fotografiert, nachts erkannt, morgens im Verzeichnis. Es gibt keinen zweiten Prozess, den jemand pflegen müsste.

Warum wir auf Fuzzy-Matching verzichtet haben

Der schwierige Teil war nicht die Erkennung, sondern die Firmennamen. Ein Lieferant taucht auf Rechnungen in mehreren Schreibweisen auf: mit und ohne Rechtsform, mit Lesefehlern, mal mit Ort, mal ohne. Die naheliegende Lösung – Namen per Ähnlichkeitsmaß zusammenführen – haben wir verworfen. Ähnlichkeitsmaße führen früher oder später zwei verschiedene Lieferanten zusammen, und diesen Fehler sieht niemand, bis ein Preisvergleich Unsinn ergibt.

Stattdessen laufen die Namen über denselben Normalisierer, den auch die Einkaufsansicht im Panel nutzt: feste Regeln, dazu ein gepflegtes Wörterbuch für die Schreibvarianten aus der Erkennung. Das Wörterbuch wächst, wenn ein Mensch einen neuen Fall bestätigt. Das ist langsamer als ein Algorithmus, aber jede Zusammenführung ist erklärbar – und Einkaufsansicht und Verzeichnis widersprechen sich nie, weil beide dieselbe Logik verwenden.

Was ein Lieferantenverzeichnis nicht löst

Ein Teil der Zeilen trägt den Hinweis „Kategorie geschätzt“: Dort war die Warengruppe aus der Rechnung nicht eindeutig abzuleiten. Wir schreiben das lieber hin, als falsche Sicherheit zu erzeugen – aber es ist eine Einschränkung, und der Kunde kennt sie. Eine Erkennung liest, was auf dem Papier steht; sie weiß nicht, in welche Warengruppe ein Artikel im Kopf des Einkäufers gehört. Diese Zuordnung bleibt Handarbeit, bis genug bestätigte Fälle vorliegen.

Das Muster selbst ist nicht an Lebensmittel gebunden. Es passt überall dort, wo ein Stammdatenverzeichnis fehlt, aber Belege existieren: Lieferanten aus Rechnungen, Artikel aus Lieferscheinen, Kunden aus Auftragsbestätigungen. Drei Regeln nehmen wir aus dem Projekt mit:

1. Ableiten statt pflegen. Ein Verzeichnis, das aus Belegen entsteht, ist nie leer und nie veraltet.
2. Jede Zeile zeigt ihren Beleg. Das ist der Unterschied zwischen einer Zahl, der man glaubt, und einer, die man prüft.
3. Zusammenführen nur nach erklärbaren Regeln. Ein falsch verschmolzener Lieferant kostet mehr Vertrauen als zehn Zeilen, die noch von Hand zu bestätigen sind.

Wie wir solche Ableitungen in bestehende Systeme einbauen, beschreiben wir unter Prozessautomatisierung für Produktion und Handel.