After Power BI Q&A: Why Business Central Analytics Needs a Purpose-Built AI Layer

In December 2026, Microsoft will retire the classic Power BI Q&A experience — the feature that let users type natural language questions into a Power BI dashboard and receive chart answers. The official replacement is Copilot for Power BI. For most analytics teams this is a smooth handover. For Business Central users, it exposes a deeper problem that Copilot does not fully solve: generic BI natural language tools are not built for ERP data, and they never were.

This post is about what purpose-built natural language analytics for Business Central actually requires — technically, architecturally, and from a data model standpoint. It is also about why we built Aurora BI the way we did, and what it does that Power BI Q&A and Copilot cannot.

1. Why Business Central Data Is Different

Generic BI natural language tools are built around flat, wide tables: a row per fact, columns per dimension. You ask "what were sales last quarter by region?" and the engine maps "sales" to a measure column, "last quarter" to a date filter, and "region" to a dimension column. This works well for data warehouses designed by analysts.

Business Central is not a data warehouse. It is a live transactional system with a normalized, entity-centric data model that was designed for accounting correctness, not query convenience. The same business question — "what is our gross margin by dimension for Q1?" — requires joining G/L entries to G/L accounts to dimension set entries to dimension values, filtering by posting date, then computing net change by account type. That is five tables, a dimensional lookup, and an aggregation with sign reversal for income vs. expense accounts. A generic NLP engine mapping "gross margin" to a column will not find it, because it is not a column. It is a computed result from the posting engine.

• Dimensions in BC are late-bound metadata, not table columns. A query for "sales by department" requires resolving the Dimension Set Entry table at runtime, not a static "department" column on the Sales Line.
• G/L amounts require sign-aware aggregation. Income accounts credit = positive. Expense accounts credit = negative. A wrong sign assumption produces a gross margin figure that is arithmetically valid and completely wrong.
• Inventory valuation in BC is cost-layer aware. "Current inventory value" is not a column — it is a function of the Inventory Valuation calculation, which accounts for cost adjustment entries.
• Period-over-period comparisons respect BC's fiscal calendar, not the Gregorian calendar. A query for "last year vs this year" must resolve against the Accounting Period table, not calendar year boundaries.
• Posted vs. unposted data requires explicit intent. Outstanding sales orders and posted revenue live in different tables with different semantics. An ambiguous "what are our sales?" should clarify the scope before computing.

2. What Generic Copilot Gets Right — and Where It Stops

Copilot for Power BI is a genuine step forward for dashboard users. It can summarise a visual in natural language, generate new visuals from a prompt, explain anomalies on a report, and answer questions grounded in an existing dataset. For a well-modelled dataset, it works well.

The limitation is the dependency on that upstream semantic model. Copilot can only answer questions that the Power BI dataset was designed to handle. If the dataset has no dimension-aware gross margin measure, Copilot cannot compute it — it will either hallucinate an approximation using whatever cost and revenue columns it can find, or return a graceful "I can't answer that from the available data." Neither outcome is useful to a CFO asking a routine financial question.

This is not a criticism of Copilot. It is the correct behaviour for a system that operates at the BI layer. The problem is architectural: when your source of truth is Business Central and your analytics layer is a Power BI dataset rebuilt nightly from a BC export, there is always a gap between what the data means in BC and what the dataset represents. That gap grows with every BC customisation, every new dimension, every change to the chart of accounts.

3. The Aurora BI Approach: Analytics Inside BC, Not Beside It

Aurora BI is built as a Business Central extension, not as an external BI tool connected to BC. This distinction is fundamental. Because it lives inside BC as an AL-based application, it has direct access to the full BC data model — not an export, not a snapshot, not a semantic model approximation. It queries the live data using the same APIs and business logic that BC itself uses.

Dimension-Native Query Resolution

When a user asks "show me operating expenses by cost centre for June," Aurora BI resolves "cost centre" against the BC Dimension table, identifies the correct Dimension Value Set for each G/L entry, and applies the correct account type aggregation. This is not a best-effort mapping — it uses the same dimension resolution logic that BC's built-in financial reports use. The result is the same number a trained BC accountant would get from the Account Schedule.

Fiscal Calendar Awareness

Aurora BI reads the Accounting Period table to resolve relative time expressions. "Last quarter" means the last closed accounting period group in the BC fiscal calendar, not the last three Gregorian months. For companies on a 4-4-5 fiscal year or a non-January year-end, this difference is material. Generic BI tools that assume Gregorian quarters produce numbers that do not match the figures in BC's own financial reports — a discrepancy that erodes trust in the analytics layer entirely.

