Microsoft DynamicsERP Platform

GP / NAV + private AI

AI for Dynamics GP and NAV, Before the Business Central Decision

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.

ERP: Microsoft Dynamics GP, Microsoft Dynamics NAV
Industries: Manufacturing, Distribution, Professional Services
Written for: Controller

Discuss your Microsoft Dynamics GP environment See use cases

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.

What usually gets in the way

The problems we hear most from controller teams running Microsoft Dynamics GP.

Finance answers questions by hand every month-end

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

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

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

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

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.

Where AI earns its place in Microsoft Dynamics GP

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

Month-end variance commentary draft

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.

Touches: 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

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.

Touches: 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

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.

Touches: 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

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.

Touches: 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

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.

Touches: 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

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.

Touches: 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

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.

Touches: 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.

Reference architecture

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.

1
GP / NAV connectors
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.
2
Data and semantic layer
A mapping between GP's or NAV's table and field naming conventions and the business terms finance and operations actually use in conversation.
3
Model serving
An open-weight model served with vLLM or Ollama on customer GPU hardware, sized for a mid-market close cycle and query volume.
4
Retrieval and agents
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.
5
Governance and audit
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.

Integration notes for your ERP team

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.

Deployment options

Air-gapped on-prem

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.

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

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.

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

Shops with a Business Central migration already planned, who want the AI layer's documentation work to carry forward into the new environment.

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 and data control

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

Data residency and access control

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.

Financial controls and segregation of duties

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.

Audit trail

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.

Data quality governance

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.

Where Netray fits

ERPray

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

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.

How an engagement runs

Phase 1 . 2-3 weeks

Discovery

-GP or NAV environment and customization inventory review
-Priority use case selection with finance and IT
-Data access plan and network architecture review

Phase 2 . 6-8 weeks

Pilot

-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

Phase 3 . 4-6 weeks

Production

-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

Phase 4 . Ongoing

Scale

-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

Questions to ask any vendor, including us

A short list that separates real Microsoft Dynamics GP AI work from a chatbot demo.

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?

Frequently asked questions

Is it worth adding AI to Dynamics GP given the support end date?

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?

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?

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?

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?

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?

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?

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.

Related guides

Business Central + private AI

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 AI

AI 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.

ERP AI Cost Guide

What ERP AI Actually Costs: A CFO's Guide

A CFO's guide to what ERP AI actually costs: GPU hardware, model licensing, integration and connector work, and realistic ongoing run-rate ranges.

ERP AI business case

Building the ROI Business Case for ERP AI in Manufacturing

How to build a defensible ERP AI business case: benefit mechanisms instead of vague productivity claims, cost structure, payback period, and sensitivity analysis.

RAG + SQL + permissions

A 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.

D365 F&SCM + private AI

AI for Dynamics 365 Finance and Supply Chain beyond Copilot

AI for D365 Finance and Supply Chain beyond Microsoft Copilot: private LLM grounded on data entities and OData, on-prem-capable via Local Business Data.

Plan it with numbers

Free Tool

Talk it through with an engineer who knows Microsoft Dynamics GP

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.

Start the conversation See ERPray

All AI for ERP guides