Every unit on one definition
Sales, transactions, and average ticket calculated identically for every location, so a unit's rank in the network means something instead of reflecting whose spreadsheet it came from.
Multi-unit franchise reporting
Power BI Dashboards for Franchise Owners Running Multiple Units
Same-store sales compared across every owner on one definition, royalty and ad-fund accruals by unit, and a head-office roll-up where each franchisee signs in and sees only their own locations. Built by a senior US-based engineer, typically in 3–5 business days.
Representative dashboard — sample data
One network, many balance sheets
Everyone needs the same numbers — and a different set of rows
A franchise network is not one company reporting on several sites. It is a franchisor and a set of independent owners who each hold part of the network, and reporting has to respect that: the owner of four units wants those four compared against the system average, the area developer wants their territory, and head office wants every unit ranked on one definition — all from the same model, none of them seeing each other's books.
That is the structural problem this page exists to solve. We build one semantic model over unit-level sales, franchisee-reported results, and your franchise agreements, then use row-level security so the report knows who is signed in. Head office gets the network roll-up; each franchise owner gets their own units and the benchmark, and nothing else.
What we build for franchise networks
- Same-store sales by owner
- Royalty & ad-fund accruals
- Per-franchisee row-level security
- Head-office network roll-up
- Unit ranking & quartiles
- New-unit pipeline & ramp
- Average ticket & transactions
Try us risk-free for 4 hours
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.
Why multi-unit operators call us
Reporting shaped like a franchise system, not a single store
You send the request; a senior engineer models units, owners, and agreements the way your network is actually structured.
Each owner sees only their units
Row-level security maps owners to the units they hold, so one report serves the whole network without any franchisee seeing another's numbers — and without a monthly file emailed to each of them.
Royalty and ad fund, accrued
Agreement rates applied to reported gross sales, so what each unit owes in royalty and marketing-fund contribution accrues as it is earned and sits beside what was actually collected.
Same-store sales that survive growth
A comparable base driven by each unit's opening date, so a wave of new openings lifts total sales without quietly inflating the comp number head office reports.
The new-unit pipeline in view
Signed agreements, sites in build, and openings tracked through to the ramp curve, so development targets and net unit growth stop living in a separate spreadsheet.
Benchmarks franchisees will act on
Each owner sees their units against the anonymised network median and quartile, which is the version of a league table people use to improve rather than dispute.
What makes franchise reporting different?
Ownership. In a company-owned chain every location shares one general ledger and one set of permissions, so a multi-location report is mostly a filter. In a franchise system the units belong to separate legal entities, some owners hold one unit and some hold twelve, the franchisor sees the network but not necessarily each owner's full P&L, and the numbers head office relies on are partly self-reported. A model that ignores that structure either leaks data between owners or forces someone to hand-build a deck per franchisee every month.
So the ownership dimension is the backbone of the build: a unit table, an owner table, an effective-dated link between them for transfers and acquisitions, and the agreement terms that decide what each unit owes. Everything else — roll-ups, comps, royalty accruals, security — hangs off that. If you run a single-concept, single-owner operation instead, the restaurant and retail versions of this work are a better fit: see Power BI restaurant sales dashboards for menu mix, labor cost % and prime cost, or Power BI for retail for sell-through, basket and inventory reporting.
Who sees what across the network
One report, several audiences, each filtered at the model level. This is the access map we usually start from and then adjust to your franchise agreements — the rules live in the semantic model, so they apply the same way in the browser, the mobile app, and any export.
| Audience | Rows they see | What they use it for |
|---|---|---|
| Single-unit franchisee | Their own unit, plus anonymised network benchmarks | Trading against last year and against the system median |
| Multi-unit franchise owner | Every unit they hold, compared side by side | Which of their locations is lagging, and by how much |
| Area developer or regional manager | All units inside their territory, across owners | Territory performance and which owners need support |
| Franchisor finance | Every unit, plus royalty and ad-fund accrual and collection | What is earned, what is banked, what is overdue |
| Franchisor development | Pipeline, openings, closures, and ramp by cohort | Net unit growth against the development plan |
Power BI enforces this with row-level security: roles hold a DAX filter, and a mapping table ties each signed-in user to the units they may see. Our guide to Power BI row-level security setup walks through the static and dynamic patterns, and Microsoft documents the underlying feature in Row-level security with Power BI (opens in new tab). One caveat worth stating plainly: RLS restricts viewers, not workspace editors, so franchisee access is granted as Viewer — we set that up with you.
Where do franchise numbers actually come from?
Rarely from one place. Unit sales usually come from POS systems, which in a franchised network are often not all the same brand or version — where the units run Toast, the API and scheduled-export routes are set out on our Toast POS Power BI dashboard page. Royalty terms come from the franchise agreements. Unit-level profit is frequently self-reported by owners on a monthly statement. Development data lives in a spreadsheet on someone's desk. The build's real work is reconciling those cadences honestly.
| Metric | Typical source | What makes it awkward |
|---|---|---|
| Gross sales by unit | POS at each location, via API or scheduled export | Owners on different POS platforms and plans |
| Royalty and ad-fund due | Agreement rates applied to reported gross sales | Rates, caps, and start dates differ by cohort |
| Royalty collected | Accounting system or payment processor | Reconciling collections back to the unit that earned them |
| Same-store sales | POS sales joined to an opening-date table | Deciding when a unit joins the comparable base |
| Unit-level P&L | Franchisee-submitted statements or their ledger | Monthly cadence, inconsistent chart of accounts |
| New-unit pipeline | Development tracker, CRM, or spreadsheet | Stage names that mean different things to different people |
We confirm the exact connection method for each system in the scope estimate before any hours are used — POS platforms differ a lot in what they expose, and some plans gate API access entirely. Once connected, we configure scheduled data refresh in Power BI (opens in new tab) so the network numbers are current each morning. Where a unit only reports monthly, the dashboard says so rather than mixing a monthly figure into a daily trend.
How do you compare owners fairly?
By fixing the definitions before anyone argues about the ranking. Same-store sales needs an explicit comparable base — a unit joins it only once it has a full matching prior-year period, so openings drive total growth and not comp growth. Average ticket needs one transaction definition across every POS. And a like-for-like ranking usually needs a cohort split, because a unit in its first year is not comparable to one in its tenth.
Networks define these differently, and the franchise agreement sometimes settles it for you. We implement your rule rather than a generic one, write it into the model as a documented measure, and show the definition on the page so a franchisee reading the number knows what it counts.
What about Power BI licensing across franchisees?
Worth settling early, because it drives the running cost more than the build does. Either every viewer holds a Power BI Pro license, or the workspace sits on a Fabric capacity large enough for free users to view its content — Microsoft sets out the difference in its Power BI licensing documentation (opens in new tab). Which is cheaper depends on how many franchisees will actually read the report. We cost both against Microsoft's current pricing during scoping, and if the answer is an embedded portal instead, our Power BI embedded analytics page covers that route.
What does it cost, and how fast?
You buy prepaid Flex hours that never expire: Starter 20h at $125/hr ($2,500), Growth 40h at $115/hr ($4,600), or Power 80h at $100/hr ($8,000). A first build — network sales roll-up, same-store sales, and per-franchisee row-level security — typically fits inside one block, with royalty accrual and the development pipeline added from the same hours afterwards. Most builds ship in 3–5 business days once you approve the scope estimate.
Traditional Power BI firms charge $175–250/hr, set project minimums, want $10K+ to start, let unused hours expire, and don't begin for 4–6 weeks. Flex Support is $100–125/hr, no minimums, banked hours that never expire, and a start this week. Hours deduct only for approved work. See how prepaid Flex hours work for the full comparison.
Who is this for?
Multi-unit franchisees, area developers, and franchisor finance and operations teams without an in-house analyst — in food service, fitness, home services, personal care, or any system where units are independently owned. The sweet spot is roughly ten to two hundred units: enough that a per-owner spreadsheet routine is a real monthly cost, not so many that you already employ a data team.
Adjacent needs are covered elsewhere on the site. Single-concept restaurant operators should start at Power BI for restaurants; store-level merchandising and inventory questions belong on Power BI for retail; if your units are leased properties whose occupancy and rent roll matter as much as their sales, see Power BI for property management; multi-rooftop auto dealer groups with their own gross-per-unit and F&I metrics should start at Power BI consultant for car dealerships; and corporate or franchised animal hospital groups, whose unit economics run on average client transaction and production per doctor, are covered on Power BI dashboards for veterinary clinics. Where the units are licensed cannabis storefronts, traceability reconciliation and the 280E cost-of-goods split come before any network roll-up — that build is on Power BI dashboards for cannabis dispensaries. Contact is form-only — send your request and we'll reply with a scope estimate.
Dashboards we build for franchise networks
- Network roll-up & unit ranking
- Same-store sales by owner
- Royalty & ad-fund accrual
- Per-franchisee row-level security
- New-unit pipeline & ramp
3–5
business days, typical
Prepaid
hours, never expire
You
own everything
A first build usually fits inside one Flex block, and hours deduct only for work you approve. See Flex pricing →
How it works
From unit exports to a network everyone can read
- 1
Send your request
Tell us your unit count, which POS platforms your owners run, how royalty is calculated, and who should see what. We reply with a scope and hours estimate — including the confirmed connection method — before any work begins.
- 2
We model & build
A senior US-based engineer builds the unit, owner, and agreement tables, writes the same-store sales and royalty measures, configures row-level security roles, and reconciles the network total back to your source systems — typically 3–5 business days.
- 3
Publish & maintain
We publish to your workspace, test each role as a real franchisee before anyone gets access, set scheduled refresh, and hand over the model and credentials. You own everything; we keep it healthy from your banked hours.
Representative perspective
We held eleven units and every month was a rebuild of the same spreadsheet. Having our locations ranked against the system on definitions nobody could argue with changed which stores we actually visit.Multi-unit franchise owner, quick-service brand
Representative perspective
Royalty was reconciled after the fact and comp sales meant something different in every deck. One model with security per owner ended both arguments in the same quarter.Finance lead, franchisor head office
See your whole network on one page — safely
Tell us your unit count, your POS systems, and who needs to see what. We'll scope the task and tell you the hours before any work begins — drawn from prepaid Flex hours that never expire, with no project minimums and no obligation.
FAQ
Questions from franchisors and multi-unit operators
Yes. We use Power BI row-level security with a mapping table of owner to unit, so a franchisee signing in sees only the units they hold, while head office sees the whole network in the same report. One model, one set of definitions, and no separate file emailed to each owner every month.
With an opening-date table and a comparable-base flag. A unit only enters the comp calculation once it has a full prior-year period to compare against, so a burst of new openings cannot flatter network growth. Networks define that window differently, so we implement your rule rather than assume one.
Yes. We apply the rates in your franchise agreements to reported gross sales, so royalty and ad-fund amounts accrue by unit and period, and compare them to what was actually collected. That turns an aged royalty receivable into a chart head office reviews weekly instead of a month-end reconciliation.
That is common and workable. We map each source to one shared set of columns, so a unit on a different POS still lands in the same sales and transaction measures. Where a franchisee only submits a monthly statement, that unit reports monthly and the dashboard labels it, rather than silently mixing cadences.
It depends how the workspace is hosted. Either each viewer holds a Power BI Pro license, or the workspace sits on a Fabric capacity large enough that free users can view it. Which is cheaper turns on how many franchisees read the report, and we cost both against Microsoft's current licensing before you commit.
Book a free demo
Get senior Power BI help, on demand
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.
- Prepaid hours from $100/hour — and they never expire
- Senior-led delivery — 20+ years on the Microsoft platform
- Typical 3–5 business day turnaround
- Full refund if you’re unhappy in your first 4 hours
The fastest way to reach us is the form — tell us the task and we'll reply within one business day.