I've been exploring different approaches to connecting LLMs to Acumatica, particularly around how AI can query ERP data dynamically without requiring administrators to anticipate and configure every possible reporting scenario.
With Acumatica's native MCP server in 26R2, administrators can expose selected, published Generic Inquiries as read-only tools for external AI clients. This provides a controlled way for an LLM to retrieve and analyze ERP data while maintaining Acumatica's existing security model.
However, there are also MCP-based integration architectures that support natural-language queries across Acumatica modules, execute queries against the ERP through authorized connections, and return results directly to the LLM or as refreshable Excel reports.
What interests me is the architectural difference between these approaches, particularly when the AI needs information that hasn't already been modeled in a predefined GI.
1. Dynamic querying vs. predefined Generic Inquiries
Consider a request such as:
"Compare revenue by customer for the last two financial quarters, identify the largest changes, and break down the results by branch."
With a predefined GI-based approach, the necessary data and relationships must already be available through the tools exposed to the LLM.
A more dynamic query architecture could potentially provide greater flexibility by constructing queries based on the user's request and retrieving data through an authorized integration layer.
The important distinction here is that dynamically executing a query is not necessarily the same as having AI create and save a new Generic Inquiry within Acumatica.
I'm interested in whether dynamic query generation could reduce the need to maintain numerous AI-specific GIs, or whether the additional flexibility introduces more complexity than it solves.
A few technical considerations come to mind:
-
Data relationships: How does the integration determine which data sources, fields, and relationships are appropriate for a particular request?
-
Business logic: How do we ensure that calculated balances, inventory quantities, costs, and margins remain consistent with Acumatica's application logic?
-
Customizations: How reliably can a dynamic query approach accommodate customized DACs, fields, and business processes?
-
Performance: What controls should exist around query complexity, result-set sizes, and execution frequency?
-
Accuracy: How do we validate that the AI retrieved and interpreted the correct data, rather than producing a technically valid but misleading result?
Predefined GIs have the advantage of allowing an administrator to establish and validate these relationships before exposing them to an AI client.
The question is whether a more dynamic approach can achieve comparable reliability without requiring every inquiry to be designed ahead of time.
2. Governed dynamic access vs. unrestricted access
Another important distinction is that dynamic querying does not inherently require unrestricted access to Acumatica.
An integration can authenticate through an established Acumatica connection and operate within the permissions assigned to that connection.
That creates an interesting architectural question.
If an AI integration already operates within Acumatica's existing access controls, how much additional governance should be imposed at the AI tool level?
For example, should an LLM be able to query any data accessible to its authenticated connection, or should administrators still explicitly define which data sources and operations are available to AI?
I'm particularly interested in how others approach the principle of least privilege when an LLM can formulate queries that weren't explicitly anticipated during configuration.
There are also questions about field-level restrictions, sensitive data exposure, query logging, and the ability to audit exactly what information was retrieved.
3. Dynamic data access and controlled writeback
The discussion gets more interesting when we move beyond read-only reporting.
Some MCP-based AI integration architectures also support ERP write operations, including creating or updating records, working with attachments, executing import scenarios, and invoking supported application actions.
These capabilities require appropriate Acumatica permissions and integration-level configuration.
For example, consider asking an LLM to:
"Find the open sales orders for this customer and add an internal note to the applicable orders."
At that point, the integration is no longer simply retrieving data. It's initiating changes within Acumatica.
That introduces another set of technical questions:
-
Are operations executed through Acumatica's supported application interfaces and associated business logic?
-
How are field validations, document status restrictions, and other application controls enforced?
-
How are partial failures handled when an AI request involves multiple operations?
-
What level of user confirmation should be required before executing a write operation?
-
How should AI-initiated changes be audited and distinguished from ordinary user activity?
I see considerable potential here, but the distinction between retrieving information and initiating ERP transactions becomes critical.
4. Is this really an MCP comparison?
One important point is that MCP itself isn't the differentiator.
Both a predefined GI-based integration and a dynamically querying integration can use Model Context Protocol.
MCP standardizes how AI applications discover and invoke tools, but the capabilities available to an LLM depend on the tools exposed by the server and the permissions enforced by the underlying integration.
Acumatica's native 2026 R2 MCP implementation currently provides read-only access through selected Generic Inquiries.
Other MCP-based architectures can expose different operations, including dynamic querying and controlled writeback, depending on their implementation.
So the more meaningful comparison may be:
Predefined, validated data-access tools versus a governed dynamic query layer that operates within Acumatica's existing permissions.
Neither approach is inherently more secure or accurate simply because of its use of MCP. Those characteristics depend on the implementation, available operations, access controls, and validation mechanisms.
5. Where should we draw the line?
I see significant value in allowing users to ask unanticipated business questions without requiring an administrator to create a separate GI for every possible use case.
At the same time, predefined GIs provide a known structure for data relationships, calculations, security, and performance.
Perhaps the better approach isn't choosing one exclusively, but determining whether a hybrid model makes sense.
For example, could validated GIs remain the preferred source for established financial and operational calculations, while a governed dynamic query layer handles more exploratory or ad hoc requests?
And where would actual AI-assisted GI creation fit into that architecture, particularly if dynamically generated queries could be reviewed, validated, and saved for reuse?
I'm curious how others in the community are thinking about this.
Is governed dynamic querying the logical next step for AI in Acumatica, or does the predictability of predefined GIs outweigh the additional flexibility?
For those working with MCP, custom integrations, or AI-assisted reporting, what technical safeguards would you consider essential before allowing an LLM to dynamically query ERP data beyond a predefined set of inquiries?
