Positionen aus Lieferantenrechnungen stapelweise
in eine Tabelle extrahieren

Warum eine Lebensmittelhändler-Rechnung komplexer ist als eine Standard-Rechnung

Eine Standard-Rechnung für Bürobedarf ist unkompliziert: Lieferantenname oben, Rechnungsnummer, Datum und eine kurze Tabelle mit Positionen – Beschreibung, Menge, Einzelpreis, Gesamtbetrag. Das gesamte Dokument passt auf eine Seite. Die Felder sind einheitlich beschriftet. Die Extraktion löst ein reines Layout-Problem.

Eine Lebensmittelhändler-Rechnung löst gleich fünf Probleme auf einmal. Erstens die Länge: Eine Sysco-Rechnung umfasst oft 4 bis 5 Seiten mit 40 bis 60 Positionen, verteilt auf durchgehende Tabellen, die häufig mitten in einer Kategorie über Seitengrenzen hinweg brechen. Eine einzelne Bestellung für ein vielbesuchtes Restaurant kann Obst, Milchprodukte, Eiweiß, Trockenwaren, Papierartikel und Reinigungschemikalien umfassen – jede Kategorie in einem eigenen Abschnitt auf derselben Rechnung, manchmal mit Zwischensummen auf Abschnittsebene, die wie Positionen aussehen, aber keine sind.

Zweitens die variable Packungsgröße: Dieselbe Zutat erscheint bei verschiedenen Lieferanten in unterschiedlichen Einheiten. Hähnchenbrust von Sysco wird in einer 40-Pfund-Kiste verkauft. Das gleiche Produkt von US Foods gibt es in einer 50-Pfund-Kiste. Der lokale Geflügelhändler verkauft direkt pro Pfund. Die Extraktion der Positionen muss die Packungsgröße und Maßeinheit für jede Zeile erfassen – nicht nur den Rechnungspreis – denn Preisvergleiche zwischen Lieferanten erfordern eine Normierung auf eine gemeinsame Einheit. Eine Extraktion auf Kopfebene, die nur den Rechnungsendbetrag erfasst, ist für jede nachgelagerte Kostenanalyse nutzlos.

Drittens: Ist-Gewicht – Proteine (Rind, Hähnchen, Fisch) werden oft nach tatsächlichem Gewicht abgerechnet, nicht nach Bestellmenge. Die Rechnung zeigt „Bestellt: 40 lbs“ und „Erhalten: 38,7 lbs“ in derselben Zeile, und der Rechnungsbetrag wird auf Basis des Ist-Gewichts berechnet. Ein Tool, das blind die erste Zahl neben einem Gewichtsfeld ausliest, extrahiert die falsche Preisgrundlage. Die Extraktion muss erkennen, welches Gewichtsfeld preisrelevant ist, und genau dieses auslesen – nicht das andere.

Viertens: handschriftliche Korrekturen – Bei Lebensmittellieferungen gibt es oft Ersatzprodukte. Der Fahrer streicht „80/20 Rinderhack – 2 Kartons“ durch und schreibt „Ersetzt durch 85/15 – gleicher Preis.“ Oder eine Gemüseposten ist knapp: „Roma-Tomaten – bestellt 25 lbs, fehlen 5 lbs.“ Diese Notizen sind handschriftlich direkt auf der gedruckten Rechnung vermerkt. Herkömmliche OCR behandelt Druck- und Handschrift als zusammenhanglose Brocken; sie kann „ersetzt“ nicht mit dem darüberstehenden Posten verknüpfen. Ein Vision-Modell, das sinngemäß liest, erkennt, dass die Handschrift zum benachbarten Posten gehört, und passt die Extraktion entsprechend an.

Fünftens: Lieferanten-Mix – Die drei Rechnungen vom Dienstag haben kein einheitliches Format. Sysco verwendet ein Layout, US Foods ein anderes. Der handgeschriebene Zettel des Gemüselieferanten passt zu keinem von beiden. Ein vorlagenbasiertes Extraktionstool benötigt drei separate Konfigurationen – und die handschriftliche Notiz bekommt gar keine, weil sich für freie Handschrift keine Vorlagen erstellen lassen. Das ganze Versprechen der Stapelverarbeitung bricht zusammen, wenn man jeden Lieferanten einzeln konfigurieren muss.

Was Sie tatsächlich extrahieren — Kopfdaten vs. Einzelposten

