Native, Power BI direct, Jet, or Fabric: why Business Central has four credible reporting paths, what each actually costs, and how to pick between them.
Business Central has more reporting options than most other ERPs, and that is not an accident. BC reporting needs span genuinely different use cases: operational documents like invoices, statements and picking lists need pixel-perfect output; finance teams need flexible, Excel-shaped analysis; operations need self-service dashboards; and AI or forecasting work needs a modern data layer. No single tool serves all four well, which is why four credible options exist, each strong for a different job. The built-in reporting has five recurring gaps that push most organisations to look elsewhere for analytical work: multi-company consolidation is awkward or impossible depending on tenant structure, external data integration is limited to BC-only sources, there is no certified semantic model, performance suffers on heavy queries against the live system, and formatted financial reporting is constrained.
Native reporting (RDLC and Word layouts) is included with BC, which is not the same as free. The real cost sits in hours: maintaining RDLC layouts, fixing them when BC versions change, and finding people who can still work with them, since those skills are increasingly scarce. Word layouts are easier to maintain than RDLC for simple documents, and most modern BC users build customer-facing documents in Word where possible, reserving RDLC only for documents that need its extra control. Total cost of ownership is real even when there is no licence line item attached to it.
“Power BI direct on BC” is one of two patterns we see regularly. It means treating BC’s own APIs as the data source and letting Power BI handle the modelling directly, with no warehouse, lakehouse or ETL layer in between. It suits smaller data volumes and single-entity setups. The other pattern lands BC data in Fabric first, which suits multi-entity, multi-source or governance-heavy requirements. Which one is right depends on scale and reporting complexity, not preference. The same principles apply to NAV and earlier Dynamics products: the extraction is more involved because the systems are older and the APIs less developed, but the downstream architecture is identical. Hopton has experience working with NAV environments through to BC migrations and has clients running on both, so being on NAV is not a barrier to starting.
Copilot adds a fifth dimension worth addressing directly, because it now shows up in both BC and Power BI. Copilot in BC is useful for the operational user drafting purchase orders, summarising customer activity or asking questions about specific transactions. Copilot in Power BI is useful for the analytical user generating visuals, drafting DAX or exploring data. The two complement each other, and both work better when the underlying data foundations are right.
Microsoft has not committed to a single reporting direction for BC, and that is a feature rather than a gap. It continues to invest in Native for operational reporting and in Power BI for analytics, and the architectural direction is clear: operational stays in BC, analytical moves to Power BI and Fabric, and there is still room for finance-specific tools like Jet to hold their place in that mix. Choosing between the four options is less about picking a winner and more about matching each reporting need to the tool built for it.
Shauna Duffy
Director of Professional Services
Part of the Hopton Analytics team, delivering governed analytics programmes for UK mid-market organisations.