Lebensmittel-Großhändler-Posten
in einem wöchentlichen Lebensmittelkostenblatt zusammenführen

Der wöchentliche Rechnungsstapel ist kein einheitliches Dokument – sondern eine Mischung aus fünf inkompatiblen Formaten

Der wöchentliche Einkauf eines Restaurants läuft 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-mainstreamigen Kategorien hinweg liegt der Durchschnitt bei über 50 Lieferantenbeziehungen, mit durchschnittlich 441 Artikeln, die über den Hauptlieferanten bezogen werden, und 907 über alle Konzepte hinweg. Für ein typisches unabhängiges Restaurant sieht der wöchentliche Rhythmus eher so aus:

Das sind grob 90 bis 130 Positionen, die innerhalb von 48 Stunden eingehen – in fünf verschiedenen Formaten, von fünf Lieferanten mit fünf unterschiedlichen Namenskonventionen und fünf verschiedenen Einheitensystemen. Der Batch-Workflow hat eine einzige Aufgabe: diesen Haufen in eine einzige Tabelle zu verwandeln, in der jede Spalte einheitlich ist, jedes Produkt identifizierbar, jeder Preis vergleichbar und jede Zeile für die Lebensmittelkostenberichterstattung kategorisiert ist. Beim Standardansatz zum Extrahieren einzelner Rechnungen – den unser Schritt-für-Schritt-Extraktionstutorial ausführlich behandelt – liegt die Herausforderung in der Formatvielfalt innerhalb eines einzelnen Dokuments. Der Batch-Workflow fügt eine weitere Ebene hinzu: Formatvielfalt zwischen Dokumenten, die zusammengeführt werden müssen.

Spalten einmal definieren – nicht pro Lieferant

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 (Fanggewicht, Substitutionshinweis, Chargennummer).

Die Technik, die dies über fünf Formate hinweg funktionieren lässt, ist die Spaltennamenextraktion: Statt einer Vorlage, die besagt „Der Stückpreis steht in Spalte 7 im Layout dieses Lieferanten“, definieren Sie die gewünschten Feldnamen – „Stückpreis“, „Artikelbeschreibung“, „Fanggewicht (J/N)“ – und die KI findet jeden Wert auf jeder Seite, indem sie versteht, was die Information bedeutet, nicht wo sie steht. Dieselbe Spaltendefinition funktioniert mit Syscos 5-seitigem PDF, US Foods' 3-seitigem PDF und dem handgeschriebenen Zettel des Gemüsehändlers, weil die KI nach semantischer Bedeutung liest, nicht nach Layout-Position. Vorlagenbasierte Tools würden fünf separate Konfigurationen erfordern – eine pro Lieferant – und ein handgeschriebener Zettel kann überhaupt nicht als Vorlage verwendet werden.

Hier ist das Spaltenset für eine vollständige wöchentliche Charge:

Zwei Spalten in diesem Satz – Kategorie und Lieferdatum – sind spezifisch für die Chargenebene. Die Kategorie ermöglicht die lieferantenübergreifende Konsolidierung: Sie normalisiert unterschiedliche Produktnamen in denselben Eimer. Das Lieferdatum sorgt für eine konsistente Wochenabgrenzung: Es überschreibt die jeweilige Datumskonvention des Lieferanten, sodass die Charge eine saubere Kalenderwoche abbildet. Beide werden unten im Detail erläutert.

Die Ausgabe eines Chargenlaufs mit diesen Spalten erzeugt eine einzige Tabelle:

Jede Zeile hat dieselben Spalten. Die Spalte Lieferantenname zeigt, von welcher Rechnung jede Zeile stammt. Die Spalte Kategorie gruppiert Artikel lieferantenübergreifend. Die Spalte Fanggewicht markiert die Lachszeile zur Überprüfung. Die Spalte Korrekturvermerk erfasst den Mangel bei den Roma-Tomaten. Das ist die Chargenausgabe – eine Tabelle, alle Lieferanten, bereit für die Lebensmittelkostenaggregation.

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

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