Die Rechnungsextraktion unterteilt sich in zwei Ebenen. Kopfdaten beantworten „Wer hat dies wann gesendet?": Lieferantenname, Rechnungsnummer, Rechnungsdatum, Fälligkeitsdatum, Bestellnummer und Rechnungssumme. Bei Lebensmittelhändler-Rechnungen bringt die reine Kopfdaten-Extraktion fast nichts — Sie wissen, wie viel Sie diese Woche bei Sysco ausgegeben haben, aber nicht wofür.

Die Einzelposten-Extraktion beantwortet „Was habe ich gekauft und wie viel hat jedes gekostet". Jede Zeile in der Ausgabe repräsentiert eine Position aus der Rechnung mit Spalten für:

Bei einer Sysco-Rechnung mit 52 Positionen sind das 52 Ausgabezeilen × ~15 Spalten = 780 einzelne extrahierte Werte – aus einer einzigen Rechnung. Über drei Lieferanten hinweg erzeugt ein einziger Liefertag rund 1.500 extrahierte Datenpunkte. Bei manueller Eingabe mit 5 Sekunden pro Wert würde das über zwei Stunden dauern. Die unten beschriebene Extraktion erledigt dies in Sekunden, wobei die Überprüfung Minuten statt Stunden in Anspruch nimmt.

Die fett markierten Felder – Erhaltene Menge, Einwaage, Preisbasis, Substitutionshinweis – sind diejenigen, die die Extraktion von Lebensmittelhändler-Rechnungen von der generischen Rechnungsextraktion unterscheiden. Genau hier scheitern die meisten Tools stillschweigend: Sie extrahieren die Bestellmenge, weil sie die erste Zahl ist, die sie sehen, aber der Rechnungspreis wurde auf Basis der erhaltenen Menge berechnet, und die Abweichung bleibt bis zum Monatsende-Inventarabgleich unentdeckt.

Der schrittweise Extraktions-Workflow

Der folgende Workflow verwendet die Spaltennamen-Extraktion: Statt Formularfelder auf dem Layout jeder Lieferantenrechnung zu markieren, geben Sie die gewünschten Spaltennamen ein, und die KI findet die passenden Daten auf jeder Seite, indem sie versteht, was die Informationen bedeuten – nicht, wo sie stehen. Eine Spaltendefinition funktioniert für Syscos PDF, US Foods' PDF und die handschriftliche Notiz des lokalen Lieferanten, ohne Konfiguration pro Lieferant.

Schritt 1 – Definieren Sie die Spaltennamen einmal. Diese werden als Vorlage gespeichert und für jede Liefercharge wiederverwendet:

Schritt 2 — Alle Rechnungen auf einmal hochladen. Ziehen Sie das Sysco-PDF (5 Seiten), das US-Foods-PDF (3 Seiten) und ein Handyfoto des handschriftlichen Produktvermerks in einen einzigen Batch-Upload. Keine Lieferantenkonfiguration. Kein Vorlagenbau. Die KI liest alle drei gleichzeitig und ordnet dabei jeden Lieferantennamen seiner Rechnung zu.

Schritt 3 — Ergebnis prüfen, nicht abschreiben. Das Ergebnis ist eine einzige Excel-Datei, in der jede Zeile einen Einzelposten darstellt, jede Spalte den von Ihnen definierten Feldnamen entspricht und die Spalte „Lieferantenname“ angibt, von welcher Rechnung jede Zeile stammt. Der Prüfschritt – das Durchsehen der Tabelle auf markierte oder unsichere Werte – dauert pro Lieferung Minuten statt der Stunden manueller Eingabe, die er ersetzt:

Beachten Sie die Unterschiede, die die KI automatisch auflöst. Sysco codiert Hähnchenbrust als „472819“ mit einer 12-stelligen Abkürzung. US Foods codiert sie als „CHK-BR-6“ mit einer längeren Beschreibung. Die Artikelnamen sehen unterschiedlich aus – aber beide werden derselben Kategorie (Protein) zugeordnet und können in einer Pivot-Tabelle verglichen werden. Der Atlantische Lachs von US Foods hat ein Fanggewicht: 15 lbs bestellt, 14,3 lbs erhalten, abgerechnet nach tatsächlichem Gewicht. Bei den lokalen Roma-Tomaten fehlen 2 lbs, und der Substitutionsvermerk hält dies fest. Die Extraktion erfasst all diese Sonderfälle in einem einzigen Durchlauf über drei verschiedene Rechnungsformate.

