There's a moment on most BI projects where someone asks, a little sheepishly, for something the dashboard can't give them: an invoice they can print, a twelve-page account statement that has to look exactly right, a data extract the finance team can hand to an auditor without apology. And there's a moment, right after, where the modern-BI purist in the room sighs and says the words "paginated report" as if reaching for a tool they'd hoped to have retired. I used to be that purist. A few months back at a retailer with some genuinely old-fashioned reporting needs, I stopped being — and I want to make the unfashionable case that paginated reports are still, in 2022, absolutely worth it, for the specific jobs they're built for.
What a paginated report actually is
Quick translation, because the name is unhelpful. A normal Power BI report is interactive — you click, filter, drill, and it reflows to fit your screen. A paginated report is the opposite philosophy: it's a fixed layout designed to fill printed pages precisely, flowing across as many pages as the data needs — hence "paginated." It descends directly from SQL Server Reporting Services, the RDL reports many of us built a decade ago, now living inside Power BI Premium and built in a separate tool, Power BI Report Builder.
If a normal Power BI report is a screen you explore, a paginated report is a document you produce. That distinction is the whole story of when to use which.
The jobs dashboards genuinely can't do
Here's where interactive reports fall down and paginated ones simply don't:
- Pixel-perfect print. When something has to land on A4 with the totals in the right box every single time — a payslip, an invoice, a regulatory return — you need control over the physical page that an interactive visual, built to reflow, will never give you. Paginated reports were designed for the printer, and it shows.
- Operational lists that run long. A table of 8,000 line items that has to be fully printable and readable across 200 pages is a paginated job. Try that in a dashboard table and you'll fight virtualisation and truncation the whole way; the paginated engine just keeps flowing rows onto pages.
- Every-row exports. Finance and audit teams routinely need all the rows, formatted, exportable to a tidy PDF or Excel on a schedule. Paginated reports export cleanly and completely, where a dashboard export is forever "the top N of what's on screen."
- Templated documents at volume. One report definition, run once per customer, to produce 4,000 individual statements — each pixel-perfect, each with its own data. That's a paginated pattern and nothing else in the stack does it as neatly.
Notice the through-line: none of these are analysis. They're production — the manufacture of documents. Dashboards are for the question "what's going on?"; paginated reports are for "produce this exact artefact, correctly, at scale."
Where they're the wrong tool
The honest counter-view, because I've also watched people reach for paginated reports out of habit and regret it:
- Anything exploratory. If the user's real need is to slice, filter, and follow their curiosity, a fixed-layout document is a straitjacket. Give them an interactive report.
- Anything that wants to be beautiful and on-screen. Paginated reports are functional, not elegant. For an executive dashboard meant to be read on a screen, the interactive tools win on every aesthetic axis.
- When Report Builder's separateness will cost you. You build paginated reports in a different tool, with a different (RDL) skill set and its own quirks. On a team with no institutional memory of SSRS, that learning curve is a real cost to weigh honestly — sometimes it's cheaper to solve the "printable" need another way than to take the team down the RDL road.
The decision, in one line each
So the rule I now give people is blunt:
- Does it need to be printed or exported exactly, every row, every time? → Paginated report.
- Does someone need to explore and ask follow-up questions? → Interactive report.
- Is it one document produced many times, one per entity? → Paginated report.
- Is it one screen many people glance at? → Interactive report.
Most organisations need both, and the mistake is treating them as competitors rather than a division of labour. The dashboards answer the questions; the paginated reports produce the documents; and a healthy BI estate has a clear-eyed sense of which of its outputs is which. At the retailer, the split turned out to be roughly the analysts living in interactive reports all day, and a quiet handful of paginated reports doing the unglamorous document work — the statements, the operational picking lists, the audit extracts — that the business would have missed instantly if it vanished, and never once described as "analytics."
Paginated reports are the plumbing of BI: nobody admires them, everybody would notice within an hour if they stopped working. Fashionable is not the same as useful, and the printable extract has outlived a decade of things that were going to replace it.
So: still worth it?
Yes — for their jobs, and only for their jobs. The trap is the fashion of it: modern BI culture treats paginated reports as legacy, faintly embarrassing, something you'd rather not admit you still run. But "legacy" and "still the best tool for this specific job" are entirely compatible, and pretending otherwise just means solving the printable-document problem badly with a tool that was never meant for it. I came back to paginated reports reluctantly and left convinced: they're not a relic, they're a specialist. Keep them in the kit, know exactly the four or five jobs they're for, don't reach for them for anything else — and you'll have the whole reporting problem covered, the glamorous half and the unglamorous half alike. The business only ever notices when the unglamorous half is missing.