Business Central Custom Reports Without IT
Building a report in Microsoft Dynamics 365 Business Central splits into two paths, and only one of them keeps finance self-sufficient. Financial statements come from the Financial Reports feature, where a controller arranges row and column definitions and never touches code. Everything else, including most operational and document reports, runs on a report object written in AL and deployed through Visual Studio Code. Business Central custom reports that fall outside the financial-statement shape land in that second path, which means a developer, a ticket, and a wait. The dividing line between the two is where finance teams keep losing time, and it is worth understanding before the next request goes into the queue.
Two ways to build a report in BC
The Financial Reports feature is the part of Business Central built for finance to use without help. It analyzes general ledger accounts and compares ledger entries to budget entries, producing income statements, balance sheets, cash flow, and similar views off the chart of accounts. Microsoft’s documentation is direct about the audience: the number of financial reports you can create is unlimited and they require no involvement of a developer. A controller picks a row definition, a column definition, sets dimension filters, and previews the result.
The other path is the report object. Microsoft describes a Business Central report as a composite of a report object, a dataset, a layout, a request page, and supporting properties and code. You create the report object in the AL Language development environment to define the dataset, the model of which tables and fields the report can reach. That sentence is the whole problem in miniature: the dataset is defined in code, so the data a report can show is fixed by a developer before a finance user ever opens it.
Why Business Central custom reports need a developer
Once the dataset exists, the report needs a layout, and there are three kinds. Excel and Word layouts are editable in the applications finance already knows. RDL layouts require Visual Studio Report Designer or SQL Server Reporting Services Report Builder, which are developer tools by any reasonable definition. So even the friendlier layout options sit on top of a dataset that was authored in AL.
That dependency is the part teams underestimate. If the field a report needs is already in the dataset, a power user can rework a Word or Excel layout. The moment the report needs a column the dataset does not carry, the work goes back to AL through a report object or a report extension, both of which are development tasks deployed through the same pipeline as any other code change. A request that sounds small to finance, such as adding a dimension breakdown or a calculated margin to an existing operational report, is a code change, a test cycle, and a deployment to whoever owns the BC environment. This is the mechanism behind every “we submitted a ticket and waited three weeks” story in the BC ecosystem.
What financial reporting handles, and what it doesn’t
Financial Reporting earns its keep for statements that map cleanly to the chart of accounts. It also has edges that finance teams hit faster than they expect. A column definition holds up to 15 columns, which constrains side-by-side period and version comparisons. Some of the row-level formatting does not survive export to Excel, so a report that looks right on screen needs reformatting once it leaves BC. The sample reports Microsoft ships are not usable as delivered; they have to be adjusted to your account categories, dimensions, and budgets first. And report definitions are not versioned, so when you change one, the previous version is overwritten the moment the change saves.
The harder limit is scope. Financial Reporting reads the general ledger. Accounts receivable aging, payables aging, sales by item or salesperson, inventory valuation, project profitability, and most of what an operations manager or a distribution controller runs day to day are not G/L-account constructs, so they do not fit the row-and-column grid. Those reports are exactly the ones that drop back into the report-object path, which is why “we can do our P&L ourselves but everything else needs IT” is the steady state for so many BC finance teams.
Building Business Central custom reports without writing AL
Velixo collapses both paths into one place: the workbook finance already opens. It extends Excel with functions that read Business Central’s API, web services, and Velixo’s own published objects, so any report layout gets built with cell formulas instead of a deployed report object. You can access any Business Central data directly from Excel and build pixel-perfect reports that leverage dimensions, attributes, and filters, with no data warehouse, coding, or IT support required.
It covers the reports that BC’s built-in Financial Reporting cannot. Pre-built financial functions handle the statement work, and a generic Query function reports on any object exposed through the API, which is where AR and AP aging, sales, purchases, inventory, and project data come from. Data refreshes live as the report is built, any cell drills down to the underlying BC entries, and security inherits from the Microsoft sign-in, so a user sees in Excel exactly what their BC permissions allow. Anne Oliva, EVP and CFO at Embrace Living Communities, put the practical effect plainly: reports that used to take days to write and program now take a few hours. The skill required is Excel, not AL.
Scoping reporting before go-live
Partners scoping a BC implementation should treat the split above as a discovery item, not a post-go-live surprise. Most implementation plans cover transactions, workflows, and data migration, and leave reporting to sort itself out. It does not sort itself out. In week two of go-live the CFO asks for a report that Financial Reporting cannot produce, and the answer is a development backlog nobody budgeted for. Naming the Excel reporting layer in the plan from the start gives finance a self-service path for the operational and dimensional reports that would otherwise generate tickets for the life of the system.
Velixo connects Excel to Business Central, pulls live data across companies, dimensions, and accounts into the workbook through cell functions, and lets finance build any report layout without writing AL or filing a ticket. Learn more about Velixo for Business Central.