Die Sonderfälle, die vorlagenbasierte Extraktion scheitern lassen – und wie KI sie bewältigt

Rechnungen von Lebensmittelhändlern haben Fehlerbilder, die bei Standardrechnungen nicht vorkommen. Ihr Verständnis erklärt, warum vorlagenbasierte Tools ständige Wartung erfordern – und warum ein semantischer Extraktionsansatz dies nicht tut.

Manuelle Positionsanpassungen. Ein Fahrer notiert handschriftlich „85/15 gegen 80/20 getauscht – gleicher Preis“ neben der Rinderhackfleisch-Position. Für ein Vorlagentool ist das Rauschen – die OCR erfasst zwar die Zeichen, aber die Vorlage erwartet einen bestimmten Wert in der Zelle „Positionssumme“ und kann mit Freitext daneben nichts anfangen. Ein semantisch lesendes Vision-Modell erkennt, dass der handschriftliche Text kontextuell zur benachbarten Position gehört, und extrahiert ihn in die Spalte „Substitutionsvermerk“. Die ursprüngliche Bestellung – 80/20 Rinderhack – bleibt erhalten. Die Tatsache, dass substituiert wurde, wird erfasst. Die Küche weiß, was tatsächlich geliefert wurde.

Catch-Weight-Preisgestaltung. Wenn Lachs, Steak oder Käse nach tatsächlichem Gewicht abgerechnet werden, zeigt die Rechnung zwei Gewichtsspalten für dieselbe Position: bestellt und erhalten. Der Rechnungsendbetrag basiert auf dem erhaltenen Gewicht. Ein Tool, das beide Zahlen extrahiert, aber nicht erkennt, welche den Preis bestimmt, erzeugt einen Abstimmungsfehler, der bei der Inventur auffällt. KI-Extraktion mit klarer Spaltenbenennung – „Bestellte Menge“ und „Erhaltene Menge“ als separate Spalten, plus ein Flag „Catch Weight (J/N)“ – bewahrt beide Werte und macht die Preisbasis explizit.

Seitenumbrüche inmitten einer Tabelle. Die Positionstabelle einer Sysco-Rechnung erstreckt sich über die Seiten 2 und 3, wobei der Seitenumbruch zwischen den Positionen 28 und 29 liegt. Die Spaltenüberschriften wiederholen sich auf Seite 3 nicht. Eine Vorlage, die den Tabellenbeginn an einer festen Position auf Seite 1 erwartet, verliert nach dem Seitenumbruch jede Position aus dem Blick. KI-Extraktion, die nach Artikelbeschreibungen und zugehörigen Zahlenwerten sucht, ignoriert Seitengrenzen – sie liest das Dokument als kontinuierlichen Datenstrom weiter.

Gemischte Maßeinheiten. Dieselbe Rechnung kann Produkte im Karton (25 lb Roma-Tomaten), Milchprodukte in Gallonen (Vollmilch), Proteine in Pfund (Lachs) und Trockenwaren einzeln (50-lb-Sack Mehl) auflisten. Die Spalte für die Einheit ändert ihre Bedeutung mit jeder Zeile. Vorlagenbasierte Extraktion geht oft von einer einzigen Maßeinheit pro Rechnung aus und ordnet Werte falsch zu. KI-Extraktion, die das Einheitenfeld jeder Zeile unabhängig liest, verarbeitet die Mischung korrekt, da sie jede Zeile als eigenen Extraktionskontext behandelt.

Von extrahierten Positionen zu nutzbaren Tabellen

Das Extrahieren der Positionen ist Schritt eins eines wöchentlichen Betriebsrhythmus. Was danach passiert, macht aus Daten Entscheidungen.

Rezeptkosten aktualisieren. Jede extrahierte Position enthält einen Stückpreis. Für Restaurants, die die Gerichtskosten verfolgen, ist dies die Eingabe für eine Berechnung des Lebensmittelkostenanteils. Wenn die Sysco-Rechnung Hähnchenbrust zu 2,82 $/lb zeigt, US Foods sie aber zu 2,70 $/lb anbietet, fließt der Preis des günstigeren Lieferanten in die Rezeptkosten für das Hähnchengericht ein – und die Gerichtskosten sinken um die Differenz multipliziert mit der Portionsgröße. Durch die wöchentliche Extraktion sind die Rezeptkosten immer aktuell und basieren nicht auf einem Preis, der vor drei Monaten bei der letzten Menüaktualisierung eingegeben wurde.

