Lebensmittelgroßhändler-Rechnungszeilen stapelweise
in ein wöchentliches Lebensmittelkostenblatt überführen

Der wöchentliche Rechnungsstapel ist kein einzelnes Dokument – er ist eine Zusammenführung von fünf inkompatiblen Formaten

Die wöchentlichen Einkäufe eines Restaurants laufen nicht über einen einzigen Kanal. Die NRA-TCU-Studie ergab, dass Restaurants im Durchschnitt 8,1 Obst- und Gemüselieferanten allein haben – und über alle nicht-mainline Kategorien hinweg liegt der Durchschnitt bei über 50 Lieferantenbeziehungen, mit durchschnittlich 441 bestellten SKUs über den Mainline-Distributor und 907 über alle Konzepte hinweg. Für ein typisches unabhängiges Restaurant sieht der wöchentliche Rhythmus eher so aus:

Das sind ungefähr 90 bis 130 Positionen, die innerhalb eines 48-Stunden-Fensters in fünf verschiedenen Formaten von fünf Lieferanten eintreffen, die fünf verschiedene Benennungskonventionen und fünf verschiedene Einheitensysteme verwenden. Der Batch-Verarbeitungsworkflow hat eine einzige Aufgabe: diesen Stapel in eine einzige Tabelle zu verwandeln, in der jede Spalte konsistent ist, jedes Produkt identifizierbar ist, jeder Preis vergleichbar ist und jede Zeile für die Lebensmittelkostenberichterstattung kategorisiert ist. Für den Standardansatz zur Extraktion einzelner Rechnungen – den unser Schritt-für-Schritt-Extraktionstutorial im Detail behandelt – liegt die Herausforderung in der Formatvielfalt innerhalb eines einzelnen Dokuments. Der Batch-Workflow fügt eine Ebene darüber hinzu: Formatvielfalt über Dokumente hinweg, die zusammengeführt werden müssen.

Spalten einmal definieren – nicht für jeden Lieferanten neu

Der Batch-Workflow beginnt mit einer einzigen Designentscheidung, die alles Weitere bestimmt: Welche Spalten soll jede Zeile in der Ausgabe haben, unabhängig davon, von welchem Lieferanten die Rechnung stammt? Die Antwort muss abdecken, was auf jeder Rechnung steht (Artikelbeschreibung, Menge, Preis) und was nur auf manchen Rechnungen steht (Schwankungsgewicht, Substitutionshinweis, Chargennummer).

Die Technik, die dies über fünf Formate hinweg ermöglicht, ist die Spaltennamensextraktion: Statt eine Vorlage zu erstellen, die besagt „Der Stückpreis steht in Spalte 7 im Layout dieses Lieferanten", definieren Sie die gewünschten Feldnamen – „Stückpreis", „Artikelbeschreibung", „Schwankungsgewicht (J/N)" – und die KI lokalisiert jeden Wert auf jeder Seite, indem sie versteht, was die Information bedeutet, nicht wo sie steht. Dieselbe Spaltendefinition funktioniert über Syscos 5-seitiges PDF, US Foods' 3-seitiges PDF und den handschriftlichen Zettel des Gemüselieferanten, weil die KI nach semantischer Bedeutung liest, nicht nach Layoutposition. Vorlagenbasierte Tools würden fünf separate Konfigurationen erfordern – eine pro Lieferant – und ein handschriftlicher Zettel kann überhaupt nicht als Vorlage dienen.

Hier ist der Spaltensatz für einen vollständigen Wochen-Batch:

Zwei Spalten in diesem Satz – Kategorie und Lieferdatum – sind spezifisch batchbezogene Anliegen. Die Kategorie ermöglicht die lieferantenübergreifende Konsolidierung: Sie normalisiert unterschiedliche Produktnamen in dieselbe Kategorie. Das Lieferdatum sorgt für eine konsistente Wochenabgrenzung: Es überschreibt die jeweilige Datumskonvention des Lieferanten, sodass der Batch eine saubere Kalenderwoche erfasst. Beide werden unten im Detail besprochen.

Die Ausgabe eines Batch-Laufs mit diesen Spalten erzeugt eine einzige Tabelle:

Jede Zeile hat dieselben Spalten. Die Spalte „Lieferant" zeigt Ihnen, von welcher Rechnung jede Zeile stammt. Die Spalte „Kategorie" gruppiert Artikel über alle Lieferanten hinweg. Die Spalte „Fanggewicht" kennzeichnet die Lachszeile zur Überprüfung. Die Spalte „Hinweis" erfasst die Minderlieferung bei den Roma-Tomaten. Das ist die Batch-Ausgabe – eine Tabelle, alle Lieferanten, bereit für die Lebensmittelkosten-Aggregation.

