Microsoft DynamicsERP Platform

Business Central + private AI

AI for Dynamics 365 Business Central, on-premises or SaaS, beyond Copilot

Short answer

Business Central's built-in Copilot features cover specific tasks well, like drafting item descriptions or bank reconciliation matching, but leave most finance and operations questions unanswered without a report. A private AI layer grounded on BC's OData v4 web services and APIs can answer broader questions directly, works the same way whether BC is on-premises or SaaS, and keeps financial data off a shared cloud AI service where that matters.

ERP
Dynamics 365 Business Central, Dynamics NAV (on-prem predecessor)
Industries
Manufacturing, Distribution, Electronics
Written for
Finance Director

Business Central sits in an interesting spot for AI adoption: it is Microsoft's mid-market ERP, available both as a multi-tenant SaaS product and, for a meaningful minority of customers, still deployed on-premises (the direct continuation of Dynamics NAV). Microsoft's Copilot features in BC are genuinely useful for what they cover, drafting item descriptions, suggesting bank reconciliation matches, summarising sales lines, but they are narrow by design, and the on-premises deployment does not get the same Copilot feature set as SaaS at all.

For a finance director, the practical gap is this: BC's data model (customers, vendors, items, general ledger entries, sales and purchase documents) is clean and well exposed through OData v4 web services, but getting an answer to a question like "summarise this quarter's aged receivables by risk, in plain language" or "which vendors have had a payment terms change in the last six months" still means building a report, pulling data into Excel, or asking someone on the finance team who knows where to look. Copilot's item description generator does not help with that.

