5 Stores, 3 POS-Systeme,
Ein Batch

Die Zahlen gehen auf – nur nicht von allein

Das U.S. Census Bureau zählt über 2 Millionen Betriebe mit mehreren Standorten. Jeder erstellt einen Tagesabschluss. Die meisten fassen diese Abschlüsse noch per Hand zusammen.

Rechnen wir das für einen bescheidenen Fünf-Filialen-Betrieb durch. Fünf Standorte, sieben Tage die Woche – 35 Tagesabschlüsse pro Woche. Etwa 150 im Monat. Bei drei Minuten pro Abschluss für die manuelle Erfassung sind das 105 Minuten pro Woche, nur um Zahlen aus Papier oder PDF in eine Tabelle zu übertragen. Und das ist der Idealfall: ein POS-Format, eine Filialvorlage, keine Abweichungen.

Die Realität ist chaotischer. Filiale A nutzt Toast, das die oberste Zeile als „Netto-Umsatz“ bezeichnet und auf der Quittung in Unterposten für Speisen, Spirituosen, Bier und Wein aufschlüsselt. Filiale B verwendet Square for Retail, das „Gesamteinnahmen“ ausgibt und die Gastronomieeinnahmen anders darstellt. Filiale C, letztes Jahr übernommen, läuft noch auf einem alten NCR Counterpoint-Terminal, dessen Quittungslayout älter ist als der aktuelle Filialleiter. Drei Formate, eine Ziel-Tabelle. Diese Tabelle füllt sich nicht von selbst.

Das Operations Data Abstract 2025 der National Restaurant Association, erstellt aus Daten von über 900 Betrieben landesweit, basiert auf der Prämisse, dass Standortvergleiche standardisierte Daten erfordern. Das Uniform System of Accounts for Restaurants (USAR) – der branchenweit standardisierte Kontenrahmen – ordnet jeden Dollar Restaurantumsatz einem bestimmten nummerierten Konto zu: 4100 für Speisen, 4300 für Spirituosen, 4400 für Bier, 4500 für Wein. Aber POS-Systeme wurden nicht für USAR-Codes entwickelt. Sie wurden entwickelt, um Transaktionen abzuschließen. Die Übersetzungsarbeit bleibt am Betreiber hängen.

Der Engpass ist nicht die Geschwindigkeit der Dateneingabe. Es ist der Übersetzungsschritt zwischen drei verschiedenen Quittungsformaten und einem standardisierten Kontenrahmen. Und keine noch so hohe Tippgeschwindigkeit behebt ein Übersetzungsproblem.

Warum das „zentrale Dashboard“ die Lücke nicht schließen kann

Jedes moderne POS-System verkauft ein Multi-Standort-Dashboard. Toasts Multi-Location Management, Squares zentrale Berichterstattung, Lightspeeds Multi-Outlet-Analysen – sie alle versprechen eine einheitliche Ansicht der Verkäufe über alle Filialen hinweg. Und sie liefern – wenn jede Filiale dasselbe POS-System nutzt, gleich konfiguriert ist und dieselbe Menüstruktur sowie Berichtskategorien hat.

Die Lücke entsteht, sobald Ihr Unternehmen durch Zukäufe wächst und nicht durch Neueröffnungen. Eine Restaurantgruppe, die eine zweite Location erwirbt, übernimmt deren vorhandenes POS-System. Eine Einzelhandelskette, die in eine neue Region expandiert, stellt fest, dass das dort bevorzugte POS-System sich vom bisherigen unterscheidet. Laut einer Umfrage von Rezku aus dem Jahr 2025 planten 29 % der Restaurantbetreiber, neue Standorte zu eröffnen – und jede Neueröffnung ist eine Weggabelung für Ihre Datenkonsistenz.

