SCSB's position on financial reporting in Dynamics 365 Business Central is not really about the reporting tool: a report depends on both reliable source data and a correct definition. 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. Resolve gaps in source data and mappings before relying on a report. A reporting model can add controlled classifications and calculations, but those transformations must be documented and reconciled.
Decide dimensions before they become expensive to change
Dimension choices should follow the reporting questions the organisation needs to answer.
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 global or shortcut dimensions updates affected posted entries. Test and schedule the procedure: sequential mode can block other users, and parallel mode requires no more than one active database session when the update starts. 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 where compatible with the posting routines; 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.
Establish licensing and data architecture before committing. Microsoft’s integration guidance distinguishes general Power BI use from the packaged Business Central Power BI apps: a free Power BI licence does not cover those apps, and users accessing reports with Business Central data also need the appropriate paid Business Central licence. Check the chosen app, workspace, viewer and author requirements rather than treating every report as the same licence case.
Microsoft’s Business Central Power BI guidance documents a limitation on exporting multiple companies through the described OData V4 route, including the suggested $expand workaround. That endpoint limitation is not a conclusion that all multi-company Power BI architectures are impossible. Define the companies and source connections explicitly, then verify the chosen extraction and combination design. Microsoft recommends API pages or queries over UI pages exposed as OData web services for new Business Central online reporting integrations.
If an existing report meets the need, assess whether a separate layer adds worthwhile value through distribution, refresh, analysis or integration with other data. Weigh that benefit against maintenance.
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 depends on the author, recipient and workspace licence/capacity combination; 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.
Microsoft’s Power BI licence guidance distinguishes Pro, Premium Per User and capacity-backed sharing. A Premium Per User workspace is not a Premium capacity workspace; qualifying capacity can allow access for free viewers under the documented conditions. Confirm the current combination before designing distribution.
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
A report change needs a reviewable definition and an owner, even where the software records the change.
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. Confirm the version and effective settings before relying on these controls. Microsoft’s financial-report auditing guidance, updated 1 October 2026, states that automatic recording of definition changes starts in 2026 release wave 2. Earlier versions need their applicable Change Log setup checked.
- 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.
Keep one definition and reconciliation record
For an illustrative monthly departmental result, record the report name and definition version, company, period, dimension filters, account mapping, currency and refresh time. Attach the approved expected total and the observed output, explain differences, and name the preparer and reviewer. If the definition changes, repeat the comparison and record whether comparative periods changed. This gives the reviewer evidence about the report’s intended meaning as well as its technical output.
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.