Warum Produktnamen brechen, wenn Sie fünf Lieferanten in einem Blatt zusammenführen

Hier ist ein Problem, das nicht existiert, wenn Sie eine Rechnung nach der anderen verarbeiten. Drei verschiedene Lieferanten verkaufen dieselbe Zutat – Frühlingszwiebeln – unter drei verschiedenen Namen:

Drei verschiedene Zeichenfolgen für dieselbe Zutat. Wenn Sie jede Rechnung einzeln verarbeiten, ist die Namensabweichung unsichtbar – Sie betrachten jeweils nur einen Lieferanten. Wenn Sie alle fünf in einer Batch-Ausgabe zusammenführen, landen diese drei Beschreibungen in drei verschiedenen Zeilen in der Spalte „Positionsbeschreibung". Ihr wöchentliches Lebensmittelkostenblatt enthält nun drei separate Positionen für Frühlingszwiebeln. Eine Aggregation der Ausgaben nach Zutat ist unmöglich – denn „Schalotte" existiert nicht in den Daten. Nur „onion green iceless", „green onion bunch" und „scallion" existieren als separate, unverbundene Zeilen.

Deshalb ist die Kategoriespalte im Batch-Schema nicht optional – sie ist die Normalisierungsebene. Das USAR (Uniform System of Accounts for Restaurants), veröffentlicht von der National Restaurant Association, bietet den standardisierten Codierungsrahmen: Produce ist Konto 5140, Protein (Geflügel) ist 5130, Milchprodukte ist 5160, Bäckerei ist 5150, Lebensmittel und Trockenwaren ist 5170. Wenn jede Position eine Kategorie trägt, landen onion green iceless von Sysco und scallion vom lokalen Lieferanten beide unter Produce – und der Lebensmittelkostenbericht auf Kategorieebene ist unabhängig von Namensunterschieden korrekt.

Deshalb übertrifft die Batch-Verarbeitung mit Spaltennamensextraktion – bei der Sie die Spalten einmal definieren und die KI nach Bedeutung liest – auch vorlagenbasierte Ansätze. Eine Vorlage ordnet zu: „Das Beschreibungsfeld befindet sich in Spalte 2 im Sysco-Layout." Sie kopiert getreu, welche Zeichenfolge dort erscheint. Eine Spaltennamensextraktion fragt: „Was ist die Positionsbeschreibung in dieser Zeile?" – über jedes Layout hinweg. Das Ergebnis sind immer noch unterschiedliche Namen – aber die Kategoriespalte, die die KI befüllt, indem sie die Beschreibung liest und versteht, um welche Art von Artikel es sich handelt, verbindet sie.

Das Problem der Maßeinheit: Warum zwei Stückpreise für dieselbe Zutat nicht vergleichbar sind

Sysco verkauft Hähnchenbrust in Kartons zu 40 Pfund. US Foods verkauft dasselbe Hähnchen in Kartons zu 50 Pfund. Der lokale Lieferant verkauft direkt pro Pfund. In der Batch-Ausgabe zeigt die Sysco-Zeile „Stückpreis: 2,82 $“, die US-Foods-Zeile „Stückpreis: 2,70 $“ und die lokale Lieferanten-Zeile „Stückpreis: 3,10 $“. Welcher Lieferant ist günstiger? Das können Sie nicht sagen – denn 2,82 $ und 2,70 $ könnten Preise pro Pfund oder pro Karton sein. Das Extraktionstool, das eine mit „Stückpreis“ beschriftete Zahl kopiert, ohne das Feld für die Packungsgröße zu erfassen, hat drei Zahlen erzeugt, die vergleichbar aussehen, es aber nicht sind.

Dieses Problem ist in der Lagerverwaltung von Restaurants weit verbreitet. Wie Over Easy Office dokumentiert, ist „einer der schwierigsten Teile der Restaurantbuchhaltung die Umrechnung von ‚1 Karton‘ in ‚24 Flaschen‘ oder ‚10 Pfund‘.“ Der Recipe Cost Calculator drückt es unverblümt aus: „Schlechte Einheitenumrechnungen vergiften Ihre Kosten stillschweigend. Jedes Teammitglied rechnet im Kopf anders um.“ Im Batch-Kontext potenziert sich das Problem: fünf Lieferanten, mehrere Packungsgrößen, inkonsistente Einheitenbeschriftungen. Die Batch-Ausgabe kann nicht für den Lieferantenpreisvergleich verwendet werden, es sei denn, jede Position enthält die Daten, die zur Normalisierung des Preises erforderlich sind.

