D365 F&SCM + private AI
AI for Dynamics 365 Finance and Supply Chain beyond Copilot
Short answer
Microsoft's own Copilot features in D365 Finance and Supply Chain Management are real but narrow, mostly summarization and drafting inside specific workspaces, and run through Microsoft's cloud AI services by default. A private LLM grounded on D365's data entities and OData/custom services can answer broader operational questions, run fully on-prem for the Local Business Data deployment option, and keep sensitive supply chain and financial data off a shared AI service where that matters.
- ERP
- Dynamics 365 Finance and Supply Chain Management, Dynamics 365 F&SCM Local Business Data (on-prem)
- Industries
- Manufacturing, Distribution, Electronics
- Written for
- CIO
Dynamics 365 Finance and Supply Chain Management is a capable, deeply configurable ERP, and Microsoft has been shipping Copilot features into it steadily: collections agent, forecast explanation, sales order description generation, and a handful of workspace-specific assistants. For a CIO evaluating what those features actually cover, the honest answer is that they are useful but narrow. They generally answer the question Microsoft chose to build a workflow for, not the operational question your supply chain planner or your controller actually has that day.
The gap shows up in two places. First, breadth: a planner who wants to ask "which purchase orders are at risk of missing their confirmed date given current vendor performance" or a controller who wants "summarize the variance drivers for this cost center this period" is outside what packaged Copilot workspaces cover, even though D365's data entities have everything needed to answer both. Second, data handling: standard Copilot features in D365 route through Microsoft's Azure OpenAI Service by default, which is appropriate for many companies but not for every regulated manufacturer, especially ones with defense, aerospace, or export-controlled customers who need a harder guarantee about where inference happens.
The architecture that answers both gaps is the same one that works for any modern ERP: connect to D365 through its OData v4 data entities or custom X++ services, ground a model (open-weight, run on infrastructure you control) on that data with a proper semantic layer, and build the specific question-answering or agent workflows your operations and finance teams actually need. For companies running the on-prem Local Business Data (LBD) deployment option of F&SCM specifically, this pattern extends naturally: the ERP is already on-prem, and the AI layer can be too, with no cloud dependency at all if that is the requirement.
This is not a rejection of Microsoft Copilot. Many D365 customers should use both: Copilot for the specific, well-supported workflows Microsoft built well (collections prioritization, for example), and a private, grounded AI layer for the broader operational and financial question-answering that Copilot does not cover and that sensitive data may not be appropriate to send to a shared cloud AI service in the first place.
What usually gets in the way
The problems we hear most from cio teams running Dynamics 365 Finance and Supply Chain Management.
Native Copilot covers specific workspaces, not general questions
Copilot features in D365 are built around particular workflows (collections, forecasting narratives); a planner or controller with a question outside those workflows still has no self-service answer.
Standard Copilot routes through Microsoft's cloud AI service
For manufacturers with defense, aerospace, or otherwise sensitive supply chain data, sending ERP context to Azure OpenAI Service by default is not always an acceptable data path, even with Microsoft's enterprise commitments.
Data entities are well-structured but underused for reporting
D365's OData data entities expose a huge amount of operational data cleanly, but most companies still rely on Power BI reports built ahead of time rather than ad hoc natural-language questions.
Supply chain exception handling is still largely manual
Purchase order delivery risk, vendor performance trends, and inventory exception review require a planner to actively dig through several workspaces rather than getting proactive, explained flags.
On-prem (Local Business Data) customers get less AI attention
Microsoft's newest Copilot capability generally targets the cloud SaaS deployment first; F&SCM Local Business Data customers on-prem or in their own Azure tenant need an AI approach that does not assume the cloud multi-tenant service.
Where AI earns its place in Dynamics 365 Finance and Supply Chain Management
Each use case names the ERP objects it reads or writes, so your ERP team can judge the integration effort before anyone commits budget.
Purchase order delivery risk flagging
An agent reads open purchase orders, confirmed delivery dates, and vendor performance history to flag POs at risk of missing their date, before it affects a production schedule.
Touches: PurchTable/PurchLine data entities, vendor performance history, VendTable
Outcome: Gives procurement earlier warning on at-risk POs than a manual weekly review would catch, without waiting for a late-delivery report.
Natural-language finance and cost center inquiry
A controller asks "what drove the variance in cost center 4100 this period" and gets an answer grounded in general ledger and cost accounting data entities, with the underlying transactions cited.
Touches: GeneralJournalEntry, LedgerJournalTrans data entities, cost center dimensions
Outcome: Reduces the time to get a first-pass variance explanation from a manual GL pull to a direct question, freeing the controller's time for judgment rather than data assembly.
Inventory and warehouse exception review
Warehouse and planning staff ask about on-hand, on-order, and allocated inventory for a specific item or site without navigating multiple D365 workspaces.
Touches: InventOnHand data entity, InventSum, Released Product data entities
Outcome: Faster inventory position answers for planners, particularly useful during month-end or a supply disruption when speed matters.
Production schedule and shop floor question-answering
Operations staff ask about production order status, routing progress, and resource load grounded in D365's manufacturing data entities.
Touches: ProdTable, ProdRoute, ProdBOM data entities
Outcome: Reduces the number of status requests routed to a scheduler, and gives shift supervisors a self-service answer instead.
Vendor and item master data quality checks
An agent scans vendor and item master data entities for inconsistencies (duplicate vendors, missing lead time data, inactive items still on open orders) and reports them for cleanup.
Touches: VendTable, EcoResReleasedProduct, PurchLine
Outcome: Surfaces master data issues that quietly degrade planning accuracy, ahead of a bigger data quality initiative.
Document intake for AP with 3-way match support
OCR and classify vendor invoices, propose a match against open purchase order and receiving data, and flag exceptions for an AP clerk to review.
Touches: VendInvoiceInfoTable, PurchLine, receiving data entities
Outcome: Cuts manual keying and matching effort on routine invoices while keeping exception handling in human hands.
On-prem grounded assistant for Local Business Data customers
For F&SCM customers running the on-prem LBD deployment specifically, a fully on-prem AI layer connects through the same OData/custom service endpoints without any cloud AI dependency.
Touches: F&SCM Local Business Data OData endpoints, custom X++ services
Outcome: Gives on-prem D365 customers the same class of AI capability as SaaS customers, without a cloud dependency they may not want or be able to accept.
Reference architecture
A private model grounded on D365 F&SCM's OData v4 data entities and custom X++ services, deployable fully on customer infrastructure for both cloud SaaS and Local Business Data on-prem installations, with any write-back proposed for human approval.
- 1
D365 connectors
OData v4 data entities for standard read access, custom X++ data entities or services for anything the standard set does not expose, authenticated via Azure AD (for SaaS) or the LBD equivalent for on-prem.
- 2
Semantic layer
A mapping of D365's data entity fields and dimension structure to business terms, accounting for the company's specific chart of accounts, dimension framework, and custom entity extensions.
- 3
Model serving
Open-weight models (Llama, Qwen, Mistral class) served via vLLM or Ollama, on customer-controlled infrastructure (on-prem GPU, private cloud VPC, or the customer's own Azure tenant with no shared Copilot dependency).
- 4
Retrieval and agents
Text-to-query against the OData layer for structured questions, exception-detection agents on a schedule for PO risk and inventory flags, RAG over documents for AP and vendor certificate intake.
- 5
Governance and audit
Every answer logged with the data entity and record it drew from; agent access scoped to match existing D365 security roles, with write actions requiring named human approval.
Integration notes for your ERP team
- Use OData v4 data entities as the primary read path; they are well-documented, versioned, and cover the vast majority of standard F&SCM tables without needing custom X++ development.
- For data not exposed by a standard entity, build a scoped custom data entity or service in X++ rather than granting the AI layer direct SQL access to the underlying AXDB/database, to preserve D365's business logic and validation.
- Authenticate via Azure AD app registration with a scoped service principal (for SaaS) or the appropriate on-prem authentication mechanism for Local Business Data, kept separate from interactive user logins for clean audit trails.
- Map the dimension framework (financial dimensions, cost centers, business units) carefully in the semantic layer; D365's dimension structure is highly configurable and varies significantly between implementations.
- For Local Business Data (on-prem) customers, confirm which OData and custom service endpoints are available in the on-prem topology, since some SaaS-only capabilities are not present in LBD.
- Respect D365's existing security role and duty structure when scoping agent access; do not create a new broad-access service account as a shortcut.
- Where Microsoft Copilot already covers a workflow well (collections prioritization, for example), integrate rather than duplicate: use the private AI layer for the gaps, not as a wholesale Copilot replacement.
Deployment options
Air-gapped on-prem
F&SCM Local Business Data (on-prem) customers, or SaaS customers whose supply chain data touches ITAR or other export-controlled contexts and needs full separation from any cloud AI service.
Model and agent logic run entirely on customer hardware, connecting to D365 (on-prem LBD or, over a controlled path, to the SaaS tenant's OData endpoints) with no data sent to Microsoft's Copilot service or any third-party AI API.
Private or sovereign cloud
Cloud SaaS D365 customers who want AI capability beyond Copilot but are comfortable with cloud economics, provided the model runs in infrastructure they control rather than a shared multi-tenant AI service.
Model serving in the customer's own Azure tenant or a dedicated VPC, connecting to D365's OData v4 endpoints over authenticated, audited calls.
Hybrid
CIOs wanting to pilot one use case (PO risk flagging, say) before deciding on the long-term hosting model or expanding to more of the supply chain and finance data.
Scoped pilot on a modest GPU or CPU footprint against a subset of data entities, same architecture, extended once the use case is validated.
Compliance and data control
How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.
ITAR / export control
For D365 customers with defense-adjacent supply chains, the AI layer runs entirely on infrastructure the company controls, with no data sent to a shared cloud AI service and access scoped to authorized US persons.
SOX / financial controls
Read-only access to general ledger and cost accounting data entities for inquiry use cases; any adjustment stays inside D365's own workflow and approval process, never a direct AI write.
GDPR / data residency (EU customers)
For EU-based D365 customers, model serving and any data replica can be kept within the required jurisdiction, independent of where Microsoft's own Copilot service processes data by default.
Data access scoping
AI agent access mirrors existing D365 security roles and duties, so a shop-floor question-answering tool does not surface finance or HR data the underlying role would not see.
Where Netray fits
ERPray
ERPray's ERP-agnostic connector architecture fits D365's OData v4 data entities directly, giving CIOs a grounded, cited question-answering layer across finance and supply chain without a from-scratch build.
Custom build
PO risk-flagging agents, master data quality scans, and document intake workflows tuned to a specific D365 configuration are typically custom builds layered on the ERPray connector.
How an engagement runs
Phase 1 . 2-3 weeks
Discovery
- -Inventory of available OData data entities and any custom entities needed for the target use case
- -Confirmed deployment topology (SaaS, Local Business Data, or hybrid) and authentication approach
- -Dimension and chart of accounts mapping for the semantic layer
- -Prioritized use case and success criteria
Phase 2 . 6-8 weeks
Pilot
- -Working connector and semantic layer for the pilot data domain (procurement, finance, or supply chain)
- -Model serving stood up on infrastructure matching the target deployment option
- -5-10 real user questions answered end to end with cited data entity sources
- -Pilot review with CIO and business sponsor
Phase 3 . 8-12 weeks
Production
- -Role-based access aligned to existing D365 security roles
- -Audit logging of all queries and any human-approved write actions
- -Exception-detection agents (PO risk, master data quality) validated against historical data
- -Runbook for IT to maintain the connector across D365 updates
Phase 4 . ongoing
Scale
- -Additional data domains (production, warehouse, AP) added to the semantic layer
- -Document intake and 3-way match workflows layered on the same infrastructure
- -Quarterly review of query patterns and Copilot-versus-private-AI use case allocation
Questions to ask any vendor, including us
A short list that separates real Dynamics 365 Finance and Supply Chain Management AI work from a chatbot demo.
- Does this route any of our D365 data through Microsoft's Azure OpenAI Service, or does the model run entirely on infrastructure we control?
- Does this work with our Local Business Data (on-prem) deployment, or only with cloud SaaS D365?
- How do you authenticate to D365, and how is that access scoped relative to our existing security roles?
- What happens where Microsoft Copilot already covers a workflow well, do you duplicate it or integrate with it?
- How do you handle our specific financial dimension and chart of accounts structure in the semantic layer?
- What exactly writes back to D365, and what stays read-only and human-approved?
- Can you show a real example of the OData query your system generated for a purchase order risk question?
- How do you keep the connector working across D365's regular platform updates?
Frequently asked questions
Is this different from Microsoft Copilot in Dynamics 365?
Yes. Microsoft's Copilot features in D365 F&SCM cover specific, well-defined workspaces (collections, forecast narratives) and route through Microsoft's Azure OpenAI Service by default. A private AI layer grounded on D365's OData data entities answers a broader range of operational and financial questions and can run entirely on infrastructure the customer controls.
Does this work with the on-prem Local Business Data deployment of D365 F&SCM?
Yes, and it is one of the strongest fits for this pattern. Local Business Data customers already run the ERP on-prem, and the AI layer can be deployed the same way, connecting through the available OData and custom service endpoints with no cloud AI dependency required.
Do we need custom development in D365 to support this?
Usually minimal. D365's standard OData v4 data entities cover most operational and financial reporting needs. Custom X++ data entities are only needed where standard entities don't expose a specific field or table the use case requires.
Will this write to our purchase orders or general ledger automatically?
Not by default. The standard design is read-only for question-answering and exception flagging, with any proposed action (rescheduling a PO, for example) requiring explicit human approval before it is entered into D365 through its own APIs.
How does this handle our custom financial dimensions?
Financial dimensions and chart of accounts structure are mapped explicitly during discovery, since D365's dimension framework is highly configurable and varies between implementations. This mapping is essential for accurate finance question-answering.
Can this run without any data going to a shared cloud AI service?
Yes. The model can run on customer-owned on-prem hardware or in a private, single-tenant cloud environment, with no data sent to Azure OpenAI Service or any other shared AI API. This is the standard approach for defense-adjacent or otherwise sensitive D365 deployments.
Does this replace Power BI reporting in D365?
No. Power BI remains well suited to pre-built dashboards and recurring reports. The AI layer complements it by answering ad hoc, plain-English questions that would otherwise require building a new report or pulling data manually.
Related guides
AI for Dynamics 365 Business Central, on-premises or SaaS, beyond Copilot
AI for Business Central beyond Copilot: grounded question answering over BC's data via OData and APIs, for on-premises and SaaS tenants alike.
AX 2012 + private AIAI for Dynamics AX 2012, Without the Forced Migration
Dynamics AX 2012 R3 left mainstream support in 2021. Add a private LLM over AX data now, use it to de-risk a future migration, without a forced move to D365.
Forecasting plus a reason whyAI Demand Forecasting for Manufacturers: Better Numbers and an Explanation Planners Can Trust
AI demand forecasting explains ERP forecast changes in plain language, flags exceptions for planners, and handles short-history SKUs without Excel overrides.
PO follow-up that does not wait on a personAI Purchase Order Automation: Supplier Follow-Up and Expedite Without a Buyer Chasing Email
AI drafts routine PO confirmation and expedite messages from open ERP order data, with a buyer approving every message and change before it goes out.
RAG + SQL + permissionsA Private LLM Grounded on Your ERP Data
How a private LLM answers questions on your ERP data: RAG plus text-to-SQL, role-based permissions inherited from the ERP, and where each fits.
AP automation + on-prem AIAI for accounts payable invoice matching in your ERP
On-prem AI reads vendor invoices, runs 3-way match against your ERP PO and receipt, and routes only real exceptions to your AP team. No invoice data leaves your network.
Plan it with numbers
ERP AI Copilot ROI Calculator
Turn user count, query volume, and time saved per question into a monthly savings, license cost offset, and payback period for an ERP AI copilot.
Free ToolOn-Prem AI ROI Calculator
Turn hours saved per employee into annual net benefit, payback months, and 3-year ROI for an on-prem AI investment.
Free ToolERP Data Quality for AI Assessment
Score item master, customer, vendor, and transaction data quality to find out whether your ERP is ready to ground an AI copilot, forecast, or chatbot.
GuideERP Copilots: Measuring Real User Productivity Gains
ERP copilots promise productivity, but what do users actually gain? Measured results, metrics that matter, and how to deploy copilots for SyteLine and LN.
GuideNatural Language Reporting Over Your ERP: A Guide
Build natural language reporting over your ERP the safe way: text-to-SQL guardrails, semantic layers, and why raw text-to-SQL fails on real ERP schemas.
GuideHybrid AI Architecture Patterns for Manufacturers
Hybrid AI architecture patterns for manufacturers: what runs on-prem vs cloud, data boundaries, latency budgets, and ITAR-safe designs that scale.
Talk it through with an engineer who knows Dynamics 365 Finance and Supply Chain Management
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.