Drei verschiedene Bezeichnungen für dieselbe Zutat. Bei Einzelrechnungsprüfung fällt die Namensabweichung nicht auf – Sie sehen immer nur einen Lieferanten. Werden alle fünf Rechnungen in einer Sammelausgabe zusammengeführt, landen diese drei Beschreibungen in drei verschiedenen Zeilen der Spalte „Artikelbeschreibung“. Ihre wöchentliche Lebensmittelkostenaufstellung enthält nun drei separate Posten für Frühlingszwiebeln. Eine Aggregation der Ausgaben pro Zutat ist unmöglich – denn „Frühlingszwiebel“ existiert nicht in den Daten. Nur „onion green iceless“, „green onion bunch“ und „scallion“ existieren als separate, unverbundene Zeilen.

Deshalb ist die Spalte „Kategorie“ im Batch-Schema nicht optional – sie ist die Normalisierungsebene. Das Uniform System of Accounts for Restaurants (USAR), herausgegeben von der National Restaurant Association, liefert den standardisierten Codierungsrahmen: Obst und Gemüse ist Konto 5140, Protein (Geflügel) ist 5130, Milchprodukte ist 5160, Backwaren ist 5150, Lebensmittel und Trockenwaren ist 5170. Wenn jede Position eine Kategorie hat, landen onion green iceless von Sysco und scallion vom lokalen Lieferanten beide unter Obst und Gemüse – und der lebensmittelkostenbericht auf Kategorieebene ist unabhängig von Namensunterschieden korrekt.

Deshalb übertrifft die Batch-Verarbeitung mit Spaltennamensextraktion – bei der die Spalten einmal definiert werden und die KI die Bedeutung liest – auch templatebasierte Ansätze. Ein Template bildet ab: „Das Beschreibungsfeld befindet sich in Spalte 2 im Layout von Sysco.“ Es kopiert getreu die Zeichenfolge, die dort steht. Eine Spaltennamensextraktion fragt: „Was ist die Artikelbeschreibung in dieser Zeile?“ – über jedes Layout hinweg. Das Ergebnis sind immer noch unterschiedliche Namen – aber die Spalte „Kategorie“, 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 40-Pfund-Kisten. US Foods verkauft das gleiche Hähnchen in 50-Pfund-Kisten. 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 lässt sich nicht sagen – denn 2,82 $ und 2,70 $ könnten Preise pro Pfund oder pro Kiste sein. Das Extraktionstool, das eine mit „Stückpreis“ bezeichnete Zahl kopiert, ohne das Feld für die Packungsgröße zu erfassen, hat drei Zahlen produziert, die vergleichbar aussehen, es aber nicht sind.

Dieses Problem ist in der Bestandsverwaltung von Restaurants weit verbreitet. Wie Over Easy Office dokumentiert, ist „einer der schwierigsten Teile der Restaurantbuchhaltung die Umrechnung von ‚1 Kiste‘ in ‚24 Flaschen‘ oder ‚10 Pfund‘“. Der Recipe Cost Calculator drückt es unverblümt aus: „Schlechte Einheitenumrechnungen vergiften Ihre Kosten still und leise. Jedes Teammitglied rechnet im Kopf anders um.“ Im Batch-Kontext potenziert sich das Problem: fünf Lieferanten, mehrere Packungsgrößen, inkonsistente Einheitenbezeichnungen. 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 behebt dies, indem es für jede Position die Packungsgröße zusammen mit dem Stückpreis extrahiert. Mit beiden ausgefüllten Feldern – Sysco: 40-Pfund-Kiste zu 2,82 $/Pfund, US Foods: 50-Pfund-Kiste zu 2,70 $/Pfund – können die Kosten pro Pfund berechnet oder direkt verglichen werden. Für Teams, die die Normalisierung bereits zum Zeitpunkt der Extraktion und nicht in einem nachgelagerten Schritt wünschen, bietet die Funktion berechnete Spalten des Tools die Arithmetik: Definieren Sie eine Spalte wie Kosten pro Pfund (Gesamtpreis ÷ (Erhaltene Menge × Packungsgewicht in Pfund)), und jede Position wird mit bereits berechneten normalisierten Stückkosten geliefert.