Natural Language to BC Query: How It Works

The query pipeline in Aurora BI has three stages. First, the natural language input is parsed by a fine-tuned model that has been trained specifically on BC entity names, field labels, and financial terminology — not general business language. "Inventory turnover," "debtor aging," "net change in period," and "outstanding PO value" are concepts this model understands at the BC data model level, not just as English phrases.

Second, the parsed intent is translated into a structured BC query — resolving dimensions, fiscal periods, account filters, and posting group constraints. This structured query is validated against the BC schema before execution, which prevents hallucinated field references from reaching the database.

Third, the query result is rendered as a visualisation with a plain-language explanation of what was computed, what filters were applied, and what was excluded. If the query is ambiguous — "show me sales" could mean sales orders, posted revenue, or both — Aurora BI surfaces the ambiguity before computing rather than silently picking one interpretation.

User query:
  "What is our gross margin by item category for Q2 vs Q1?"

Aurora BI resolution:
  → "gross margin"         : Revenue (Income) − COGS (COGS account group)
  → "item category"       : Item."Item Category Code" via Item Ledger Entry join
  → "Q2"                  : Accounting Period 2026-04-01 to 2026-06-30 (fiscal)
  → "Q1"                  : Accounting Period 2026-01-01 to 2026-03-31 (fiscal)
  → Sign convention       : Income = credit balance positive, COGS = debit positive
  → Excluded              : Non-inventory G/L postings, intercompany entries

Computed result:
  Item Category | Q1 Margin | Q2 Margin | Δ
  Electronics   |    38.2%  |    41.7%  | +3.5pp
  Accessories   |    52.1%  |    49.8%  | −2.3pp
  Services      |    71.4%  |    73.0%  | +1.6pp

4. Proactive Insight: Moving Beyond Query-Response

The Q&A paradigm — user asks, system answers — is useful but fundamentally reactive. A CFO has to know what questions to ask. Aurora BI's proactive layer inverts this: it monitors key financial and operational signals in BC and surfaces anomalies and trends without waiting for a prompt.

• Gross margin compression alerts: when the margin on a specific item category drops more than a configurable threshold between periods, a notification surfaces in the BC Role Centre with the contributing accounts highlighted.
• Debtor aging drift: when the proportion of receivables in the 61–90 day bucket increases week-over-week, the system flags it with the specific customer accounts driving the shift.
• Purchase price variance: when the actual unit cost on a posted purchase invoice deviates from the standard cost by more than the tolerance, it surfaces for review before the cost adjustment runs.
• Period-end readiness: Aurora BI tracks unposted journals, unreconciled bank accounts, and unapplied payments against the current accounting period close checklist, surfacing a readiness score as the period-end date approaches.

These are not ML models trained on external benchmarks. They are rules applied to the BC posting engine's own output, using the same account categories and dimension structures the company has already configured. This makes them immediately relevant and immediately explainable — every alert links to the specific G/L entries, item ledger entries, or customer ledger entries that triggered it.

5. What This Means for Finance, Operations, and Sales Teams

For a finance team, the practical change is that the standard set of questions asked at the monthly management meeting — revenue vs. budget by department, gross margin by product line, expense variance by cost centre, cash position vs. forecast — are answered directly in BC without exporting to Excel, rebuilding a Power BI report, or waiting for the BI team to update the semantic model. The numbers match BC because they come from BC.

For operations, the item ledger and inventory valuation queries that previously required a BC developer to write a custom report are now expressible in plain language. "What is our stock value at standard cost by location as of last Friday?" is a query that took a developer half a day to build as a report. In Aurora BI it is a ten-second prompt.

For sales, the customer ledger queries — outstanding balances by salesperson, average payment terms by customer segment, order backlog value by item group — are surfaced in the same interface used for everything else, with no Power BI licence required for the end user.

6. The December 2026 Transition and What To Do Now

If your organisation is using Power BI Q&A against a BC dataset today, the retirement timeline is December 2026. Microsoft's recommended path is migration to Copilot for Power BI, which requires a Power BI Premium Per User or Fabric licence. For organisations that do not already have these licences, the migration adds cost and requires a rebuilt semantic model.

The alternative is to reconsider the architecture entirely. If the reason you built a Power BI layer on top of BC was to get natural language analytics, and that natural language layer is now being deprecated and replaced with something that requires a rebuilt model and a new licence tier, this is the right moment to ask whether the Power BI layer is actually necessary for your core reporting workload.