Selbst innerhalb eines einzigen POS-Ökosystems führt Konfigurationsdrift zu Inkonsistenzen. Der Manager von Filiale 1 hat „Speiseeinnahmen“ als Verkaufskategorie angelegt. Der Manager von Filiale 2, der sechs Monate später eingestiegen ist, wählte „Speisenverkauf“. Filiale 3 hat die Voreinstellung nie geändert. Das Dashboard meldet brav alle drei – als separate Posten. Der Mensch muss sie trotzdem abgleichen.

Auf Reddits r/Bookkeeping finden sich unzählige Varianten desselben Beitrags: Ein Buchhalter betreut vier Restaurantstandorte, lädt separat Berichte von Toast, Square und DoorDash herunter, erstellt eine Excel-Vorlage, um sie zusammenzuführen, und verbringt jeden Monat Stunden mit dem Abgleich der Unterschiede. Wie ein Kommentator es ausdrückte: „Die Art, wie sie Einzahlungen bündeln, ist frustrierend und macht die Suche noch schwieriger.“

Wie Batch-Extraktion 3 POS-Formate ohne Vorlagen liest

Die meisten Dokumentextraktions-Tools arbeiten mit Vorlagen: Sie zeichnen Rechtecke um die gewünschten Felder, und das Tool sucht auf jeder folgenden Seite nach Daten an genau diesen Positionen. Dieser Ansatz scheitert, sobald Sie eine Quittung von einem anderen POS-System hinzufügen – weil die Felder nicht an denselben Positionen sind, nicht gleich heißen und möglicherweise nicht einmal gleich strukturiert sind.

Benutzerdefinierte Spaltenextraktion verfolgt einen anderen Ansatz – einen, der besonders für das POS-übergreifende Batch-Problem geeignet ist. Statt der KI zu sagen, wo sie auf einer Seite suchen soll, sagen Sie ihr, was Sie suchen. Sie definieren Spaltennamen wie „Filiale“, „Datum“, „Speisenverkauf (USAR 4100)“, „Getränkeverkauf (USAR 4300)“, „Bierverkauf (USAR 4400)“ und „Gesamt“. Die KI liest dann jede Quittung – ob von einem Toast-Terminal, einem Square-Lesegerät oder einer Lightspeed-Kasse – und findet die passenden Werte, indem sie versteht, was die Zahlen bedeuten, nicht wo sie auf der Seite stehen.

Dieser semantische Ansatz macht die Batch-Konsolidierung über POS-Formate hinweg möglich. Die KI erkennt, dass „4.287,50 €“ neben der Bezeichnung „Nettoumsatz“ auf einer Toast-Quittung und „4.287,50 €“ unter „Gesamteinnahmen“ auf einer Square-Quittung dasselbe sind – nicht weil sie dieselbe Vorlagenposition teilen, sondern weil die KI versteht, dass sich beide Bezeichnungen auf den endgültigen Transaktionsbetrag beziehen. Der Spaltenname ist der Vertrag: Wie auch immer Sie ihn nennen, die KI sucht auf jeder Seite im Batch nach seiner semantischen Entsprechung.

Der Batch erzeugt dann eine einzige Tabelle, in der jede Zeile eine Quittung und jede Spalte eines der von Ihnen definierten Felder ist – unabhängig davon, welches POS-System welche Quittung erstellt hat. Der Toast-Ausdruck von Filiale A und der Square-Beleg von Filiale B landen in benachbarten Zeilen, mit Werten, die unter denselben Spaltenüberschriften ausgerichtet sind.

Umsatzübersicht für mehrere Standorte in 4 Schritten erstellen

So sieht der Workflow aus Sicht des Betreibers aus. Er erfordert keine POS-Integration, keinen API-Zugriff und keine IT-Beteiligung – Sie arbeiten direkt mit den Tagesabschlussbelegen, die Ihre Manager bereits erstellen.

Für einen tieferen Einblick in die Zuordnung mehrerer POS-Formate auf ein einzelnes USAR-konformes Tabellenblatt – einschließlich Toast-, Square- und NCR-Formatvergleichen sowie einem vierschrittigen täglichen Abstimmungs-Workflow – lesen Sie unseren Leitfaden zum Extrahieren von POS-Belegverkaufsdaten in eine einheitliche Excel-Arbeitsmappe.

