Paginated report

What is a paginated report?

A paginated report is a report designed as a document. The layout is fixed: page size, margins, tables, logos, headers, footers, and page numbers are placed deliberately. The result is meant to print cleanly, export to PDF, or be distributed as a finished file.

That is the difference from an interactive Power BI report. A Power BI report is a screen you explore with slicers, filters, tooltips, and drill-through. A paginated report is the document you hand over: an invoice, payslip, audit list, board pack, customer statement, or monthly operational report.

The strongest use case is long tables. If a table contains 4,000 rows, an interactive report shows a scrollable visual. A paginated report can generate a multi-page document that includes every row.

RDL and Report Builder

Power BI paginated reports use RDL, short for Report Definition Language. RDL is an XML representation of the report definition: data sources, datasets, layout, parameters, expressions, and formatting.

The main authoring tool is Power BI Report Builder, a free desktop application from Microsoft. You design the report locally, preview it, and publish it to the Power BI service. Microsoft also supports a web authoring experience for simpler paginated reports in the Power BI service.

RDL has its roots in SQL Server Reporting Services. Many organisations still have old SSRS reports. Reports from modern SSRS or Power BI Report Server environments can often be migrated to the Power BI service, but unsupported features and data-source details need testing.

Paginated report versus interactive report

Purpose
An interactive report supports exploration. A paginated report supports distribution.

Layout
An interactive report adapts to a screen canvas. A paginated report is laid out for fixed pages such as A4 or letter.

Tables
An interactive table may scroll. A paginated table continues over pages until all rows are shown.

Interactivity
A paginated report can have parameters, but once the document is generated, it is a fixed output. The reader does not explore it like a dashboard.

Exports
Paginated reports are built for export formats such as PDF, Excel, Word, PowerPoint, CSV, XML, and accessible PDF where supported.

Use both where needed. A management dashboard can show the trends. A paginated report can produce the official monthly pack or customer-specific document from the same governed data source.

When do you use a paginated report?

Choose a paginated report when completeness and layout matter more than exploration.

• Invoices and credit notes. One fixed document per customer, with branding, totals, VAT details, and payment information in the right place.

• Payslips, certificates, and statements. Documents where the layout must be stable and personal to the recipient.

• Audit and accountant lists. Long lists where every row must be present, including rows that would sit outside the visible part of a dashboard.

• Board packs. A repeated monthly structure that is reviewed as a PDF or printed document.

• Operational runs. Pick lists, delivery notes, reminders, membership lists, and inspection sheets.

If the question is exploratory, use an interactive report. If the result is a document, use a paginated report.

Data sources and semantic models

A paginated report does not contain a Power BI-style model of its own. It contains embedded data sources and datasets, or it connects to existing sources.

Common sources include Power BI semantic models, SQL Server, Azure SQL, Oracle, and other supported sources. Using a semantic model as the source is often the cleanest path because the definitions and measures stay aligned with the dashboards users already trust.

Be aware that Power BI paginated reports do not support SSRS-style shared data sources and shared datasets in the same way. If you migrate from SSRS, test those parts rather than assuming everything maps one to one.

Parameters and subscriptions

Parameters let one report generate many versions. The layout stays the same while the content changes by customer, period, region, employee, or account.

Subscriptions in the Power BI service can send reports on a schedule. Dynamic per-recipient subscriptions go further: they use data to decide which recipient receives which parameterised version. That is useful when every manager, customer, or account owner needs their own document.

Subscription and export limits change over time and depend on capacity, tenant settings, report design, and file size. For operational distribution, test with realistic volumes before promising that a report run will always finish within a time window.

Licensing and capacity

Power BI Report Builder itself is free. Publishing and sharing paginated reports follows Power BI and Fabric licensing rules. The exact requirements depend on where you publish, who consumes the report, and whether you use features such as subscriptions, embedding, or capacity-backed workspaces.

Do not design a billing or compliance process around a licensing assumption from memory. Check the current Microsoft licensing and tenant settings before rollout.

What to watch out for

Design takes more handwork
Pixel precision is useful because you control everything. It is also slower because you control everything.

Do not use it to fix every export annoyance
If a normal dashboard export is merely inconvenient, a simpler visual or Excel export may be enough. Use paginated reports when fixed layout and complete row output are requirements.

Large reports need testing
Huge exports can hit memory, runtime, or attachment limits. Test the largest realistic customer, month, and filter set.

Reuse definitions where possible
If every paginated report contains its own SQL logic, definitions drift. Prefer governed semantic models or shared warehouse logic for important metrics.

Security still applies
A PDF sent by email leaves the interactive security boundary. Think about recipient lists, parameters, row-level access, attachment handling, and retention.