Das Batch-Schema löst dies, indem es für jede Position die Packungsgröße zusammen mit dem Stückpreis extrahiert. Wenn beide Felder ausgefüllt sind – Sysco: 40-Pfund-Karton zu 2,82 $/Pfund, US Foods: 50-Pfund-Karton zu 2,70 $/Pfund – können die Kosten pro Pfund berechnet oder direkt verglichen werden. Für Teams, die die Normalisierung bereits bei der Extraktion und nicht in einem Nachbearbeitungsschritt wünschen, übernimmt die Funktion berechnete Spalte des Tools die Arithmetik: Definieren Sie eine Spalte wie Kosten pro Pfund (Erweiterter Preis ÷ (Erhaltene Menge × Packungsgewicht in Pfund)), und jede Position wird mit bereits berechneten, normalisierten Stückkosten geliefert.

Ausnahmebehandlung bei fünf Lieferanten: Was ein Einzelrechnungs-Workflow übersieht

Wenn Sie eine Rechnung nach der anderen verarbeiten, wirken Ausnahmen wie Einzelrechnungs-Probleme. Eine Catch-Weight-Anpassung bei Sysco: 40 Pfund Hähnchen bestellt, 38,7 Pfund erhalten, abgerechnet mit 38,7 × 3,87 $. Eine Substitution bei US Foods: 85/15-Rinderhack statt 80/20, gleicher Preis. Eine Teillieferung auf dem Produktbeleg: minus 2 Pfund Roma-Tomaten. Drei verschiedene Ausnahmetypen, drei verschiedene Lieferanten – und in einer Batch-Ausgabe landen alle drei in derselben Tabelle. Wenn das Batch-Schema keine Ausnahmen eingeplant hat, erzeugt die Extraktion saubere Zahlen, die auf drei verschiedene Arten falsch sind.

Die FDA-Verordnung 21 CFR 101.105 regelt die Nettogewichtskennzeichnung für Lebensmittelprodukte – weshalb das Supplier Compliance Manual von Sysco Catch Weight mit drei Dezimalstellen auf jedem Frachtbrief vorschreibt. Dies ist eine regulierte Praxis, keine Lieferanten-Eigenheit. Das Extraktionssystem, das das erste Gewichtsfeld neben „Menge" liest, liest schlicht das falsche Gewicht – die Rechnung wurde entwickelt, um sowohl Bestell- als auch Empfangsgewicht zu zeigen, und die Extraktion muss wissen, welches den Preis bestimmt. Eine vollständige Aufschlüsselung dieser strukturellen Fehlermodi finden Sie in unserem Artikel über warum Sysco- und US-Foods-Rechnungen die Positionsextraktion brechen.

Die Verteidigung des Batch-Schemas gegen diese Ausnahmen sind die Spalten Catch Weight (Y/N) und Adjustment Note. Catch Weight kennzeichnet jede Zeile, in der die abgerechnete Menge von der bestellten Menge abweicht. Die Adjustment Note erfasst Substitutionen, Teillieferungen und handschriftliche Korrekturen. Zusammen ermöglichen sie es Ihnen, eine 90-zeilige Batch-Ausgabe zu scannen und die 5 bis 8 Zeilen zu identifizieren, in denen die extrahierte Zahl überprüft werden muss – statt alle 90 Zeilen zu prüfen, weil Sie nicht erkennen können, welche möglicherweise falsch sind.

Selbst kostenpflichtige Restaurantplattformen räumen die Schwierigkeit vollautomatischer Ausnahmebehandlung bei Lebensmittelverteiler-Rechnungen ein. MarginEdge (330 $/Monat pro Standort) setzt eine menschliche Prüfebene ein, um handschriftliche Notizen zu lesen und Ausnahmezeilen vor der Datenerfassung zu verifizieren. Das Vorhandensein menschlicher Prüfung in einem Tool in dieser Preisklasse ist ein Beleg dafür, dass vollautomatische Batch-Verarbeitung von Lebensmittelrechnungen mehrerer Lieferanten – bei der Ausnahmen Dokumentgrenzen überschreiten – ein schwieriges Problem bleibt. Der hier beschriebene Batch-Workflow verarbeitet die 90 % der Zeilen, die sauber extrahiert werden, und kennzeichnet die 10 %, die Aufmerksamkeit benötigen. Für Restaurantgruppen, die Rechnungen im großen Maßstab über 10+ Standorte verarbeiten, summiert sich diese 90/10-Aufteilung zu erheblichen Zeiteinsparungen.