Tagesabschnitts-Gruppierung und USAR-Kontenzuordnung

Eine Funktion, die Batch Extraction ermöglicht – und die die meisten POS-Dashboards nicht bieten – ist die Tagesabschnitts-Gruppierung, ohne dass das POS diese erfasst haben muss. Ein Mittagsservice in Filiale A kann auf demselben Tagesabschluss-Beleg erfasst sein wie der Abendservice. Wenn Ihr POS Transaktionen nicht nativ nach Tagesabschnitt aufteilt, existiert diese Spalte in Ihrem Dashboard nicht.

abgeleitete Spalte – einer der drei benutzerdefinierten Spaltenmodi im Extraktions-Workflow – adressiert dieses Problem. Sie definieren eine Spalte namens Day Part (Optionen: Lunch/Dinner/All Day), und die KI liest den Beleginhalt – Zeitstempel, Positionen, Gesamtstruktur – und leitet ab, welchen Tagesabschnitt der Beleg repräsentiert. Sie schreibt die Antwort in die Ausgabetabelle, obwohl „Day Part“ nie ein Feld auf dem Originalbeleg war. Diese Spalte kann dann Pivot-Tabellen antreiben und ermöglicht es Ihnen, die Mittagsleistung über alle fünf Filialen und die Abendleistung über alle fünf Filialen in einer einzigen Ansicht zu vergleichen.

Dieselbe Ableitungslogik gilt für die USAR-Kontenzuordnung. Wenn Sie eine Spalte als USAR Account (Optionen: 4100 Food/4300 Liquor/4400 Beer/4500 Wine) definieren, kann die KI die positionsbezogene Aufschlüsselung des Belegs lesen und jeden Verkauf dem korrekten USAR-Code zuordnen – sogar bei Belegen von POS-Systemen, die überhaupt keine USAR-Terminologie verwenden. Ein Square-Beleg mit „Drinks“ wird basierend auf den tatsächlichen Positionen darunter dem passenden USAR-Alkoholkonto zugeordnet. Ein Toast-Beleg, der Spirituosen bereits separat ausweist, erhält direkt die Zuordnung 4300.

Der USAR-Kontenrahmen, veröffentlicht von der National Restaurant Association, unterteilt die Verkaufskonten der 4000-Ebene in spezifische Erlöskategorien: 4100 Food Sales (mit Unterkonten 4110 Food, 4190 Discounts & Comps), 4300 Liquor Sales (4310 Liquor, 4390 Discounts), 4400 Beer Sales (4410 Beer, 4420 Bottle Beer, 4430 Draft Beer) und 4500 Wine Sales. Wenn Ihr Buchhaltungssystem oder Reporting-Stack Daten erwartet, die auf diese Kategorien ausgerichtet sind, ist der Übersetzungsschritt von rohen POS-Belegen zu USAR-codierten Einträgen manuelle Arbeit, die mit jedem weiteren Standort zunimmt. Batch Extraction integriert diese Übersetzung direkt in den Verarbeitungsschritt.

Was sich ändert, wenn Sie aufhören, Tabellen zu verknüpfen

Der Unterschied zwischen manueller Konsolidierung und Batch-Extraktion liegt nicht nur in der Zeit – obwohl die Zeitersparnis erheblich ist. Bei 3 Minuten pro Beleg für die manuelle Erfassung verbringt eine Kette mit fünf Filialen rund 7,5 Stunden pro Monat mit der Übertragung von Belegen in Tabellen. Die Batch-Extraktion reduziert dies auf die Zeit, die zum Sammeln und Hochladen der Belege benötigt wird: etwa 10 Minuten pro Woche für einen Betrieb mit fünf Filialen.

