Toast to Power BI, done for you
Net sales, menu mix, labor cost percentage by daypart and comps across every location — extracted from Toast on a schedule, landed in a store you own, and modelled by a senior US-based engineer so the whole group fits on one page instead of one restaurant at a time.
Representative dashboard — sample data
Where Toast reporting runs out
Toast reports the restaurant in front of you extremely well. What it is not built to do is hold your entire group, several years deep, beside labor, purchases and a budget that live in other systems. Toast’s own support documentation is candid about the ceiling: comparing multiple locations across a wide date range in Sales Analytics can cause the report to time out, and the advice is to shorten the date range or select fewer locations.
That is exactly the question a multi-unit operator needs answered every Monday. This page is about the plumbing that answers it — getting order, menu and labor data out of Toast on a schedule, keeping it somewhere you own, and modelling locations, dayparts and comparable stores properly. For the operating narrative around those numbers — prime cost, the weekly ops meeting, what a good restaurant week looks like — our Power BI restaurant sales dashboard page is the industry-level companion to this one.
What we build from Toast
Buy a block of prepaid Flex hours and, if you’re unhappy within the first 4 hours, we refund you in full — no questions asked. Hours are deducted only for work you’ve reviewed and approved, there’s no project minimum, and your banked hours never expire.
What the build covers
None of them are chart choices. Every one of them is where an in-house attempt at this tends to stall.
Toast API access is arranged with Toast rather than switched on from a settings page, and export delivery has to be set up per restaurant. We tell you exactly what to request, and we design around whichever route your group can actually approve.
Late-night sales belong to the night that earned them. We model on Toast’s business date so a 1:15am check lands on the right operating day and every daypart, weekday and comp comparison stops drifting.
Orders are pulled once and retained in a store you own, so a two-year trend does not depend on re-reading Toast every morning — and a menu item renamed last spring still reconciles to what it sold as.
Each restaurant carries its own identifier in Toast. We turn that list into a real dimension — region, market, store group, concept, open and close dates — so one slicer drives every page and roll-ups are not typed by hand.
Gross sales, discounts, comps, voids, refunds, service charges and tax all have to be settled into one agreed definition of net sales — written down, applied everywhere, and tied back to a Toast report your accountant already trusts.
A morning refresh timed after close, row-level security so a general manager opens the report on their own restaurant, and failures fixed by us out of your banked hours rather than by whoever built it.
Through an extraction you schedule, because Power BI Desktop ships no first-party Toast connector and there is no supported way to point it at the platform’s database. In practice there are two workable routes and one shortcut. The API route reads orders, menus, labor and configuration for each restaurant, identified by the restaurant’s own identifier in Toast, and access is arranged with Toast rather than self-issued from a settings screen. The export route has Toast deliver scheduled report files to storage you control, which is often the faster path to a first dashboard when API approval will take weeks.
The shortcut is worth asking about first: plenty of groups already send Toast data somewhere — an accounting integration, a franchise data pool, a warehouse an internal developer set up. If a clean copy already exists, we model that and skip the extraction entirely.
| Route | What it gives you | When we use it |
|---|---|---|
| Toast APIs (orders, menus, labor, configuration) | Order, check and line-item detail with modifiers, discounts, voids and service charges, plus menu structure and shift and time-entry data, per restaurant and per business date | The default where access is approved — it is the only route that gives you the selection-level grain menu mix and daypart analysis actually need |
| Scheduled Toast report exports | Saved report output delivered on a schedule to storage you control, at whatever grain the report itself carries | Where API access is not approved in time, or a figure your team already reconciles exists only inside an established Toast report |
| An existing warehouse or integration copy | Toast data already landed into Azure SQL, Microsoft Fabric, Snowflake or a partner platform by someone else | Always our first question — faster to refresh, cheaper to model, and already joinable to accounting |
| Manual exports from the Toast back end | Ad-hoc CSV downloads per restaurant | Only to validate the model during build, or for a one-off backfill — never as the thing that runs every morning |
| Non-Toast systems alongside it | Scheduling and payroll hours, purchase invoices, the general ledger, budgets and franchise targets | Whenever the question is prime cost or profit rather than sales — labor and COGS do not live in the POS |
Whichever route you land on, we build it as a scheduled job that writes into your own store rather than as a chain of Power Query steps calling an API on every refresh. That pattern is fragile for a reason worth naming: an address assembled by string concatenation in Power Query is what the service classifies as a dynamic data source, and it will refuse to refresh it on a schedule even though it worked in Desktop. The supported shape is a constant base address with everything variable passed as relative path and query parameters, which the Power Query Web connector (opens in new tab) handles directly.
Because the POS is built to run service and a dashboard asks historical questions. Toast answers “what happened at this restaurant on this business date” efficiently; a group dashboard asks for every location, every daypart, two years back, on one page. Re-reading that range on every refresh is slow at best and throttled at worst, and it leaves your history hostage to a system whose menus, locations and staff keep changing underneath it.
A modest landing store — Azure SQL, a Fabric lakehouse, or files in your own storage account — fixes all of that at once. It also gives you the one thing the POS cannot: a stable copy of what was true then. When a menu item is renamed, a location is remodelled into a new concept, or a store group is reorganised mid-year, the retained extract still reconciles.
| Toast concept | What it carries | Role in the model |
|---|---|---|
| Restaurant | One identifier per physical location, with its own menus, time zone and configuration | Location dimension — extended with region, market, store group, concept, and open, close and remodel dates |
| Order | The visit: opened and closed timestamps, business date, dining option, revenue center and server | Sets the daypart, service mode and guest-count grain — and carries the business date every calendar relationship keys on |
| Check | Amounts, discounts, service charges, tax and tender for the portion of an order that is paid | Sales fact header — where gross becomes net once discounts, comps, voids and refunds are applied |
| Selection (line item) | The menu item sold, its quantity and price, its modifiers, and whether it was voided or comped | Menu-mix fact — the grain that makes item-level attachment, modifier revenue and category mix answerable |
| Menu, group and item | The menu structure a selection was sold from, including category and price | Menu dimension, versioned so a renamed or repriced item still ties to what it sold as last year |
| Shifts and time entries | Scheduled and clocked hours by job and restaurant, where the labor module is in use | Labor fact — what turns labor cost percentage and sales per labor hour into measures rather than estimates |
| Business date | The operating day a check belongs to, independent of the clock date it closed on | The key to the date table — without it, late-night revenue splits across two days and every comparison drifts |
The shape follows Microsoft’s star schema modeling guidance (opens in new tab), and the general craft is covered on our star schema guide. The detail that causes most rework is the discount, comp and void configuration. Every group has its own reason codes, several usually mean the same thing to the accountant, and one or two behave differently from how they are named. We map them with your controller during scoping and keep the mapping as data, so a new promo code next quarter is a row to add rather than a query to reopen.
The set below is what multi-unit operators consistently assemble by hand from Toast exports. Each one embeds a definition someone has to agree with before the number means anything, so we write them as documented DAX measures over the star schema and a proper restaurant calendar, then validate every total against a Toast report your team already runs.
| Measure | How it is defined | Why it is written this way |
|---|---|---|
| Net sales | Gross sales less discounts, comps, voids and refunds, with tax and service charges handled per your agreed treatment | One definition, written down and applied on every page — the alternative is two departments quoting different sales figures in the same meeting |
| Comp-store sales | Net sales for locations open through both periods being compared, against the same period last year | Keeps a new opening from being read as growth, and survives a closure without anyone re-filtering the report by hand |
| Average check and guest count | Net sales over checks, and over guests where guest counts are captured, by daypart and dining option | Separates a busier week from a bigger-ticket week — two very different operating stories with the same sales line |
| Menu mix | Share of items sold and of net sales by category and item, with modifier revenue attributed to the item that carried it | Mix at the selection grain is what makes a menu decision defensible; a category total alone hides the item doing the work |
| Labor cost percentage | Labor cost over net sales, by restaurant, daypart and day part of week, from hours and rates you supply | Read at daypart level rather than weekly, because that is the grain a schedule is actually changed at |
| Sales per labor hour | Net sales over hours worked for the same window and location | Comparable between a 60-seat room and a 200-seat one, where raw labor dollars only ever flag the biggest restaurant |
| Comps, voids and discounts | Value and rate of each, by reason code, restaurant, server and daypart | A rate by reason code turns an uncomfortable number into a specific, checkable conversation instead of a suspicion |
| Daypart and weekday trend | Net sales and check counts by daypart across the business-date calendar, indexed to a trailing average | Restaurant weeks are not calendar weeks, and a Tuesday only means something next to other Tuesdays |
Comps by location is usually the measure that changes a conversation. Arithmetically it is trivial; organisationally it is uncomfortable, because a group-wide comp rate that looks tolerable frequently resolves into two restaurants carrying nearly all of it. The discipline that makes it defensible — one date table on the business date, conformed dimensions, measures rather than calculated columns — is the same craft described on our Power BI data modeling and DAX page.
Toast ships a genuinely capable reporting layer, and for questions inside one restaurant, in Toast’s shape of the data, it is the right tool. The requests that reach us cross a boundary: the whole group at once, several years of it, or numbers that only mean something once labor, purchases and the ledger sit beside the sales.
| What you are trying to do | Reporting inside Toast | Custom Power BI model |
|---|---|---|
| Check yesterday at one restaurant | Its core strength — live, in context, already secured | Possible, but not a reason to build a model |
| Compare every location over a long date range | Toast documents that this can time out in Sales Analytics, advising fewer locations or a shorter range | Pre-aggregated in your own tenant, so the whole group and multiple years open in seconds |
| Prime cost: sales, labor and COGS together | Purchases and the ledger live outside the POS | Invoices and accounting modelled as further facts against the same location and calendar |
| Comp-store sales across openings and closures | Needs the comparable set re-filtered by hand each time | A comparable-location rule built into the measure, applied identically every week |
| One pack for owners, operators and the bank | Needs each viewer to hold a Toast login and know where to look | One published report, secured by location, in tools they already use |
| Where the logic lives | Inside the vendor’s reporting layer | In a model file in your own tenant, which you own outright |
The practical answer is usually both. Keep Toast reporting for running service, and build the model for the numbers that decide menus, schedules and which location gets attention this quarter.
The model is published to your Power BI workspace and refreshed on a cadence that matches how restaurants actually close — typically a single morning refresh after the last business date is settled, since a closed day does not change — inside Microsoft’s documented data refresh limits (opens in new tab). Where several years of orders have accumulated, we configure incremental refresh (opens in new tab) so each morning re-reads only a recent window of business dates.
Visibility is handled with row-level security in the Power BI service (opens in new tab), driven from a mapping of viewers to locations and evaluated against the location hierarchy, so a general manager opens the report on their own restaurant, a regional lead sees their market, and ownership sees the group. Our guide to Power BI row-level security setup walks through the same configuration step by step. Where units are independently owned, that separation is not a nicety — the structure for it is covered on our Power BI dashboards for franchise owners page.
Prepaid Flex hours that never expire: Starter 20 hours at $125/hr ($2,500), Growth 40 hours at $115/hr ($4,600), Power 80 hours at $100/hr ($8,000), with hourly work from $100/hour on the largest block. A first build covering net sales, menu mix and labor cost percentage by location from an approved Toast connection usually fits a Starter block. Adding purchases and COGS for full prime cost, budget comparison, or a backfill of several years of orders typically needs Growth, because agreeing comp, void and net-sales definitions across operations and accounting takes discussion as well as development.
Most tasks ship within 3–5 business days of scope approval, and you get a scope and hours estimate before anything starts. Our guide to Power BI dashboard development cost covers what moves the number, how prepaid Flex hours work explains the model in full, and custom Power BI dashboard development describes the wider service this build sits inside.
Restaurant groups running Toast across enough locations that comparing them is a weekly chore — usually somewhere between three and thirty restaurants, with enough history to trend and no dedicated analyst. Owners, multi-unit operators and the finance leads who own the P&L are the people who get in touch, typically at the point where someone exports the same reports every Monday morning.
Writing back to Toast is out of scope: this is a read-only reporting build, and menu and configuration changes belong in the POS. If your questions are about the operating narrative rather than the data plumbing, start at Power BI for restaurants. If accounting is the harder half of the problem, the ledger side is covered on our QuickBooks Power BI dashboard page. And if your restaurants sell online as much as in the dining room, the e-commerce side of that is on Shopify Power BI dashboards. Contact is form-only — send your request and we’ll reply with a scope estimate.
business days, typical
hours, never expire
own everything
A first Toast build usually fits inside one Flex block, and hours deduct only for work you approve. See Flex pricing →
How it works
We work out which extraction Toast will approve for your group, and agree the definitions in parallel — net sales, which reason codes count as comps, how dayparts are cut, what makes a location comparable, and how far back usable history goes. You get a scope and hours estimate before any work begins.
A senior US-based engineer builds the scheduled extraction, lands orders, menus and labor in a store you own, flattens the location hierarchy, builds the star schema on Toast’s business date, and writes the DAX — validating every total against a Toast report your team already runs.
Published to your workspace with scheduled or incremental refresh, row-level security so each manager sees only their restaurants, and documentation you keep. We maintain it from your banked hours.
Representative perspective
Our comp rate looked fine for the group. Split by restaurant and reason code, two rooms were carrying most of it, and neither had ever come up on a Monday call.Operations director, multi-unit restaurant group
Representative perspective
Pulling one location worked on my laptop. Pulling twelve every morning, and keeping last year’s menu straight, was the part we were never going to finish ourselves.Finance lead, regional restaurant operator
Tell us how many restaurants you run in Toast, which reports your team exports today, and what ownership asks for each Monday. We’ll confirm the extraction route, scope the task, and tell you the hours before anything starts — no project minimums, no obligation.
FAQ
Power BI ships no first-party Toast connector, so the data leaves Toast one of two ways: through Toast’s APIs, where access is arranged with Toast rather than generated in a settings screen, or through scheduled report exports delivered to storage you control. Either route lands the data in a store Power BI can refresh from on a schedule.
Because the APIs answer operational questions one restaurant and one business date at a time, while a dashboard asks for two years across every location at once. Pulling that range on every refresh is slow, fragile and easy to throttle. A landing store you own turns the refresh into a fast local read and keeps history that Toast reporting no longer shows the same way.
It is the operating day a check belongs to rather than the clock date it closed on. A bar ringing sales at 1:15am belongs to the night before, not to the new calendar day. Modelling on the timestamp instead of the business date splits late-night revenue across two days and quietly breaks every daypart, weekday and comp-store comparison.
That is the main reason groups commission one. Toast’s own support documentation notes that comparing multiple locations across a wide date range in Sales Analytics can cause the report to time out, so users are told to narrow the dates or drop locations. A pre-aggregated model in your own tenant answers the whole-group question without that trade-off.
With an explicit comparable-location rule rather than a filter someone remembers to apply. Each location carries an open date, a close date and any remodel or conversion dates, and the comp measure includes only locations open through both periods being compared. New units are reported separately so growth is never mistaken for same-store performance.
No. We are an independent US-based Power BI consultancy with no Toast partnership to claim and no prebuilt connector to sell. We build against whatever route your restaurants can approve, using credentials your team requests and owns, and everything we produce is published into your own Power BI workspace.
The industry-level companion to this page is Power BI for restaurants, which covers prime cost and the weekly operating narrative rather than the data plumbing. Networks of independently owned units should read Power BI dashboards for franchise owners, where royalty accrual and per-owner data separation are the real problem. Operators on a different terminal want the Square Power BI dashboard build instead, where the work is the Orders-versus-Payments-versus-Reporting API split and unstacking Square’s gross sales, net sales and net total rather than Toast’s business date. If inventory, promotions and multi-channel selling matter more than covers and dayparts, Power BI for retail is the closer fit, with Shopify Power BI dashboards and Power BI dashboards for e-commerce brands covering the online side. Accounting joins the picture through the QuickBooks Power BI dashboard build, and what a Power BI dashboard costs to develop sets expectations before you commit. Every task is scoped before work begins from your prepaid block of senior-led hours — no project minimums, no change-order surprises, and hours are deducted only for work you approve.
Book a free demo
Tell us the task. We scope it, you approve, and a senior consultant delivers — typically in 3–5 business days. Prepaid hours that never expire.
The fastest way to reach us is the form — tell us the task and we'll reply within one business day.