The fix is the same pattern that works across any modern ERP: ground a private model on BC's OData v4 endpoints (or the newer BC API pages), with a semantic layer that translates BC's table and field names into finance and operational language, and let the finance and operations teams ask direct questions. This works identically whether BC is SaaS or on-premises, since both expose the same OData/API surface (with the on-premises deployment requiring its own web service configuration rather than Microsoft's cloud endpoint).

This matters particularly for BC customers in regulated or IP-sensitive industries, electronics manufacturers with export-controlled BOMs, or distribution businesses handling data for customers with their own data-handling requirements, who are comfortable with BC itself but want the AI layer on top of it to run on infrastructure they control rather than through a shared cloud AI service. On-premises BC customers, and the growing minority of SaaS BC customers on the mid-market side of aerospace and defense supply chains, tend to be the clearest fit.

What usually gets in the way

The problems we hear most from finance director teams running Dynamics 365 Business Central.

Copilot in BC covers specific tasks, not general questions

Item description generation and bank reconciliation matching are useful, but a finance director's actual question ("why did gross margin move this period") is outside what BC's Copilot features answer.

On-premises BC does not get the SaaS Copilot feature set

Customers running Business Central on-premises (or the older NAV) do not have access to the same built-in Copilot capabilities as SaaS tenants, leaving a wider gap for on-prem shops specifically.

Reporting still means building a report or exporting to Excel

BC's data is clean and accessible via OData, but ad hoc questions from finance or operations staff still typically route through a report request or a manual Excel export.

Small finance and IT teams have little capacity to build custom reporting

Mid-market BC customers, who are often smaller organisations, rarely have a dedicated BI or reporting resource to keep building new views as questions come up.

Sensitive financial and customer data may not belong in a shared cloud AI service

Some BC customers, particularly those with regulated or export-adjacent customers of their own, are not comfortable routing financial detail through Microsoft's default Copilot AI processing.

Where AI earns its place in Dynamics 365 Business Central

Each use case names the ERP objects it reads or writes, so your ERP team can judge the integration effort before anyone commits budget.

Plain-language aged receivables and payables summaries

A finance director asks for a summary of aged receivables by risk category, or which vendors are approaching a payment terms change, grounded in live BC ledger data.

Touches: Cust. Ledger Entry, Vendor Ledger Entry, Payment Terms tables via OData/API pages

Outcome: Turns a recurring Excel export-and-summarise task into a direct question, freeing finance time for follow-up rather than data assembly.

Margin and variance explanation

Ask "what drove the gross margin change on this item group this quarter" and get an answer grounded in sales, cost, and item data, with the underlying transactions cited.

Touches: Sales Invoice Line, Item Ledger Entry, G/L Entry

Outcome: Gives a first-pass variance explanation in minutes rather than a manual pull and pivot table exercise.

Inventory and item availability questions

Operations and sales staff ask about on-hand, on-order, and reserved quantity for a specific item without navigating BC's item card or building a new list view.

Touches: Item, Item Ledger Entry, Sales Line reservations

Outcome: Faster availability answers for sales and operations staff, particularly useful for non-power-users of BC.

Vendor and customer master data quality checks

Scan vendor and customer records for inconsistencies (duplicate entries, missing tax or bank details, inactive accounts with recent activity) and report them for cleanup.

Touches: Vendor, Customer, Bank Account tables

Outcome: Surfaces master data issues before they cause a payment error or a failed reconciliation.

Purchase and sales document status inquiry

Ask about the status of a purchase order or sales order, including receipt and shipment progress, without opening the document in BC.

Touches: Purchase Header/Line, Sales Header/Line, Warehouse Receipt/Shipment

Outcome: Reduces the number of status questions routed to whoever processes purchasing or sales documents.

Document intake for AP with matching support

OCR and classify vendor invoices, propose a match against open purchase orders, and flag exceptions for a clerk to review, complementary to BC's own document capture feature.

Touches: Purchase Invoice, Purchase Order, Vendor

Outcome: Cuts manual keying on routine invoices, particularly useful for smaller finance teams without dedicated AP staff.

On-premises grounded assistant with no cloud dependency

For customers running Business Central on-premises, an AI layer connects through the on-prem OData/SOAP web services with the model itself running fully on-prem, no cloud AI dependency at all.

Touches: On-premises BC OData v4 web services, NAV/BC SOAP services where still in use

Outcome: Gives on-premises BC customers a modern AI capability equivalent to what SaaS Copilot offers elsewhere, without requiring a move to SaaS or any cloud AI service.

Reference architecture

A private model grounded on Business Central's OData v4 web services and API pages, working identically for SaaS and on-premises deployments, with a semantic layer translating BC's table structure into finance and operational language.

  1. 1

    BC connectors

    OData v4 web services and BC API pages for structured read access to customers, vendors, items, and ledger entries; on-premises deployments use the equivalent locally hosted web service endpoints.

  2. 2

    Semantic layer

    A mapping of BC's table and field names to finance and operational business terms, accounting for any custom fields or extensions (AL extensions) the company has added.

  3. 3

    Model serving

    Open-weight models served via vLLM or Ollama, on infrastructure sized to a mid-market finance and operations team's query volume, whether on-prem or in a small dedicated cloud instance.

  4. 4

    Retrieval and agents

    Text-to-query against the OData/API layer for structured finance and operations questions, RAG over documents for AP invoice intake and vendor correspondence.

  5. 5

    Governance and audit

    Every answer logged with the BC table and record it drew from; access scoped to match existing BC user permissions and roles.

Integration notes for your ERP team

  • Use OData v4 web services (or BC API v2.0 pages) as the primary read path; both are well documented and cover most standard BC tables without custom AL development.
  • For data not exposed by standard web services, publish a scoped custom API page in AL rather than granting the AI layer direct SQL Server access to the BC database, preserving BC's business logic layer.
  • For on-premises BC, confirm the web service configuration (NAV/BC Server instance, published endpoints) since it requires explicit setup that differs from the SaaS tenant's default exposure.
  • Map any AL extensions the company has installed, since a meaningful share of BC customers run ISV add-ons or custom extensions that add fields the AI layer needs to know about.
  • Authenticate via Azure AD app registration (SaaS) or NTLM/Windows auth as configured for on-prem, kept as a scoped, dedicated service account separate from interactive user logins.
  • Where BC's own Copilot features already cover a task well (item description drafting, bank reconciliation matching), let them continue to do that; the private AI layer is for the broader question-answering gap, not a wholesale replacement.
  • Confirm currency and dimension configuration in the semantic layer early; smaller BC customers sometimes have simpler dimension setups than larger ERPs, which actually makes this mapping step faster.

Deployment options

Air-gapped on-prem

Customers running Business Central on-premises who want the AI layer to match, with no cloud dependency at all, or SaaS BC customers with export-adjacent data who need a stronger separation than Microsoft's default Copilot processing.

Model and connector run entirely on customer hardware, connecting to on-premises BC web services (or, over a controlled path, a SaaS tenant's OData endpoints) with no data sent to any external AI service.

Private or sovereign cloud

SaaS Business Central customers comfortable with cloud economics who want AI capability beyond Copilot's specific workflows, without routing data through a shared multi-tenant AI service.

Model serving in a dedicated, single-tenant cloud environment, connecting to BC's OData v4 endpoints over authenticated calls.

Hybrid

Smaller finance teams wanting to pilot a single use case, aged receivables summarisation for example, before committing to infrastructure.

A modest pilot footprint (small quantized model, limited data scope), same architecture, expanded once proven.

Compliance and data control

How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.

Data protection (UK GDPR / EU GDPR as applicable)

For UK and EU Business Central customers, model serving and any data storage can be kept within the required jurisdiction, independent of where Microsoft's default Copilot processing occurs.

Financial controls

Read-only access to ledger and document data for inquiry use cases; any adjustment or posting stays inside BC's own workflow, never a direct AI write, preserving the existing approval chain.

Data access scoping

AI agent access mirrors existing BC user permission sets, so a sales-facing availability query tool does not surface finance data the underlying permission set would not allow.

Export control (where relevant)

For BC customers supplying electronics or components into export-controlled supply chains, sensitive item and BOM data can be kept fully on infrastructure the customer controls.

How an engagement runs

Phase 1 . 1-2 weeks

Discovery

  • -Inventory of available OData/API pages and any AL extensions affecting the target use case
  • -Confirmed deployment (SaaS or on-premises) and authentication approach
  • -Prioritized use case (finance inquiry, inventory, or document intake)
  • -Success criteria agreed with finance and IT

Phase 2 . 4-6 weeks

Pilot

  • -Working connector and semantic layer for the pilot data domain
  • -Model serving stood up matching the target deployment (on-prem or dedicated cloud)
  • -5-10 real finance or operations questions answered end to end with cited sources
  • -Pilot review with finance director and IT

Phase 3 . 6-8 weeks

Production

  • -Role-based access aligned to existing BC permission sets
  • -Audit logging of all queries
  • -Document intake workflow validated against a batch of real vendor invoices, if in scope
  • -Runbook for IT to maintain the connector across BC updates

Phase 4 . ongoing

Scale

  • -Additional data domains (sales, purchasing, inventory) added to the semantic layer
  • -Quarterly review of query patterns and any new AL extensions requiring mapping updates

Questions to ask any vendor, including us

A short list that separates real Dynamics 365 Business Central AI work from a chatbot demo.

  1. Does this work the same way for our on-premises Business Central deployment as it would for SaaS?
  2. Does any of our financial data get sent to Microsoft's Copilot AI processing, or does the model run entirely on infrastructure we control?
  3. How do you handle AL extensions and ISV add-ons we've installed that add custom fields?
  4. What exactly can this write back to BC, and what stays strictly read-only?
  5. How is access scoped relative to our existing BC user permission sets?
  6. Can you show a real example of the OData query your system generated for an aged receivables question?
  7. What is the realistic setup time and cost for a finance team our size, without an in-house BI resource?
  8. How do you keep this working as we upgrade Business Central versions?

Frequently asked questions

Does this work with Business Central on-premises, not just SaaS?

Yes. On-premises BC exposes the same class of OData v4 and SOAP web services as SaaS, just requiring explicit configuration on the local server. The AI layer connects to either the same way, and on-premises customers get a fully on-prem AI deployment with no cloud dependency if that's the requirement.

How is this different from Microsoft Copilot in Business Central?

BC's built-in Copilot features handle specific tasks well, like drafting item descriptions or suggesting bank reconciliation matches, and route through Microsoft's cloud AI processing. A private AI layer grounded on BC's OData data answers a much broader range of finance and operations questions and can run entirely on infrastructure you control.

Do we need a developer to build custom AL extensions for this to work?

Usually not. BC's standard OData v4 web services and API pages cover most finance and operations data needs. A custom AL-published API page is only needed for data not already exposed, which is uncommon for core finance and inventory use cases.

Will this post journal entries or change documents automatically?

Not by default. The standard design is read-only for inquiry and summarisation use cases, with any proposed change requiring a person to review and post it through BC's own workflow, preserving normal financial controls.

Is this realistic for a smaller finance team without a dedicated BI person?

That is the main audience for this approach. Business Central customers are often smaller organisations without capacity to build and maintain custom reports for every new question; grounded question-answering removes that dependency for routine inquiries.

Does this replace BC's own document capture and OCR feature for invoices?

It can complement it. BC's native invoice capture handles basic OCR; a more thorough document AI layer can add matching against open purchase orders and flag exceptions with more context, while still routing anything uncertain to a person.

Can this keep our customer and vendor data off Microsoft's Copilot processing entirely?

Yes, if that is a requirement. Running the model on customer-controlled infrastructure, on-prem or in a dedicated cloud tenant, means no BC data needs to be sent to Microsoft's Copilot AI service at all.

Talk it through with an engineer who knows Dynamics 365 Business Central

Bring one real question your team cannot answer from the ERP today. We will map the data path, the model, and where it runs, and tell you honestly if AI is the wrong tool for it.