Sharing a Power BI report inside your own company is simple. Anyone on the same Microsoft 365 tenant, with a Power BI license, can open it. The moment you want a client to see one of those reports, the question gets harder, and it's a question about money, not about buttons. A fundraising consultancy that builds donor-analysis and campaign reports for its clients ran into this and spent hours in Microsoft documentation before deciding to ask for help. That research dead end is common, because the three ways to do this look similar and cost very differently.
Here's the thing worth settling before anyone touches a setting: how many outside people need access, and is this a one-off or something several of your people will do for many clients? That answer decides which route makes sense.
Guest Access
You can invite an external person into your Microsoft 365 tenant as a guest. That works for a Word file or a Teams chat, where a guest gets a limited security profile and can see the one thing you shared. Power BI is different. To view a report the way another user in your organization sees it, a guest generally needs a Power BI license within your tenant. So guest access to a report isn't free the way sharing a document is.
Guest access fits a narrow case: one person, for a short window, who needs to click around a report once. Give them a guest account for a week and move on. As a standing arrangement for many clients, it turns clumsy fast, and it's the wrong tool for that job.
Per-User Licensing
The next option is to buy each external viewer a Power BI license. It works, and it's clean from a permissions standpoint. It also scales linearly with people, which is exactly the problem. If you're serving a handful of clients with one or two contacts each, the per-seat math might be fine. If you want an entire client's team, or many clients, looking at reports, you're buying a license for every person who opens one.
Embedded Reports for External Viewers
Microsoft's own design for this is to publish the report so it's reachable from a standard internet connection, outside your domain, through a URL with security in front of it. This is not the same as making a report public on the open web. Access is still controlled. What changes is that the report lives on a component built to serve viewers who aren't inside your tenant, so those viewers don't each need a Power BI license in your organization.
That's the decision point. Setting this up is a defined piece of work up front. After that, whether 10 people or a thousand view the reports doesn't change the cost, because you're not paying per viewer. For an organization where several people will publish reports to many clients over time, that flips the economics against per-user licensing quickly.
Is external viewing a rare one-off, or a repeated pattern across your clients? A one-off leans toward guest access. A repeated pattern leans toward an embedded, externally reachable report, where cost is fixed regardless of viewer count.
When Clients Send Data Back
There's a second requirement hiding behind the first, and it's the one that changes the design. Read-only viewing is one thing: the client clicks around a report, the way you'd click through a web analytics dashboard. Collecting data back from those same clients is a different animal. A Power BI report on its own doesn't capture input.
The fundraising firm wanted both. Their campaign managers work a prospect list off donor records for years, projecting next actions, ask amounts, and what a donor actually gives. The goal was to let the client update their side (who they called, who agreed to a gift) in the same place they view the campaign report, so it's one less system for the client to track.
The natural instinct is to embed a data-entry app inside the report. In practice it tends to run the other way: you publish a Power App as the web app, and the report is embedded inside the app. The app collects the input; the report is the visual reference the client sees while they work. Same single destination for the client, but the piece doing the collecting sits at the front.
Building that requires the Power Platform (Power Apps, and often Dataverse behind it), which not every Microsoft 365 subscription includes by default. If you're building a Power App and prompts about Dataverse or Fabric keep surfacing, that's the platform telling you the app needs storage and services that may sit outside your current licensing. Worth confirming what you already own before you commit to a design.
Two separate decisions live in this, and it helps to keep them apart. First, how outside people get to see a report, which is a licensing choice with real cost attached. Second, whether you also need to collect data from them, which pushes you from a report into an app with a report inside it. Sizing either one depends on your current subscription and how many people are involved, so it's worth pinning down what your licensing already covers before you budget for the rest.