Preisverlauf für jede Zutat aufbauen. Das Speichern der wöchentlichen Extraktionsergebnisse – mit konsistenter Spaltenstruktur – erstellt einen durchsuchbaren Datensatz jedes Zutatenpreises von jedem Lieferanten, Woche für Woche. Exportieren Sie die Hähnchenbrust-Zeilen über 12 Wochen, zeichnen Sie den Stückpreis auf, und Sie haben eine visuelle Preisentwicklung. Die Grafik zeigt Ihnen, ob die Behauptung des Sysco-Vertreters, „die Preise seien stabil gewesen", mit den Daten übereinstimmt.

Bestandsabgleich der Lieferungen. Die Spalte „Erhaltene Menge“, summiert über alle Kategorien, ist die Grundlage für den wöchentlichen Bestand. Wenn die Extraktion ergibt, dass diese Woche 80 Pfund Hähnchenbrust von allen Lieferanten eingegangen sind und der Kühlraum noch 55 Pfund ausweist, ergibt sich daraus der tatsächliche Verbrauch der Woche – und die Basis für die Berechnung der tatsächlichen im Vergleich zu den theoretischen Lebensmittelkosten. Manuelle Dateneingabe führt zu Übertragungsfehlern, die diesen Abgleich unzuverlässig machen. Extrahierte Daten eliminieren die Variable der Übertragungsfehler.

Unterstützung bei Lieferantenverhandlungen. Wenn ein Lieferant eine Preiserhöhung vorschlägt, liefert die Extraktionshistorie objektive Daten. „Ihr Hähnchenbrustpreis ist in den letzten sechs Wochen von 2,70 $ auf 2,95 $ gestiegen – ein Anstieg von 9,2 %. Der Rohstoffindex für entbeinte Brust ist im gleichen Zeitraum um 3,1 % gestiegen. Können Sie die Differenz erklären?“ Das Gespräch verlagert sich von Meinungen zu Beweisen, und der Lieferant weiß, dass es eine nachvollziehbare Dokumentation gibt.

Für einen praktischen Einstieg in die Rechnungsdatenextraktion ohne Template-Konfiguration probieren Sie unser KI-Tool zur Rechnungsdatenextraktion – es verarbeitet Lebensmittelrechnungen mehrerer Lieferanten, handschriftliche Notizen und Catch-Weight-Preise in einem Durchgang.

FAQ

Kann das Tool mehrseitige Rechnungen verarbeiten, bei denen sich die Tabelle über mehrere Seiten erstreckt?

Ja. Die KI liest das gesamte Dokument als kontinuierlichen Informationsstrom – sie behandelt jede Seite nicht als separates Dokument und erwartet keine auf eine Seite beschränkten Tabellen. Wenn die Positionsliste einer Sysco-Rechnung über die Seiten 2 und 3 verteilt ist (ohne Wiederholung der Spaltenüberschriften auf Seite 3), setzt die KI die Extraktion nahtlos an der Stelle fort, an der die Tabelle endet. Sie müssen Seiten nicht separat hochladen oder Seitenbereiche konfigurieren. Laden Sie alle Seiten aller Rechnungen gemeinsam hoch, und die Extraktion erzeugt eine einzige Ausgabedatei mit allen Positionen aller Seiten.

Versteht die KI unterschiedliche Packungsgrößen und Einheitenumrechnungen?

Die KI extrahiert Packungsgröße und Einheit exakt wie auf der Rechnung gedruckt – sie rechnet Einheiten nicht automatisch um (z. B. Pfund in Kilogramm). Sie erfasst jedoch beide Werte, sodass Sie sie in der Tabelle normalisieren können: "Packungsgröße: 40" und "Einheit: lb" werden in eigenen Spalten extrahiert und liefern die Rohdaten für jede nachgelagerte Umrechnung oder Stückkostenberechnung. Für Teams, die die Umrechnung während der Extraktion wünschen, kann eine berechnete Spalte definiert werden – z. B. "Stückkosten (Gesamtpreis ÷ erhaltene Menge, zwei Dezimalstellen)" – und die KI führt die Berechnung vor der Ausgabe durch, sodass jede Position unabhängig von der Packungsgröße bereits einen normalisierten Preis pro Einheit hat.