Datumsgrenzen: Warum in Ihrem Wochen-Batch möglicherweise die Einkäufe eines ganzen Lieferanten fehlen

Die wöchentliche Lebensmittelkostenberichterstattung erfordert eine saubere 7-Tage-Grenze über alle Lieferantenrechnungen hinweg. Das Problem: Lieferanten sind sich nicht einig, welches Datum auf einer Rechnung stehen soll.

Sysco datiert Rechnungen nach Lieferdatum – dem Tag, an dem der Lkw ankam. US Foods datiert manchmal nach Versanddatum – dem Tag, an dem die Bestellung das Lager verließ, was einen Tag vor der Lieferung liegen kann. Ein Gemüselieferant datiert nach dem Tag der Ernte. Ein Molkereilieferant verwendet möglicherweise das Bestelldatum statt des Lieferdatums. Wenn der Batch-Datumsfilter „Rechnungen von Montag bis Sonntag" lautet und US Foods am Montag für eine Lieferung am Dienstag versendet hat, trägt diese Dienstags-Lieferrechnung ein Montagsdatum – und wird aus dem Batch ausgeschlossen. Der wöchentliche Lebensmittelkostenbericht lässt nun die Einkäufe eines gesamten Lieferanten für die Woche aus.

Die NRA-TCU-Umfrage unterstreicht, warum das wichtig ist: 40 % der Betreiber erhalten von Großhändlern keine Daten über die Rechnung hinaus. Es gibt keinen separaten Lieferplan-Feed, keine API, keinen EDI-Datenstrom, der unabhängig bestätigen könnte, wann eine Lieferung eingetroffen ist. Die Rechnung ist der einzige Beleg – und wenn die Rechnung die falsche Datumskonvention für den Batch-Filter trägt, verschwinden die Einkäufe dieses Lieferanten ohne Fehlermeldung aus dem Bericht. Eine Spalte „Lieferdatum" im Extraktionsschema macht die Batch-Grenze explizit und prüfbar.

Was mit dem zusammengeführten Output zu tun ist: Wöchentliche Lebensmittelkosten, Rezeptaktualisierungen und Preishistorie

Der zusammengeführte Batch-Output – eine Tabelle, in der jede Zeile eine Position von einem von fünf Lieferanten ist – ist ein vollständiges Einkaufsjournal für die Woche. Drei Dinge werden möglich, die mit getrennten Lieferantendaten nicht machbar waren:

Wöchentliche Lebensmittelkosten nach Kategorie. Die Aggregation der Spalte Gesamtpreis nach Kategorie ergibt die Wochenausgaben nach USAR-Konto – Proteine (5110/5130) vs. Produkte (5140) vs. Molkerei (5160) vs. Bäckerei (5150) vs. Trockenwaren (5170). Mit dem wöchentlichen Lebensmittelumsatz aus dem POS ist die Berechnung des Lebensmittelkostenprozentsatzes sofort möglich. Die National Restaurant Association berichtet, dass Lebensmittel und Arbeit jeweils etwa 33 Cent pro Dollar Umsatz ausmachen, was eine Vorsteuermarge von etwa 5 % lässt. Ein Lebensmittelkostenbericht, der selbst um 2 % abweicht – die Art von Fehler, die Batch-Verarbeitung ohne Kategorienormalisierung erzeugt – verwandelt eine 5-%-Marge in eine vermeintliche 3-%-Marge oder, schlimmer, versteckt eine echte 3-%-Marge hinter einer Phantom-5-%-Marge.

Rezeptkostenaktualisierungen. Jede Position im Batch-Output trägt einen Stückpreis. Für ein Restaurant, das Tellerkosten verfolgt, fließt dies direkt in die Berechnung des Lebensmittelkostenprozentsatzes ein. Wenn die Sysco-Zeile Hähnchenbrust zu 2,82 $/lb zeigt und die US-Foods-Zeile 2,70 $/lb, fließt der günstigere Preis in die Rezeptkosten ein. Die wöchentliche Batch-Extraktion bedeutet, dass sich Rezeptkosten jede Woche aktualisieren, ohne dass jemand eine Zahl eintippt.

