Business Central reports have a dataset (what data, in what shape) and one or more layouts (how it looks). The layout choice is the one people argue about; the dataset design is the one that decides whether the report is fast, extensible and reusable. When to use RDLC, Word and Excel, how to design a dataset that survives, report extensions, and the five mistakes in most inherited reports.
A Business Central report is two things. The dataset, defined in AL, says which tables, in what nesting, with what columns and filters. The layout says how the dataset is rendered: RDLC (the SQL Reporting Services format), Word, or Excel, and since version 20 a user can have several layouts per report and pick one at run time. Most arguments are about the layout. Most problems are in the dataset.
| RDLC | Word | Excel | |
|---|---|---|---|
| Best for | Precise documents and complex lists: invoices with dense tables, multi-section statements, anything with conditional formatting and running totals | Documents a business user should be able to edit: letters, simple invoices, certificates, labels | Analytical outputs: anything the user will pivot, chart or filter; management reports |
| Who maintains it | Developer, in Report Builder or VS Code | A capable user, in Word, with the report's XML mapping | A capable user, in Excel, with the dataset as a table and their own sheets on top |
| Expressions and logic | Full: VB expressions, grouping, conditional visibility | Limited: repeating sections, conditional content via field codes | Excel formulas, pivots and charts over the data sheet |
| Weak points | Slow to render large datasets; hard for non-developers; page-break quirks | Tables that need to break across pages with repeated headers; totals | Not for printed documents |
The practical rule: documents customers see are RDLC (or the new document report experience in version 29, which brings themes and reusable headers to Word layouts and is worth adopting for new documents); anything internal that ends up in Excel anyway should be an Excel layout from the start; Word for the letters and labels the business wants to tweak without a developer.
DataItemTableView and DataItemLink push the restriction to SQL. CurrReport.Skip() in OnAfterGetRecord reads everything and throws most of it away.Since version 18 you extend a report you do not own: add columns to a data item (dataset { add("Sales Invoice Line") { column(PalletConfig; "CON Pallet Configuration") } }), add data items, add request page fields, and add your own layouts. Then the standard Sales Invoice carries your field and your layout shows it, with no copy of the report and no merge at the next update. This replaces the NAV habit of copying report 206 to 50206 and modifying it, which is still the most common thing we find in inherited code and the first thing we retire.
Version 20 onwards: any user with permission can create a layout for any report (Report Layouts page, New, choose RDLC, Word or Excel), start from the standard one, edit it, and set it as the default for themselves, a company or everyone. Excel layouts in particular mean the finance team can own the management report format while the developer owns the dataset. The developer's job is to make the dataset complete enough that they never need to come back for a column.
Reports are where users judge the system, because the invoice is what the customer sees and the management pack is what the board sees. They deserve the same design discipline as the posting code. If your document pack is a set of copied reports, the AL code check will list them and the extension-based replacement is usually quicker than the first copy was.