Ausnahmebehandlung bei fünf Lieferanten: Was ein einzelner Rechnungsworkflow übersieht

Wenn Sie Rechnungen einzeln bearbeiten, sehen Ausnahmen wie Einzelrechnungsprobleme aus. Eine Catch-Weight-Anpassung bei Sysco: 40 lbs Hähnchen bestellt, 38,7 lbs erhalten, abgerechnet mit 38,7 × 3,87 $. Eine Substitution bei US Foods: 85/15 Rinderhackfleisch ersetzt 80/20, gleicher Preis. Eine Mindermenge beim Gemüse: minus 2 lbs 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 vorsieht, liefert die Extraktion saubere Zahlen, die auf drei verschiedene Arten falsch sind.

Die FDA-Verordnung 21 CFR 101.105 regelt die Nettogewichtsangabe bei Lebensmitteln – weshalb Syscos Lieferanten-Compliance-Handbuch 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“ ausliest, liest schlicht das falsche Gewicht – die Rechnung zeigt sowohl Bestell- als auch Liefergewicht, 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 Zeilenextraktion sprengen.

Die Verteidigung des Batch-Schemas gegen diese Ausnahmen sind die Spalten Catch Weight (J/N) und Anpassungsnotiz. Catch Weight kennzeichnet jede Zeile, in der die berechnete Menge von der bestellten Menge abweicht. Die Anpassungsnotiz erfasst Substitutionen, Mindermengen und handschriftliche Korrekturen. Zusammen ermöglichen sie, einen 90-zeiligen Batch-Durchlauf zu scannen und die 5 bis 8 Zeilen zu identifizieren, bei denen die extrahierte Zahl überprüft werden muss – statt alle 90 Zeilen zu prüfen, weil man nicht weiß, welche falsch sein könnten.

Selbst kostenpflichtige Restaurantplattformen räumen ein, dass die vollautomatische Fehlerbehandlung bei Rechnungen von Lebensmittellieferanten schwierig ist. MarginEdge (330 $/Monat pro Standort) setzt eine manuelle Prüfung ein, um handschriftliche Notizen zu lesen und Ausnahmepositionen zu verifizieren, bevor Daten gebucht werden. Die manuelle Prüfung bei einem Tool dieser Preisklasse zeigt, dass die vollautomatische Stapelverarbeitung von Rechnungen mehrerer Lieferanten – bei der Ausnahmen über Belegsgrenzen hinweg auftreten – weiterhin ein schwieriges Problem darstellt. Der hier beschriebene Stapelworkflow verarbeitet die 90 % der Positionen, die sauber extrahiert werden, und markiert die 10 %, die Aufmerksamkeit erfordern. Für Restaurantgruppen, die Rechnungen im großen Stil an über 10 Standorten verarbeiten, führt diese 90/10-Aufteilung zu erheblichen Zeitersparnissen.

Datumsgrenzen: Warum in Ihrem Wochenstapel möglicherweise die vollen Einkäufe eines 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 eine Rechnung gehört.

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

Die NRA-TCU-Umfrage zeigt, warum das wichtig ist: 40 % der Betreiber erhalten von Distributoren keine Daten über die Rechnung hinaus. Es gibt keinen separaten Feed für Lieferpläne, keine API, keinen EDI-Datenstrom, der unabhängig bestätigen würde, wann eine Lieferung eingetroffen ist. Die Rechnung ist der einzige Beleg – und wenn die Rechnung die falsche Datumskonvention für den Batch-Filter verwendet, verschwinden die Einkäufe dieses Lieferanten ohne Fehlermeldung aus dem Bericht. Eine Spalte für das Lieferdatum im Extraktionsschema macht die Batch-Grenze explizit und nachvollziehbar.

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 lieferantengetrennten Daten nicht machbar waren:

Wöchentliche Lebensmittelkosten nach Kategorie. Die Aggregation der Spalte Extended Price nach Category ergibt die Wochenausgaben pro USAR-Konto — Proteine (5110/5130) vs. Produkte (5140) vs. Molkereiprodukte (5160) vs. Bäckerei (5150) vs. Trockenwaren (5170). Mit dem wöchentlichen Lebensmittelumsatz aus dem POS ergibt sich der Lebensmittelkostenprozentsatz sofort. Die National Restaurant Association berichtet, dass Lebensmittel und Arbeit jeweils etwa 33 Cent pro Dollar Umsatz ausmachen, was eine Vorsteuermarge von etwa 5 % ergibt. Ein Lebensmittelkostenbericht, der selbst um 2 % abweicht — die Art von Fehler, die durch Stapelverarbeitung ohne Kategorienormalisierung entsteht — verwandelt eine 5-%-Marge in eine vermeintliche 3-%-Marge oder, schlimmer noch, verbirgt eine echte 3-%-Marge hinter einer Phantom-5-%-Marge.

Rezeptkostenaktualisierungen. Jede Position im Stapelausgang enthält einen Stückpreis. Für ein Restaurant, das die Gerichtskosten verfolgt, fließt dies direkt in die Berechnung des Lebensmittelkostenprozentsatzes ein. Wenn die Sysco-Zeile Hähnchenbrust zu 2,82 $/lb und die US-Foods-Zeile zu 2,70 $/lb anzeigt, fließt der günstigere Preis in die Rezeptkosten ein. Die wöchentliche Stapelextraktion bedeutet, dass sich die Rezeptkosten jede Woche aktualisieren, ohne dass jemand eine Zahl eingeben muss.

Preisverlauf nach Lieferant und Zutat. Die Speicherung des wöchentlichen Batch-Outputs erstellt eine durchsuchbare Historie aller Zutatenpreise jedes Lieferanten, Woche für Woche. Filtern Sie nach Hähnchenbrust über 12 Wochen, stellen Sie den Stückpreis grafisch dar, und Sie erhalten eine visuelle Historie. Die Grafik zeigt, 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: „Ihr Hähnchenbrustpreis ist in 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." Die Diskussion verlagert sich von Meinung zu Daten.

Für Restaurantgruppen, die Rechnungen über mehrere Standorte hinweg verarbeiten müssen – bei denen der hier beschriebene Batch-Workflow an jedem Standort unabhängig läuft – siehe unseren Leitfaden zur Batch-Verarbeitung von Restaurant-Distributorenrechnungen für Lebensmittelkosten auf Multi-Unit-Ebene. Das gleiche Spaltenschema, die gleichen Normalisierungsregeln, die gleiche Kategoriestruktur – einfach 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: einem Großhändler (Sysco, US Foods oder PFG) für Trockenwaren und Proteine, einem Gemüsespezialisten, einem Molkereilieferanten, einer Bäckerei oder einem Brotlieferanten, einem Getränkedistributor und manchmal Speziallieferanten für Meeresfrüchte, Kaffee oder ethnische Zutaten. Die NRA-TCU-Erhebung 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 aus. Der hier beschriebene Batch-Workflow verarbeitet die 5 regelmäßigen wöchentlichen Lieferanten. Das Hinzufügen eines 6. oder 7. Lieferanten ändert das Spaltenschema nicht – es fügt dem Batch-Output Zeilen 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 Spaltennamen-Extraktion definieren Sie die Spalten einmal: Lieferantenname, Rechnungs-Nr., Artikelcode, Beschreibung, Kategorie, Bestellmenge, Erhaltene Menge, Einheit, Packungsgröße, Einzelpreis, Gesamtpreis, Fanggewicht, Korrekturvermerk. Dieselbe Spaltendefinition funktioniert für Syscos 5-seitige PDF, US Foods' 3-seitige PDF und den handgeschriebenen Produktzettel, weil die KI jeden Wert anhand seiner Bedeutung findet – nicht durch Abgleich mit einem vorkonfigurierten Layout. Template-basierte Extraktion würde für jeden Lieferanten eine separate Konfiguration erfordern, und handschriftliche Notizen lassen sich gar nicht als Vorlage abbilden. Das Spaltenschema kann als Vorlage gespeichert und jede Woche mit einem Klick wiederverwendet werden – mit stets identisch strukturierter Ausgabe.