Preishistorie nach Lieferant und Zutat. Wenn Sie die Batch-Ausgabe jeder Woche speichern, entsteht ein durchsuchbares Protokoll aller Zutatspreise von allen Lieferanten, Woche für Woche. Filtern Sie nach Hähnchenbrust über 12 Wochen, stellen Sie den Stückpreis grafisch dar, und Sie haben eine visuelle Historie. Die Grafik zeigt Ihnen, ob die Behauptung des Sysco-Vertreters, „die Preise seien stabil gewesen", mit den Daten übereinstimmt. Wenn ein Lieferant eine Preiserhöhung vorschlägt, liefert die Batch-Historie objektive Belege: „Der Preis für Ihre Hähnchenbrust ist über sechs Wochen von 2,70 $ auf 2,95 $ gestiegen – eine Erhöhung um 9,2 %. Der Rohstoffindex für entbeintes Brustfleisch ist im gleichen Zeitraum um 3,1 % gestiegen." Das Gespräch verlagert sich von Meinungen zu Daten.

Für Restaurantgruppen, die Rechnungen über mehrere Standorte verarbeiten müssen – wo der hier beschriebene Batch-Workflow an jedem Standort unabhängig läuft –, finden Sie in unserem Leitfaden zum Batch-Verarbeiten von Restaurant-Distributorenrechnungen für Lebensmittelkosten auf Multi-Unit-Ebene weitere Informationen. Dasselbe Spaltenschema, dieselben Normalisierungsregeln, dieselbe Kategoriestruktur – nur pro Standort repliziert.

Häufig gestellte Fragen

Von wie vielen Distributoren kauft ein typisches Restaurant tatsächlich pro Woche ein?

Die meisten unabhängigen Restaurants kaufen in einer typischen Woche bei 4 bis 7 Lieferanten ein: ein Broadline-Distributor (Sysco, US Foods oder PFG) für Trockenwaren und Proteine, ein Gemüsespezialist, ein Molkereilieferant, ein Bäcker oder Brotlieferant, ein Getränkedistributor und manchmal Speziallieferanten für Meeresfrüchte, Kaffee oder ethnische Zutaten. Die NRA-TCU-Studie ergab, dass Restaurants in ihrem gesamten Lieferantennetzwerk durchschnittlich 8,1 Gemüsedistributoren und 2,0 Molkereidistributoren haben – aber nur ein Teil davon liefert in einer bestimmten Woche. Der hier beschriebene Batch-Workflow verarbeitet die 5 regelmäßigen Wochenlieferanten. Das Hinzufügen eines 6. oder 7. Lieferanten ändert das Spaltenschema nicht – es fügt Zeilen zur Batch-Ausgabe mit derselben Spaltenstruktur hinzu.

Muss ich für jeden Lieferanten eine separate Spaltenvorlage definieren?

Nein – und genau das ist die Kern-Effizienz des Batch-Workflows. Mit der Spaltennamens-Extraktion definieren Sie den Spaltensatz einmal: Lieferantenname, Rechnungsnr., Artikelcode, Beschreibung, Kategorie, Bestellmenge, Empfangsmenge, Einheit, Packungsgröße, Stückpreis, Gesamtpreis, Fanggewicht, Anpassungshinweis. Dieselbe Spaltendefinition funktioniert mit Syscos 5-seitigem PDF, US Foods' 3-seitigem PDF und der handschriftlichen Gemüsenotiz, weil die KI jeden Wert findet, indem sie versteht, was er bedeutet – nicht durch Abgleich mit einem vorkonfigurierten Layout. Vorlagenbasierte Extraktion würde eine separate Konfiguration für jeden Lieferanten erfordern, und handschriftliche Notizen können überhaupt nicht vorlagenbasiert verarbeitet werden. Das Spaltenschema kann als Vorlage gespeichert und jede Woche mit einem Klick wiederverwendet werden, wodurch jedes Mal eine identisch strukturierte Ausgabe entsteht.

Was passiert, wenn ein Lieferant sein Rechnungslayout ändert?

Layoutänderungen führen sofort zu Fehlern bei der vorlagenbasierten Extraktion – das Tool sucht den Einzelpreis in Spalte 7, aber jetzt steht er in Spalte 9, und jede Zeile liefert den falschen Wert. Die Spaltennamenextraktion ist layoutunabhängig: Die KI sucht semantisch nach „Einzelpreis“ und findet ihn, egal wohin er im neuen Layout verschoben wurde. Keine Neukonfiguration nötig. Das ist besonders im Foodservice-Bereich wichtig, wo Broadline-Distributoren ihre Rechnungsformate regelmäßig aktualisieren und kleinere Lieferanten möglicherweise die Vorlage verwenden, die ihr Buchhalter in diesem Quartal eingerichtet hat.

