# AI for Dynamics GP and NAV, Before the Business Central Decision > Source: https://netray.co/erp-ai/dynamics-gp-nav-ai-legacy > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: AI for ERP ## Short answer Microsoft has set an end date for Dynamics GP mainstream support, and Dynamics NAV has not received new feature investment for years, with most active development going to Business Central. A private LLM grounded in the GP or NAV SQL Server database gives finance and operations staff faster answers today, independent of when or whether a Business Central migration happens. ## Kind platform ## Erp Family microsoft ## Erp Products - Microsoft Dynamics GP - Microsoft Dynamics NAV ## Industries - Manufacturing - Distribution - Professional Services ## Region Global ## Persona Controller ## Eyebrow GP / NAV + private AI ## Intro Dynamics GP and Dynamics NAV run month-end close, inventory, and order processing for a large number of mid-market manufacturers and distributors, many of whom have no near-term appetite for a forced move to Business Central. Microsoft's messaging has been consistent for years: GP support has an end date, and NAV's active development moved to Business Central long ago, but that does not mean the installed base disappears on schedule. It means controllers and finance teams need a plan for getting more value out of GP or NAV in the meantime, not a plan that assumes the decision is already made. For a controller, the daily friction is rarely about the ERP roadmap. It is the time spent writing variance commentary from GL data, chasing down why a vendor invoice did not three-way match, or answering "what did we spend on X last quarter" questions that require someone to open Management Reporter, SmartList, or a NAV report and manually assemble the answer. A model grounded in the GP or NAV database can answer many of these directly, in plain language, without a new report being built. Both GP and NAV have accumulated years of Integration Manager jobs, eConnect customizations, Jet Reports or SmartList Builder configurations, and (for NAV) years of C/AL or AL object customizations that nobody has fully documented. Before any Business Central migration conversation goes anywhere, someone needs an honest inventory of what is actually load-bearing, and that inventory is exactly the kind of task a model that has read the customization objects and usage logs can accelerate. None of this requires waiting for the Business Central decision. A retrieval and drafting layer can run against the existing GP or NAV SQL Server database today, on the customer's own infrastructure, and the documentation it produces carries forward directly into a future migration scope, whether that migration happens next year or in five. ## Pain Points ### Finance answers questions by hand every month-end **Detail:** Controllers and staff accountants spend real close-cycle hours pulling GL detail and writing variance narratives that a model grounded in the same GP or NAV tables could draft in minutes. ### Nobody knows what the Integration Manager jobs actually do **Detail:** Years of eConnect and Integration Manager customizations in GP, or C/AL and AL objects in NAV, exist with little current documentation, making any change risky and any migration estimate unreliable. ### Support end dates create pressure without a funded plan **Detail:** GP's mainstream support end date and NAV's long-stalled feature development create urgency in leadership conversations, but budget for a full Business Central migration is rarely approved on the same timeline. ### SmartList and Jet Reports requests queue up behind IT **Detail:** Every new question finance or operations has turns into a report-building request, when many of those questions could be answered directly against the underlying data with a natural-language interface. ### Vendor and customer master data has drifted **Detail:** Years of manual entry and partial cleanups have left duplicate vendors, inconsistent terms, and stale customer records that any AI layer, or any migration, needs cleaned up or at least clearly flagged first. ## Use Cases ### Month-end variance commentary draft **Description:** The model drafts a first-pass explanation of budget-to-actual variance by GL account and department using GP or NAV general ledger detail, for the controller to review and edit before it goes into the close package. **Erp Objects:** GP: GL20000/GL30000 transaction tables, Management Reporter; NAV: G/L Entry, G/L Budget Entry tables **Outcome:** Cuts the drafting time for close commentary, letting the controller focus on review and judgment calls rather than first-draft writing. ### Natural-language finance and operations Q&A **Description:** Staff ask plain-English questions about vendor spend, customer aging, or inventory value instead of requesting a new SmartList, Jet Reports layout, or NAV report. **Erp Objects:** GP: SmartList data sources, RM/PM tables; NAV: Customer Ledger Entry, Vendor Ledger Entry, Item Ledger Entry **Outcome:** Answers routine ad hoc questions in minutes instead of a multi-day report request queue. ### AP three-way match exception explanation **Description:** For invoices that failed the three-way match, the model summarizes the discrepancy in plain language (quantity, price, or receipt mismatch) and drafts a note for the buyer or AP clerk to act on. **Erp Objects:** GP: POP10100/POP30300 purchase order tables; NAV: Purchase Line, Item Ledger Entry **Outcome:** Reduces the manual investigation time AP staff spend tracing why an invoice did not clear automatically. ### Integration Manager / eConnect job documentation **Description:** An agent reads Integration Manager job definitions and eConnect customization code and produces a plain-language summary of what each integration does, its source and target, and its trigger schedule. **Erp Objects:** Integration Manager job XML, eConnect stored procedures, SQL Agent job schedules **Outcome:** Produces a working integration inventory in place of tribal knowledge, ahead of any support or migration conversation. ### NAV C/AL and AL customization explainer **Description:** For NAV shops, the model reads customized C/AL or AL objects and explains what a given customization does and which base objects it modifies, before a developer has to trace it manually. **Erp Objects:** NAV object designer exports, C/AL code, AL extensions **Outcome:** Shortens the investigation time for an unfamiliar customization from hours of code reading to a reviewed first draft. ### Vendor and customer master data cleanup assistant **Description:** The model flags likely duplicate vendors or customers, inconsistent payment terms, and stale records based on GP or NAV master data patterns, for a controller-led cleanup pass. **Erp Objects:** GP: PM00200 vendor master, RM00101 customer master; NAV: Vendor, Customer tables **Outcome:** Gives finance a prioritized cleanup list instead of a manual, spreadsheet-driven review of thousands of records. ### Business Central migration readiness inventory **Description:** For shops actively considering the move, the model compiles which customizations, integrations, and reports are used regularly versus rarely, based on execution and access logs, to inform migration scope. **Erp Objects:** SQL Server query logs, Integration Manager job history, report execution history **Outcome:** Turns migration scoping from a guess into an evidence-based inventory, which typically reduces rework during the BC implementation. ## Architecture **Overview:** The model runs on customer-owned or private-cloud GPUs beside the existing GP or NAV SQL Server database. A read-only connector queries the transactional and master data tables directly; no change is required to the GP or NAV application layer, and no data leaves the customer's network. **Layers:** #### GP / NAV connectors **Detail:** Direct SQL Server read access to GP company databases or NAV database tables, plus optional export of Integration Manager job definitions and NAV object customizations for the documentation use cases. #### Data and semantic layer **Detail:** A mapping between GP's or NAV's table and field naming conventions and the business terms finance and operations actually use in conversation. #### Model serving **Detail:** An open-weight model served with vLLM or Ollama on customer GPU hardware, sized for a mid-market close cycle and query volume. #### Retrieval and agents **Detail:** Retrieval-augmented answers grounded in current GL, AP, and inventory data, plus draft-only agents for variance commentary and AP exception summaries that stop at a human review step. #### Governance and audit **Detail:** Every draft and answer is logged with its source query; the system is read-only against GP or NAV unless a controller explicitly approves any write-back. ## Deployment Options ### Air-gapped on-prem **Fit:** Controllers and IT directors who want the AI layer entirely inside existing infrastructure, with no new cloud dependency added to an already end-of-life-adjacent system. **Detail:** The model runs on GPU hardware on the same network as the GP or NAV SQL Server instance, with no outbound internet requirement after setup. ### Private or sovereign cloud **Fit:** Organizations that prefer not to add on-prem GPU hardware but still want GP or NAV data to stay inside a controlled, single-tenant environment. **Detail:** The model and retrieval layer run in a private VPC connected to the GP or NAV database over a secure link, under the customer's existing access controls. ### Hybrid **Fit:** Shops with a Business Central migration already planned, who want the AI layer's documentation work to carry forward into the new environment. **Detail:** The retrieval and documentation layer connects to GP or NAV now and can be extended or re-pointed to Business Central's data entities as the migration proceeds. ## Compliance ### GP or NAV data and AI query logs stay inside the customer's network or private cloud tenancy, inheriting existing SQL Server and application-level access controls rather than a separate permission scheme. **Framework:** Data residency and access control ### The AI layer is read-only for financial data and drafting; any actual GL posting or write-back still requires the same approval path GP or NAV already enforces, with the AI draft as an input, not an override. **Framework:** Financial controls and segregation of duties ### Every AI-drafted variance commentary or AP exception note is logged with its source data and reviewed by a named controller or AP lead before use. **Framework:** Audit trail ### Master data cleanup suggestions are flagged for human review and action, not applied automatically, keeping the controller in control of what changes in the vendor and customer masters. **Framework:** Data quality governance ## Integration Notes GP access is via direct SQL Server read queries against the company database(s); no change to GP's Dexterity application layer or eConnect runtime is required for the read-only use cases. NAV access is via SQL Server read queries for on-premises NAV installations, or the NAV/BC web services layer where available, depending on version. Integration Manager job XML and eConnect stored procedure code are read directly for the documentation use case, without interrupting scheduled integration runs. NAV C/AL and AL customization objects are exported via the object designer or extension source for the customization explainer, analyzed offline. Any write-back (a corrected GL entry, a flagged duplicate vendor merge) goes through GP's or NAV's normal posting and approval workflow, with a human required to execute it. Authentication follows the customer's existing Active Directory or SQL Server authentication; no separate identity system is introduced. Where Jet Reports or SmartList Builder configurations already define useful business logic, those definitions are read to seed the semantic layer rather than rebuilt from scratch. ## Product Fit ### ERPray **Why:** Natural-language question answering and dashboards grounded in the GP or NAV SQL Server data model, read-only by default, with the underlying query shown to the user. ### Custom build **Why:** The Integration Manager/eConnect and NAV C/AL customization explainers, and the migration readiness inventory, are GP/NAV-specific accelerators beyond generic ERP Q&A. ## Engagement ### Discovery **Duration:** 2-3 weeks **Deliverables:** - GP or NAV environment and customization inventory review - Priority use case selection with finance and IT - Data access plan and network architecture review ### Pilot **Duration:** 6-8 weeks **Deliverables:** - Working retrieval layer over GL, AP, and master data - One drafting agent (variance commentary or AP exceptions) in draft-only mode - Accuracy review against real close-cycle questions ### Production **Duration:** 4-6 weeks **Deliverables:** - Hardened deployment on customer GPU hardware or private cloud - Access controls aligned to existing GP or NAV security roles - Audit logging in place for every draft and answer ### Scale **Duration:** Ongoing **Deliverables:** - Additional use cases (customization explainer, master data cleanup) - Expanded data scope as adoption grows - Migration-readiness documentation ready if and when a Business Central move is funded ## Buyer Questions - Does this require any change to our GP or NAV application layer or database schema? - Where does the model run, and does any of our financial data leave our network? - How does the AI layer handle GP's Dexterity customizations or NAV's C/AL and AL objects specifically, versus a generic ERP connector? - What happens to the work we do here if we eventually migrate to Business Central? - Who reviews and approves an AI-drafted variance narrative before it goes into the close package? - How is data quality in our vendor and customer masters handled, given how much manual entry has accumulated? - Can we pilot on a single GL area or company before expanding scope? - What is the realistic infrastructure cost for our transaction volume and user count? ## Faq ### Is it worth adding AI to Dynamics GP given the support end date? **Answer:** Yes, for most controllers the practical value is in daily and close-cycle time savings that accrue regardless of when a Business Central migration happens. The system is read-only against GP's SQL Server database, so it adds no risk to an environment that is already being run conservatively. ### Does Dynamics NAV, which is no longer actively developed, still make sense for an AI layer? **Answer:** Yes, if NAV is still running production. A retrieval layer over NAV's SQL Server tables works the same way regardless of Microsoft's roadmap for the product, and the customization documentation it produces has direct value if a Business Central migration is eventually planned. ### Can AI draft our month-end variance commentary accurately? **Answer:** It can produce a grounded first draft based on the actual GL detail, which a controller then edits and approves. It replaces the blank-page writing task, not the judgment call on what the variance actually means for the business. ### How does this help if we eventually move to Business Central? **Answer:** The Integration Manager, eConnect, and C/AL/AL customization documentation this system produces becomes the evidence base for scoping a Business Central migration, distinguishing load-bearing customizations from dead code before the migration RFP is written. ### Is our financial data safe with an AI layer connected to GP or NAV? **Answer:** The model runs on customer-owned or private-cloud infrastructure inside the existing network boundary, is read-only by default, and any write-back still requires the same posting and approval workflow GP or NAV already enforces. ### What about the messy vendor and customer master data we've accumulated over the years? **Answer:** The system can flag likely duplicates and inconsistencies for a controller-led review, but it does not merge or change records automatically; a human decides what gets cleaned up and when. ### How long does a GP or NAV AI pilot take? **Answer:** A focused pilot on one area, typically AP or GL variance commentary, over 6-8 weeks is enough to validate accuracy and value before expanding to additional finance and operations use cases. ## Search terms Dynamics GP AI, Dynamics NAV AI, Dynamics GP AI integration, on-prem AI for Dynamics GP, Dynamics GP copilot, Dynamics NAV generative AI, Dynamics GP legacy AI, Dynamics GP end of support AI, NAV to Business Central migration AI, Dynamics GP private LLM, SmartList AI alternative, Dynamics NAV C/AL documentation AI --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json