Was passiert, wenn ein Lieferant sein Rechnungslayout ändert?

Layout-Änderungen lassen die template-basierte Extraktion sofort scheitern – das Tool sucht den Einzelpreis in Spalte 7, aber jetzt steht er in Spalte 9, und jede Zeile liefert den falschen Wert. Die Spaltennamen-Extraktion ist layout-unabhä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 wichtig in der Gastronomie, wo Großhändler ihre Rechnungsformate regelmäßig aktualisieren und kleinere Lieferanten oft das Template verwenden, das ihre Buchhalterin 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 (ein 5-seitiges PDF, ein 3-seitiges 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 über 100 Positionen ist die Verarbeitung in der Regel in unter einer Minute abgeschlossen. Der Prüfschritt – die Spalten „Catch Weight“ und „Adjustment Note“ auf markierte Zeilen scannen, stichprobenartig einige Artikelbeschreibungen über Lieferanten hinweg prüfen – dauert pro Batch Minuten, statt der Stunden, die die manuelle Eingabe erfordert. Ein Restaurantleiter, der dieselben 100 Positionen manuell eingibt, würde bei etwa 15 Sekunden pro Position für Tipparbeit plus Nachschlagen von Produktcodes und Einheitenumrechnungen etwa 25 bis 40 Minuten benötigen – und das vor jeglicher Konsolidierung oder Kategorisierung.

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

Nein. Gutschriften und Korrekturrechnungen werden genauso behandelt wie Standardrechnungen: Die KI liest das Dokument und extrahiert die von Ihnen definierten Spalten. 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 ein, und die Spalte „Dokumenttyp“ ermöglicht genaue Nettokostenberechnungen. Der Batch verarbeitet sie einfach zusammen mit den Rechnungen.

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

Der Batch-Export erfolgt als Standard-Excel-Datei (XLSX) oder CSV – 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 (Obst/Gemüse → 5140, Protein → 5110/5130 usw.) sorgt für eine konsistente Zuordnung zu den Sachkonten – Woche für Woche, ohne manuelle Codierung. Für Restaurants, die Google Sheets zur Lebensmittelkostenverfolgung nutzen, können die extrahierten Daten mit dem Google-Sheets-Add-on des Tools direkt in eine Tabelle geschrieben werden – kein Export und Re-Import nötig.

Wöchentliche Rechnungen von Lebensmittelhändlern stapelweise verarbeiten

Der in diesem Artikel beschriebene Batch-Workflow – ein Spaltenschema, alle Lieferanten, jede Woche – basiert auf einer Extraktion, die nach Bedeutung statt nach Layout sucht. ImageToTable.ai nutzt 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 bei Sysco, US Foods, Gemüsehändlern, Molkereien und Bäckereirechnungen – ohne lieferantenspezifische Konfiguration.

Laden Sie alle fünf Rechnungen von Dienstag auf einmal hoch. Das Tool erstellt eine konsolidierte Tabelle, in der jede Zeile einen Posten eines Ihrer Lieferanten darstellt, 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.