Die strukturellere Veränderung ist jedoch die Datenkonsistenz über alle Standorte hinweg. Bei manueller Konsolidierung trifft die Person, die die Daten zusammenführt, Ermessensentscheidungen: „Diese Zahl auf dem Toast-Beleg sieht aus wie die ‚Netto-Umsätze‘-Zahl von Square, also setze ich sie in dieselbe Spalte." Diese Ermessensentscheidungen summieren sich über 150 monatliche Belege. Das Ergebnis ist eine Tabelle, die vollständig aussieht, aber tatsächlich keine vergleichbaren Daten über die Filialen hinweg enthält – weil die Zuordnungsentscheidungen nicht einheitlich waren.

Die semantische Extraktion ersetzt diese Ermessensentscheidungen durch einen einzigen Satz von Spaltendefinitionen, der einheitlich auf jeden Beleg angewendet wird. Die KI wird nicht müde und beginnt nicht, beim 147. Beleg anders zu raten.

Die National Restaurant Association berichtete in ihrem 2025 Restaurant Operations Data Abstract, dass die Arbeitskosten im Median 36,5 % des Umsatzes bei Vollservice-Restaurants und 34,0 % bei Schnellrestaurants ausmachen. Kostenverhältnisse sind jedoch nur dann handlungsrelevant, wenn der Umsatz-Nenner genau ist – und Genauigkeit beginnt mit einer konsistenten Datenerfassung. Wenn die Umsätze jeder Filiale unterschiedlich zusammengestellt werden, basiert die daraus resultierende Primärkostenanalyse auf Sand.

Speziell für den Einzelhandel mit mehreren Standorten prognostiziert der NRF für 2026 Einzelhandelsumsätze von 5,6 Billionen US-Dollar, ein Anstieg von 4,4 % gegenüber 2025. Die Betreiber, die sich einen Anteil an diesem Wachstum sichern, sind diejenigen, die ihre Leistung klar genug sehen können, um darauf zu reagieren – nicht diejenigen, die noch die Belege des letzten Monats abstimmen, während die dieses Monats sich bereits stapeln.

Häufig gestellte Fragen

Funktioniert die Stapelverarbeitung, wenn jede Filiale ein anderes Kassensystem nutzt?

Ja – genau dafür ist sie konzipiert. Da die Extraktion semantisch (basiert auf dem Verständnis der Datenbedeutung) und nicht vorlagenbasiert (basiert auf der Position der Daten auf der Seite) erfolgt, können Belege von Toast, Square, Lightspeed, NCR Counterpoint, Clover oder jedem anderen Kassensystem im selben Stapel verarbeitet werden. Die von Ihnen definierten Spaltennamen sind die Brücke: Die KI findet die passenden Werte auf jedem Beleg, unabhängig von der Bezeichnung des jeweiligen Kassensystems.

Was ist, wenn ein Tagesabschlussbeleg nicht alle benötigten Felder enthält?

Manche Kassensysteme drucken detailliertere Belege als andere. Ein Toast-Beleg zeigt in der Regel Zwischensummen für Essen, Spirituosen, Bier und Wein. Ein einfacher Square-Beleg zeigt möglicherweise nur eine Gesamtsumme. Fehlt ein Feld auf einem Beleg, bleibt die Zelle in der Ausgabe leer – es werden keine Daten erfunden oder geraten. Wenn Sie konsistente Unterkategorien für alle Standorte benötigen, können Sie die Belegkonfiguration der Kassen nach Möglichkeit vereinheitlichen, auch wenn die zugrunde liegenden Kassensysteme unterschiedlich bleiben.

Kann die KI einen einzelnen Tagesabschlussbeleg in separate Tagesabschnitte aufteilen?