Wie lange dauert ein wöchentlicher Batch tatsächlich – vom Upload bis zur nutzbaren Tabelle?

Das Hochladen von 5 Rechnungen (eine 5-seitige PDF, eine 3-seitige PDF, ein Handyfoto einer handschriftlichen Notiz, zwei 1-seitige PDFs) dauert mit Drag-and-Drop nur Sekunden. Die KI-Extraktion verarbeitet alle Seiten gleichzeitig. Bei einem Batch mit 100+ Positionen ist die Verarbeitung in der Regel in unter einer Minute abgeschlossen. Der Verifizierungsschritt – das Durchsuchen der Spalten „Catch Weight“ und „Adjustment Note“ nach markierten Zeilen sowie das stichprobenartige Prüfen einiger Artikelbeschreibungen über Lieferanten hinweg – dauert Minuten pro Batch statt der Stunden, die die manuelle Eingabe erfordert. Ein Restaurantmanager, der dieselben 100 Positionen manuell eingibt – bei etwa 15 Sekunden pro Zeile für Tippen plus Nachschlagen von Produktcodes und Einheitenumrechnungen – würde ungefähr 25 bis 40 Minuten benötigen – und das vor jeder Konsolidierung oder Kategorisierung.

Was ist mit Gutschriften und Korrekturrechnungen – brechen sie den Batch?

Nein. Gutschriften und Korrekturrechnungen werden genauso behandelt wie Standardrechnungen: Die KI liest das Dokument und extrahiert die Spalten, die Sie definiert haben. Fügen Sie eine Spalte für Dokumenttyp (Rechnung / Gutschrift / Korrektur) in Ihr Schema ein, damit die zusammengeführte Ausgabe Belastungen von Gutschriften unterscheidet. Gutschriften für retournierte Artikel oder Preiskorrekturen fließen in dieselbe Tabellenstruktur, und die Spalte „Dokumententyp“ ermöglicht genaue Nettokostenberechnungen. Der Batch verarbeitet sie einfach zusammen mit den Rechnungen.

Kann die Batch-Ausgabe direkt in meine Buchhaltungssoftware eingespeist werden?

Die Batch-Ausgabe ist eine Standard-Excel-Datei (XLSX) oder CSV-Datei – dasselbe Format, das QuickBooks, Xero und die meisten Restaurant-Buchhaltungsplattformen für den Import akzeptieren. Jede Spalte ist einem Datenfeld im Buchhaltungssystem zugeordnet. Die Kategorisierung nach USAR-Code (Produce → 5140, Protein → 5110/5130 usw.) sorgt dafür, dass die Zuordnung zu den Sachkonten jede Woche konsistent ist – ohne manuelle Codierung. Für Restaurants, die Google Sheets für die Lebensmittelkostenverfolgung nutzen, können die extrahierten Daten mithilfe des Google-Sheets-Add-ons des Tools direkt in eine Tabelle geschrieben werden – kein Export- und Re-Import-Schritt erforderlich.

Verarbeiten Sie Ihre wöchentlichen Lebensmittelhändler-Rechnungen im Batch

Der in diesem Artikel beschriebene Batch-Workflow – ein Spaltenschema, alle Lieferanten, jede Woche – hängt von einer Extraktion ab, die nach Bedeutung liest und nicht nach Layouts sucht. ImageToTable.ai verwendet die Spaltennamensextraktion: Sie geben die gewünschten Feldnamen ein, und das Vision-Modell findet die passenden Werte auf jeder Seite, unabhängig von Format, Layout oder ob das Dokument gedruckt, handschriftlich oder beides ist. Dieselbe Spaltendefinition funktioniert für Sysco-, US-Foods-, Produktlieferanten-, Molkerei- und Bäckereirechnungen ohne Konfiguration pro Lieferant.

Laden Sie alle fünf Rechnungen von Dienstag auf einmal hoch. Das Tool erstellt eine konsolidierte Tabelle, in der jede Zeile eine Position von einem Ihrer Lieferanten ist, jede Spalte ein von Ihnen festgelegtes Feld ist und die Kategoriespalte alles für die Lebensmittelkostenberichterstattung gruppiert. Verwenden Sie jede Woche dieselbe Spaltenvorlage, und Sie bauen eine Preishistorie auf, die Lieferantenverhandlungen evidenzbasiert macht.