Was ist, wenn der Fahrer Ersatznotizen direkt auf die gedruckte Rechnung schreibt?

Handschriftliche Notizen auf gedruckten Rechnungen – Ersatzlieferungen, Fehlmengen, Preisänderungen, die vom Fahrer notiert wurden – werden von der KI erfasst und in der Ausgabe festgehalten. Wenn z. B. bei „80/20 Rinderhack – 2 Kisten“ handschriftlich „ersetzt durch 85/15 – gleicher Preis“ vermerkt ist, wird der ursprüngliche Artikel (80/20 Rinderhack) weiterhin als Artikelbeschreibung extrahiert, und der Ersatzvermerk erscheint in der dafür vorgesehenen Spalte. Diese Fähigkeit unterscheidet die Extraktion per Vision-Modell von herkömmlicher OCR, die gedruckten und handschriftlichen Text unabhängig voneinander liest und nicht kontextuell verknüpfen kann. Die praktische Einschränkung: Die Handschrift muss einigermaßen lesbar sein, und das Foto muss die Notiz deutlich zeigen. Ein bei gutem Licht, frontal und von einer flachen Rechnung aufgenommenes Foto liefert zuverlässige Ergebnisse. Ein dunkles, schräg aufgenommenes Foto einer gefalteten Rechnung führt bei handschriftlichen Teilen zu geringerer Genauigkeit.

Worin unterscheidet sich das von einer AP-Automatisierungsplattform wie Restaurant365 oder xtraCHEF?

AP-Automatisierungsplattformen bieten vollständige Kreditoren-Workflows – sie erfassen Rechnungen, buchen Positionen auf Sachkonten, leiten Genehmigungen weiter und integrieren sich in Buchhaltungssysteme. Für Restaurantgruppen mit mehreren Standorten, die monatlich hunderte Rechnungen verarbeiten, rechtfertigen die Integrationstiefe und die Automatisierungsvorteile die Plattformkosten. Für ein einzelnes Restaurant oder eine kleine Gruppe, die wöchentlich 10 bis 20 Rechnungen von drei Lieferanten verarbeitet, kann dieselbe Positionsextraktion mittels KI-gestützter Foto-zu-Tabelle-Extraktion erfolgen, die standardmäßige Excel-Ausgabe liefert und mit jedem bereits genutzten tabellenbasierten Tracking-System funktioniert. Der Unterschied liegt im Umfang: AP-Plattformen automatisieren den gesamten Zahlungsprozess. Die Positionsextraktion löst das spezifische Problem, Rechnungsdaten in eine Tabelle zu bekommen – und kann je nach Größenordnung ein Sprungbrett zu einer vollständigen Plattform oder eine dauerhafte, schlanke Lösung sein.

Was passiert, wenn ein Lieferant eine Gutschrift oder eine Korrekturrechnung statt einer Standardrechnung sendet?

Gutschriften, Belastungsanzeigen und Korrekturrechnungen werden wie Standardrechnungen behandelt: Die KI liest das Dokument und extrahiert die von Ihnen definierten Felder. Falls die Gutschrift die ursprüngliche Rechnungsnummer referenziert, wird diese Referenz in der Ausgabe erfasst. Entscheidend ist, eine Spalte für den Belegtyp einzufügen – z. B. „Belegtyp (Rechnung/Gutschrift/Korrektur)“ – damit die Ausgabe zwischen Belastungen und Gutschriften unterscheidet. Gutschriften für Retouren oder Preisberichtigungen fließen in dieselbe Tabellenstruktur wie reguläre Rechnungen, wobei die Spalte für den Belegtyp genaue Nettokostenberechnungen ermöglicht.

Kann ich die Spaltenvorlage speichern und jede Woche wiederverwenden?

Ja. Die von Ihnen definierten Spaltennamen – Lieferantenname, Artikelcode, Artikelbeschreibung, erhaltene Menge, Einzelpreis und alle weiteren Felder – werden nach der ersten Nutzung als Vorlage gespeichert. Jede folgende wöchentliche Liefercharge verwendet dieselbe Vorlage mit einem Klick und liefert jedes Mal eine identisch strukturierte Ausgabe. Dadurch wird die oben beschriebene Preisverlaufs- und Trendverfolgung praktikabel: Eine konsistente Spaltenstruktur über Wochen hinweg ermöglicht die automatische Zusammenführung der Daten in einer Mastertabelle, ohne dass zwischen den Chargen neu formatiert werden muss.