Zeigt der Beleg selbst getrennte Abschnitte für Mittag- und Abendessen (unterschiedliche Zeitstempel, separate Zwischensummen), kann die KI diese Struktur erkennen und entsprechend extrahieren. Zeigt der Beleg nur eine tägliche Gesamtsumme ohne zeitliche Aufschlüsselung, kann die KI basierend auf dem Gesamtinhalt und Kontext des Belegs eine Tagesabschnittsklassifizierung ableiten, aber keine Zwischensummen erfinden, die in der Quelle nicht existieren. Für präzise Umsatzaufteilungen nach Tagesabschnitten ist es am zuverlässigsten, wenn jede Filiale separate Belege pro Schicht erstellt.

Wie ist das im Vergleich zu einer direkten POS-Buchhaltungs-Integration?

Direkte POS-Integrationen (wie Toast-zu-Restaurant365 oder Square-zu-QuickBooks) synchronisieren Transaktionsdaten automatisch und sind empfehlenswert, wenn verfügbar. Sie machen die Verarbeitung einzelner Belege überflüssig. Sie haben jedoch zwei Einschränkungen: Erstens erfordern sie, dass jeder Standort ein unterstütztes Kassensystem verwendet, was bei übernommenen oder gemischten Flotten nicht immer der Fall ist. Zweitens ist die Datenzuordnung nur so gut wie die Standardfeldzuordnungen der Integration – wenn Ihr Kassensystem etwas anders bezeichnet als Ihr Buchhaltungssystem erwartet, kann die Integration es stillschweigend falsch zuordnen. Die Stapelbelegverarbeitung arbeitet auf einer anderen Ebene: Sie verwendet die tatsächlichen Tagesabschlussdokumente, nicht API-Datenfeeds, was nützlich ist, wenn keine Integrationen verfügbar sind oder Sie die von der Integration gemeldeten Daten überprüfen möchten.

Was ist mit Geschäften, die noch Papierbelege ohne digitalen Export ausdrucken?

Ein Smartphone-Foto des gedruckten Belegs reicht aus. Die KI liest Text und Zahlen aus Bildern. Unter normaler Innenbeleuchtung fotografierte Papierbelege liefern brauchbare Ergebnisse, wobei klare, gut beleuchtete Fotos eine höhere Genauigkeit erzielen. Unscharfe oder schräge Fotos können bei kleineren Texten wie Dezimalbeträgen zu Lesefehlern führen.

Sind die Daten bei der Stapelverarbeitung von Belegen über ein Online-Tool sicher?

Hochgeladene Dateien werden im Arbeitsspeicher verarbeitet und nach Abschluss der Verarbeitung nicht gespeichert. Falls Ihre Organisation spezifische Compliance-Anforderungen hat (z. B. PCI-DSS für Zahlungsdaten auf Belegen), prüfen Sie die Datenverarbeitungsrichtlinie des Tools. Beachten Sie, dass Tagesabschluss-Kassenbons in der Regel Verkaufszusammenfassungen enthalten – Summen, Zahlungsarten, Steuern – und nicht einzelne Kundenzahlungsdetails, was die Gefährdung im Vergleich zu Transaktionsexporten begrenzt.

Die Tabelle ist nicht das Ziel

Die konsolidierte Tabelle ist ein Mittel, nicht der Zweck. Was sie ermöglicht, sind schnellere Abschlusszyklen, die Gewissheit, dass „Nettoumsatz“ von Filiale A und „Gesamteinnahmen“ von Filiale B tatsächlich dasselbe bedeuten, und die Möglichkeit, Tageszeit-Leistungen über Standorte hinweg zu vergleichen, ohne erst zwei Stunden mit dem Übersetzen von Belegen zu verbringen.

Der eigentliche Wandel ist der vom wöchentlichen Abgleich als lästiger Pflicht hin zum Abgleich als Datenintegritätsprüfung – etwas, das Sie verifizieren, nicht etwas, das Sie von Grund auf neu aufbauen. Wenn der Übersetzungsschritt wegfällt, wird die Zeit, die Sie früher dafür aufgewendet haben, zur Zeit für die Entscheidungen, die diese Übersetzung unterstützen sollte.