# AI for Dynamics 365 Finance and Supply Chain beyond Copilot > Source: https://netray.co/erp-ai/dynamics-365-finance-supply-chain-ai-on-prem > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: AI for ERP ## 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. ## Kind platform ## Erp Family microsoft ## Erp Products - Dynamics 365 Finance and Supply Chain Management - Dynamics 365 F&SCM Local Business Data (on-prem) ## Industries - Manufacturing - Distribution - Electronics ## Region Global ## Persona CIO ## Eyebrow D365 F&SCM + private AI ## Intro 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. ## Pain Points ### Native Copilot covers specific workspaces, not general questions **Detail:** 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 **Detail:** 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 **Detail:** 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 **Detail:** 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 **Detail:** 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. ## Use Cases ### Purchase order delivery risk flagging **Description:** 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. **Erp Objects:** 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 **Description:** 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. **Erp Objects:** 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 **Description:** Warehouse and planning staff ask about on-hand, on-order, and allocated inventory for a specific item or site without navigating multiple D365 workspaces. **Erp Objects:** 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 **Description:** Operations staff ask about production order status, routing progress, and resource load grounded in D365's manufacturing data entities. **Erp Objects:** 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 **Description:** 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. **Erp Objects:** 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 **Description:** OCR and classify vendor invoices, propose a match against open purchase order and receiving data, and flag exceptions for an AP clerk to review. **Erp Objects:** 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 **Description:** 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. **Erp Objects:** 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. ## Architecture **Overview:** 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. **Layers:** #### D365 connectors **Detail:** 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. #### Semantic layer **Detail:** 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. #### Model serving **Detail:** 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). #### Retrieval and agents **Detail:** 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. #### Governance and audit **Detail:** 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. ## Deployment Options ### Air-gapped on-prem **Fit:** 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. **Detail:** 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 **Fit:** 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. **Detail:** 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 **Fit:** 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. **Detail:** 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 ### 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. **Framework:** ITAR / export control ### 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. **Framework:** SOX / financial controls ### 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. **Framework:** GDPR / data residency (EU customers) ### 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. **Framework:** Data access scoping ## Integration Notes 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. ## Product Fit ### ERPray **Why:** 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 **Why:** 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. ## Engagement ### Discovery **Duration:** 2-3 weeks **Deliverables:** - 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 ### Pilot **Duration:** 6-8 weeks **Deliverables:** - 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 ### Production **Duration:** 8-12 weeks **Deliverables:** - 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 ### Scale **Duration:** ongoing **Deliverables:** - 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 ## Buyer Questions - 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? ## Faq ### Is this different from Microsoft Copilot in Dynamics 365? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms Dynamics 365 Finance and Supply Chain AI, D365 F&SCM AI integration, on-prem AI for Dynamics 365, D365 AI beyond Copilot, Dynamics 365 Local Business Data AI, D365 private LLM, Dynamics 365 supply chain AI agents, D365 generative AI, Dynamics 365 OData AI, D365 on-prem AI integration, Dynamics 365 copilot alternative, Microsoft Dynamics AI on-prem --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json