Why can't multi-unit groups see prime cost in real time?
Your controller can add two numbers and divide. Trouble is, those numbers arrive from three systems, on three schedules, for eight locations that don't code things the same way.
Answered in short
4 things that decide this
- 01Multi-unit groups can't see prime cost in real time because the number is assembled from three systems: the POS for sales, invoices and inventory counts for cost of goods, and scheduling or payroll for labor. Each closes on its own clock, and the controller joins them by hand after month end.
- 02The arithmetic is trivial. The join is the work: mapping every location's sales categories, general-ledger accounts and job codes to one chart of accounts, then keeping that mapping true as menus, rosters and vendors change.
- 03Packaged tools cover parts of it. MarginEdge states it pulls 7shifts labor onto the P&L daily; connectors such as Bookkeep post a daily Toast sales journal to the ledger. The gaps are mixed POS estates after acquisitions, franchise entity structures, commissary transfers and the inventory count itself, which no API makes daily.
- 04A daily view is a data problem, not a dashboard: one nightly pipeline per location, one chart of accounts with an owner, and a count cadence the kitchen will keep. Do that and prime cost by location lands on the ops lead's screen the next morning instead of after close.
Where each half of the number comes from, and when
Sales are the easy third. Toast, Square, Lightspeed or whatever each location runs closes the day at night and exposes it through an API or an export. That's why a sales journal into QuickBooks is the first integration most groups build. Net sales by location can be on your screen at 6am.
Labor is nearly as fast and slightly dishonest. Clock punches land nightly, so scheduled and worked hours are available the next day. But tips, overtime corrections and salaried allocations settle on the payroll cycle. Your daily labor number is a close estimate that gets trued up later. Groups that know this tolerate it; groups that don't argue about it.
Cost of goods is the slow third. Invoices arrive on the vendor's schedule, and a true cost of goods needs a closing count, which most kitchens take weekly or monthly. Between counts, a daily figure uses purchases as a stand-in for usage. That's fine for spotting a bad week and wrong for closing the books. Honest 'real time' for prime cost is daily, on estimated usage, corrected at each count.
What a group has to put in place to see it daily
Start with one chart of accounts and a mapping table. Every POS sales category, every vendor GL code and every payroll job code at each of your locations points at one line in the group chart. This table is the product. Give it an owner, because a new LTO or a renamed shift breaks it quietly.
Then a nightly pull per location: sales by category from the POS, hours and loaded rates from scheduling or payroll, purchases from invoice capture, plus the latest count. Each night the pipeline writes one row per location with COGS (estimated between counts), labor and net sales. A location that moves past its budget gets flagged. Alerts go to your area manager, not to a report nobody opens.
Where everything already runs in one suite, buy the suite's report. Restaurant365 sells accounting, inventory and scheduling as one product, and a group with all three inside it should read prime cost there. A custom layer is for the group that isn't shaped like that: two POS systems from an acquisition, franchise entities with their own books, a commissary that transfers product between sites. That trade-off is real. It is built and maintained rather than switched on, and it needs your kitchens to keep counting.
- 01Sales: Toast, Square, Lightspeed or whatever each location runs, pulled nightly by API or export.
- 02Labor: 7shifts, HotSchedules, your payroll provider, or the FSM's own timeclock, with loaded rates applied.
- 03COGS: invoice capture for purchases, a count cadence the kitchen keeps, and an estimate rule everyone agrees on between counts.
- 04One mapping table, one owner, and a change log, because that table is where 'real time' actually breaks.
- POS closesNet sales by category, per site.
- Labor exportedHours and rates, per site.
- Purchases + countInvoices in, last count applied.
- MappedEverything onto one chart of accounts.
- Prime cost by siteEstimated between counts, trued at each.
- AlertArea manager, by 7am, only where it moved.
Your controller still owns the close; the pipeline just stops the close from being the first time anyone sees the number.
Related questions
01Can Restaurant365 or MarginEdge give us real-time prime cost out of the box?+
Yes, within their own boundaries. Restaurant365 bundles accounting, inventory and scheduling, so a group running all three inside it reports from one place, and MarginEdge states that it brings 7shifts labor onto the P&L daily. Both assume one POS family, one entity structure and their own count workflow. A group with a mixed estate, franchise entities or a commissary usually ends up exporting from both into a spreadsheet, which is the manual join this page is about.
02How real can 'real time' be for prime cost?+
Daily is the honest floor, and cost of goods is estimated between counts. Sales and hours can be next-morning figures; product usage can only be exact on count day. Treat the daily number as an early warning and the counted number as the record, and label each one so nobody confuses them.
03What does the controller still do once this runs?+
Everything that needs judgement: owning the chart of accounts, approving mapping changes, trueing labor at the payroll cycle, and closing the period. What goes away is the re-keying and the chasing of location managers for exports. Your controller also stops being the first person in the group to learn a location had a bad week.
Related
- What is prime cost in a restaurant? →Definition, what counts and what doesn't.
- What is food cost variance? →Product half, split into theoretical and actual.
- How to connect Toast to QuickBooks →Sales-journal integration this page assumes as step one.
- QuickBooks Online and Xero APIs: what a real integration involves →Ledger side of the pipeline.
- Software for restaurants →What we build around the POS you already run.
- API integration →Our service behind the nightly pulls.
- Business intelligence →The reporting layer on top of the pipeline.
