SCSB's position on financial reporting in Dynamics 365 Business Central is not really about the reporting tool: a report inherits whatever the underlying data already is. Requests for better reporting usually arrive as a symptom — a report is late, hard to reconcile, or disputed at the management meeting — and the instinct is to change the reporting layer. The more useful first step is to establish what the report is for, which records it depends on, how those records are categorised and dimensioned, and who is accountable for reviewing the result.
This article sets out that sequence, including where a separate reporting layer such as Microsoft Power BI genuinely adds something, and where it does not.
Start with the decision, not the report
"We need a management report" is not yet a configuration requirement. Before changing anything, define the intended decision, the audience, the period and cut-off, the source records, the dimensions and filters, the calculation logic, the reviewer and the approval route. That definition lets the configuration be tested against an agreed result rather than a vague expectation.
Microsoft's financial reporting documentation describes the Financial Reports feature, which analyses figures in general ledger accounts and compares general ledger entries with budget entries. It is explicit that the sample reports supplied are not ready to use out of the box, and need adjusting to your own accounts, dimensions, account categories and budgets. Those are configuration capabilities; they do not determine accounting policy or statutory treatment.
The chart of accounts and dimension design set the ceiling
Microsoft lists three prerequisites for financial reporting: map general ledger posting accounts to general ledger account categories, design how you use dimensions, and set up budgets where you want to compare actuals against budget.
The same foundation carries straight into the reporting layer. The documented setup for the Power BI Finance app is to set up general ledger account categories for your chart of accounts, then map those categories to the corresponding categories in the Power BI Finance semantic model. A dashboard does not introduce a second, better version of your chart of accounts — it reads the one you already have.
That gives a test to apply before any reporting-layer discussion. If the chart of accounts, account categories and dimension design cannot support the built-in balance sheet, income statement and statement of cashflows reliably, adding a visualisation layer changes the presentation, not the answer.
Decide dimensions before they become expensive to change
This is the point at which SCSB most often finds a reporting problem was actually decided years earlier, in a configuration nobody revisits.
Dimensions let an organisation analyse by department, project or area without building those distinctions into the chart of accounts. Microsoft's dimensions documentation sets out the structural limits that make this an early decision:
- Two global dimensions only. These are the dimensions usable as filters on reports, batch jobs and ledger entry pages, so they should be the ones used most often.
- Up to eight shortcut dimensions, available as fields on journals, document lines and ledger entries.
- Once a dimension has been used in any entry it cannot be deleted, even if that entry is never posted, because a dimension set is created immediately.
- Changing a global or shortcut dimension requires every posted entry carrying it to be updated, which locks tables and blocks other users unless run in parallel mode. Microsoft's own guidance is to choose these carefully to avoid changing them later.
Three further controls are worth setting deliberately: dimension combinations can be left unrestricted, limited to certain value pairings, or blocked; default dimensions can be assigned per account, with a value-posting rule that makes a code mandatory; and default dimension priorities resolve conflicts where account types propose different dimensions.
A dimension applied inconsistently makes a detailed report less reliable, not more useful. The detail implies a precision the underlying data does not support.
Map the workflow before assuming the fix is technical
Where a reporting process is not working, map it before redesigning it: source records, data owners, manual transformations, reconciliations, exceptions, reviews, approval and distribution. That map usually shows where the constraint really sits: data quality, an unclear measure definition, duplicated work, an access restriction, a cut-off problem, or a missing control. None of those is fixed by running the existing process faster.
Reporting quality is an operating model, not a layout. For each recurring output, identify the data owner, the preparer, the reviewer, the approver and the administrator responsible for future changes. Where any of those is unclear, automation makes a weak process quicker without making it more reliable — so some problems are resolved by naming an owner and setting a clearer cut-off rule, not by a configuration change.
Where built-in reporting is enough, and where a reporting layer earns its place
SCSB treats this as a judgement about the organisation, not about the tools. The question is what the data can already support, not which product is more capable.
Not every organisation needs a reporting layer. Business Central ships a substantial set of built-in finance reports — trial balances by period, balance sheet, income statement, statement of cashflows, retained earnings, audit trail, and dimension total and detail reports. Financial reports can also be integrated with a Microsoft Excel workbook template and refreshed with Business Central data.
For quick questions, the Data Analysis feature lets a finance user pivot directly on list pages such as general ledger, customer ledger and vendor ledger entries without running a report or switching application. Microsoft positions it for exactly the cases where you do not want to run a report, no report exists for the need, or you want to iterate quickly.
Where a reporting layer does earn its place, the mechanism is documented: Power BI reports can be displayed in parts on Business Central pages, and Microsoft publishes Power BI apps for functional areas including finance, sales, purchasing, inventory, manufacturing and projects. The Finance app has been generally available since the 2024 release wave 2, covering financial overview, budget comparison, liquidity and profitability reporting, and a general ledger entries report sliced by all eight shortcut dimensions.
Two constraints are worth establishing before committing. Microsoft states the Power BI apps are free to install but that users must hold a paid Power BI licence; confirm the current position through Microsoft's Business Central licensing documentation. Second, multi-company reporting is not a given: since the 2021 release wave 2 only OData V4 is supported, and Microsoft states that OData V4 does not export data from multiple companies.
The test is simple. If the decision is already served by a report a finance user can run, reconcile and explain, a second reporting layer adds a maintenance obligation without adding an answer.
Treat refresh and access as separate controls
A report can be visually plausible while using an incomplete filter, a stale refresh or an unexpected permission. Each Power BI report draws on a dataset fed from Business Central sources, and Microsoft notes that depending on how an organisation has set up Power BI, refreshing might not happen automatically. Someone must own the refresh schedule and the failure path when it does not run.
Access is a separate control again. Business Central governs who may view or change financial reports through dedicated permission sets — one for viewing financial reports, another for editing report, row and column definitions. Alongside that: uploading a Power BI report through Business Central requires SUPER user permissions; sharing a Power BI report requires both parties to hold a Power BI Pro licence, or the content to sit in Premium capacity; and modifying a shared report from within the Business Central part republishes that change to everyone unless it is saved as a new report. Microsoft records that this modify capability is not available with Business Central on-premises.
A viewer should receive only the information the organisation intends that role to see. That is an information-governance decision, and a dashboard connection does not make it for you.
Keep the report definition traceable and reviewable
In SCSB’s experience this is the control that lapses first, because it depends on habit rather than configuration.
One documented behaviour deserves particular attention: financial report definitions are not versioned. When a definition is changed, the old version is replaced as soon as the change is saved, so Microsoft's stated guidance is to copy or export the definition first, as a configuration package.
Business Central offers more than a manual design note here, and these controls are worth switching on deliberately:
- The Change Log can capture changes to the report, row and column definition tables, recording what changed, who changed it and when.
- Field-level monitoring can send a notification when someone changes a monitored value.
- Financial report audit logs show who ran which report, when, and in what output format.
- Where telemetry is enabled, administrators can analyse both definition-lifecycle changes and how often reports are actually used.
- Lifecycle statuses of active, draft and retired, together with blocking, prevent a superseded definition being used unknowingly.
Keep the substantive design record alongside those system controls: chart-of-accounts and dimension logic, posting assumptions, calculation rules, and cut-off behaviour. Where a definition changes, record the owner, the effective date, the test evidence and any effect on comparatives. The person who built the report is not always the person who has to explain it a year later.
Test against real decisions, then accept formally
Run representative and exceptional transactions through the whole process: corrections, reversals, period-end journals, missing dimensions, late postings, and users with different access rights. Reconcile key totals to the recognised source records, confirm access for the intended audience, and document who accepted the result. Treat a new or changed report as a controlled change, and revisit the design when the chart of accounts, a dimension, an integration or the underlying business process changes.
None of this determines which financial reporting framework applies to an organisation's financial statements, or how any figure should be recognised, measured or disclosed. MFRS and MPERS are issued by the Malaysian Accounting Standards Board, and both the applicable framework and its application are matters for the Board's pronouncements and the organisation's own advisers. Tax obligations are matters for HASiL and those advisers. A configured report supports a reporting process; it does not discharge an accounting or tax obligation.
Where SCSB implementation support fits
Where an organisation has defined a Business Central financial-reporting configuration scope, SCSB's financial reporting service can be discussed. Where the real constraint is ownership, cut-off discipline or an unagreed measure definition, an internal fix is often the proportionate one, and we would say so rather than configure around it. SCSB’s work in this area is usually less about building reports than about settling the decisions underneath them: what each measure means, who owns the close, and which dimensions the organisation is prepared to maintain. Where those are already settled, the configuration itself is generally straightforward and an organisation may reasonably do it in-house.
This article is general information about configuring and controlling financial reporting in Business Central. It is not accounting, tax, legal or regulatory advice, and it does not establish an outcome for any organisation. Accounting policies, statutory reporting conclusions and management approval remain the responsibility of the organisation and its advisers. Product capabilities and licensing terms are set by Microsoft and may change.
Dynamics 365 Business Central, Microsoft, Microsoft Excel and Power BI are trademarks of the Microsoft group of companies.