Power BI reports, with their screen-friendly format, easy editing and strong visuals, have become the gold standard for business intelligence. But what happens when a report must be printed? Maybe it’s a board meeting where hard copies are table stakes. Maybe you need to slice your data across multiple departments. Maybe that simple matrix that looked great in pixels doesn’t look so hot on eight and a half by eleven. Suddenly those visuals become a clumped, stretched, unpredictable mess. Nothing says “we chose the wrong tool for the job” like a ten-page document that reminds your executives more of a mad scientist’s scribblings than the business they’re supposed to be running.
You’ve probably run into this before: page breaks splitting mid-row, tables split across pages, charts cut in half.
The right tool for the job is a Power BI paginated report, and it’s not as difficult as you might think. Paginated reports can use your existing semantic model, and building them requires one additional free tool: Report Builder. (Or no tool at all, if you start in the browser — though you’ll have limited functionality.)
Paginated Reports 101 — a five-part series
- When to use a paginated report (you are here)
- Using a semantic model as your data source
- Building your paginated report dataset
- Adding parameters and filters
- Getting print and view ready
Parts 2 through 5 are hands-on. Download the sample files and build the model before you start Part 2, and every figure in the series will match what’s on your screen.
What a paginated report actually is
Paginated reports came to Power BI from SQL Server Reporting Services, and they exist for one purpose: precise, repeatable output from a defined set of data. Each one is saved as an .rdl file — Report Definition Language — and that name is the most useful thing about it.
If you’re used to Power BI Desktop, you’re used to a file that can carry data. Import a few tables into a .pbix and the data rides along inside it. An .rdl carries none. It is purely a set of instructions: fetch this, arrange it like this, break the pages here. The data arrives when somebody runs the report, and not before. It’s a recipe, not a meal.
The comparison worth keeping
Early in a construction project, everyone crowds around a whiteboard and moves the loading dock six times in an afternoon. That is the correct way to work at that stage. It’s fluid, argumentative and deliberately unfinished, and nobody expects the whiteboard to be right. That’s the point. Different people want to see the data structured differently, and few of them want to see it the same way twice.
What eventually goes to contractors is a stamped drawing: dimensioned, titled, revision-numbered and identical for every trade who pulls it off the printer. It isn’t interactive and was never meant to be. Its entire value is that it says the same thing to everyone, every time, including six months from now.
Power BI reports are the whiteboard. Paginated reports are the stamped drawing. Nobody has ever argued that stamped drawings are obsolete because whiteboards exist.
Operational, not exploratory
Power BI analytical reports are built to be interactive and to work across a range of screen sizes, which makes for a good online experience. For most people who use one, the best part is the sheer number of ways they can slice, dice and drill. They get to see what happened and go digging into why.
Paginated reports are a just-the-facts tool. They do let people make selections — called parameters, the subject of Part 4 — but the choices are deliberate and finite, and you control them at the time of writing. If an analytical report exists to help someone explore the why, a paginated report is built to state the what, the same way, for everyone who opens it.
That sounds like a downgrade until the month you need three hundred invoices to come out identically.
The two side by side
| Power BI report (.pbix) | Paginated report (.rdl) | |
|---|---|---|
| Authored in | Power BI Desktop, or the Power BI service | Power BI Report Builder, or the Power BI service |
| Holds data? | Yes — the semantic model can store data, depending on the connection model | No — data is fetched when the report runs |
| Layout | Canvas-based and responsive, sized for screens | Fixed and measured in dimensions, sized for pages |
| Long tables | Scroll inside a visual; totals summarize | Flow across as many pages as the data needs |
| Interactivity | Cross-filtering, slicers, drill through, bookmarks | Parameters defined by the writer, with some control by the viewer |
| Export fidelity | Best effort; layout can shift on the way out | Exact, by design: PDF, Excel, Word, CSV and more |
| Best at | Exploration, explanation, presentation | Reproducible operational output |
When to reach for a paginated report
Three situations. In our experience the third is the one people miss.
1. The report needs to be precisely defined and structured, not interacted with. Core financial statements are the obvious case. An income statement, a balance sheet and a statement of cash flows all have an expected format, and expected format is what paginated reports are good at.
2. Many versions of the same report go to different people based on role. A budget-to-actuals report emailed to each department head on the first of the month. A standard slide of key figures that every employee includes in their annual review. An invoice template printed and mailed to each customer. One definition, hundreds of outputs.
3. The report has to work on paper and on screen, and exploring it wouldn’t help anyway. Operational reports you send to banks, auditors, insurers or regulators. Internal lists — employees by department, output by plant — where a clean table is the whole ask and anything else is in the way. These can technically be built as analytical reports, but they make more sense as paginated ones, because the recipient needs a specific PDF or Excel structure and needs it to look the same every month.
A great many corporate reports live in that third bucket. You mostly won’t know about them unless you work in the department that maintains them.
Isn’t this a dying technology?
We field this objection on most engagements where paginated reports come up, and it deserves a direct answer. The release history contradicts it.
The current release is Power BI Report Builder. Microsoft added Power Query to Report Builder and took it to general availability in September 2024, which opened up hundreds of connectors and let you shape data inside the report itself. In September 2025 the default map provider moved from Bing Maps to Azure Maps. Browser-based authoring shipped in the Power BI service. Microsoft’s own documentation still describes Report Builder as the authoring tool for paginated reports, and the change log is public.
A tool that gains new data connectivity, new mapping infrastructure and an entirely new authoring surface across two years is not being wound down. Paginated reports get less marketing attention than analytical reports. That is a very different thing from getting less investment.
Two ways to get started
This is the part that has changed most since 2023, and it’s good news if you’ve been putting it off.
Start in the browser. You can now create a paginated report directly in the Power BI service, though without the full feature set of Report Builder. Microsoft still describes parts of this experience as preview. It’s the fastest way to find out whether a paginated report solves your problem.
Then move to Report Builder. It’s a free download and it’s where the precise control lives: page setup, whitespace behavior, repeating headers, and the properties that decide whether your report prints cleanly. Everything from Part 2 onward assumes you’re working there. It is a Windows application, so on macOS or Linux you’ll need a Windows VM.
What it costs
Report Builder is free to download and needs no license to install. Beyond that, paginated reports carry the same license requirements as standard Power BI reports:
- A free license lets you publish to My Workspace.
- A Pro or Premium Per User license lets you publish to shared workspaces. You’ll also need at least the Contributor role in that workspace, and Build permission on the semantic model you’re connecting to. That last one is the most common reason a first attempt fails.
- For colleagues on a free license to view what you publish, the content needs to sit on Fabric F64 or higher, or Premium P1 or higher.
On that last point: Microsoft is retiring the per-capacity Power BI Premium P SKUs in favor of Fabric capacity. They came off the purchase flow for new customers in July 2024 and renewals stopped soon after. If you’re planning capacity around paginated reports, plan around F SKUs. Check the current Fabric licensing guide and the paginated reports FAQ before you commit to numbers. This is the area that changes fastest.
Coming from SQL Server Reporting Services
If you already have an SSRS estate, you are not starting from scratch. You’re migrating. Paginated reports authored for SSRS 2016 and later, or for Power BI Report Server, are compatible with the Power BI service, and Report Builder ships an RDL Migration Tool in its installation directory to help move reports across. Not every feature comes along, so check the limitations before you commit to a date, but the path exists and it’s supported.
Where this goes next
If you’ve read this far and recognized one of your own reports, you probably don’t need to rebuild your data. If you’ve already built an analytical report in Power BI Desktop, the semantic model underneath it can feed a paginated report too.
The tricky part is that what works in Power BI Desktop does not always translate to Power BI Report Builder. Several things share a name and behave completely differently. That’s where the next post starts.
Next in this series — Part 2 How to Use a Power BI Semantic Model as Your Paginated Report’s Data Source