Any ERPUse Case

Ask your ERP anything

Natural Language Query for ERP Data: Ask SAP, Infor, or Oracle a Question in Plain English

Short answer

Natural language query over ERP data works by translating a question into a governed SQL or API call against your SAP, Infor, Oracle, or NetSuite database, then returning the result with the underlying query shown. Done well, it runs read-only, respects existing ERP roles table by table, and never lets a model touch production data unsupervised. Netray builds this as ERPray, deployed on-prem or in a private cloud so the questions and the data never leave your boundary.

ERP: SAP S/4HANA, Infor SyteLine, Infor LN, Oracle E-Business Suite, NetSuite, Dynamics 365 Finance & Supply Chain
Industries: Manufacturing, Distribution, Aerospace, Defense, Electronics
Written for: Finance Director

Discuss your SAP S/4HANA environment See use cases

If you run finance for a manufacturer or distributor, a large share of your week probably goes into ad hoc report requests: someone needs AP aging by vendor for a board deck, someone else wants a variance explanation before the close call, and every one of those requests becomes a ticket to a report writer or BI team with a multi-day turnaround, even though the answer is sitting in a table your ERP already has.

The obvious fix, giving analysts a general-purpose AI chatbot, usually fails the first time it matters. A model answering from memory or from a loosely connected export has no way to know your chart of accounts, your GL account mapping, or which numbers are final versus in-process, and a wrong number in a board deck is not a risk finance can absorb to save a few hours.

A grounded natural language query system works differently. It translates the question into a constrained SQL or OData call against a mapped, permissioned view of your real schema, whether that is SAP's ACDOCA line items, SyteLine's ap_invoice and gl_detail tables, or Oracle EBS's GL_JE_LINES, runs it read-only against the actual data, and returns the result alongside the exact query it used, so the answer can be checked the same way you would check a report writer's output.

In production, that changes what your day looks like. An analyst types 'show me AP aging over 60 days by vendor for Q3' and gets a table back in seconds, with the query visible for anyone who wants to verify it, instead of filing a request and waiting. The report-writer backlog does not disappear, but the long tail of one-off questions stops competing for the same queue.

What usually gets in the way

The problems we hear most from finance director teams running SAP S/4HANA.

Report-writer bottleneck

Every ad hoc finance question becomes a ticket to the BI or reporting team, with a turnaround measured in days rather than minutes, even for questions that only need one or two tables.

Frozen database access

Giving finance analysts direct SQL access to the production ERP database is a change-control and security risk nobody wants to own, so the alternative is waiting in line behind everyone else's requests.

Spreadsheet sprawl

Analysts export to Excel and rebuild logic the ERP already has, creating version drift between what finance reports and what the system of record actually says at close.

Public LLM exposure risk

Pasting GL detail, vendor names, or customer numbers into a public chatbot to get help drafting a query is a data exposure nobody signed off on, and it happens more often than most finance leaders assume.

No trust without a visible query

Even where a chatbot exists, if it cannot show the source table, the filter logic, and the as-of date behind an answer, finance will not put that number in front of the CFO or the board.

Where AI earns its place in SAP S/4HANA

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

AP aging by vendor

A finance analyst asks how much is owed to a specific vendor past 60 days without waiting on a scheduled report.

Touches: SAP FBL1N vendor line items / BSEG, SyteLine ap_invoice and ap_voucher, Oracle EBS AP_INVOICES_ALL

Outcome: Analyst gets the answer in the time it takes to type the question instead of filing a report request.

GL variance drill-down for close

A controller asks why a specific G/L account moved materially month over month, ahead of the close variance call.

Touches: SAP ACDOCA / CO-PA line items, SyteLine gl_detail, Oracle GL_JE_LINES

Outcome: Cuts the first pass of close variance commentary from a half day of manual pivoting to a few targeted questions.

Open order and backlog snapshot

Sales operations checks the status of a customer's open orders while the customer is still on the phone.

Touches: SAP VBAK/VBAP sales orders, SyteLine co_ohdr and co_itemw, NetSuite SuiteQL saved searches

Outcome: Sales ops answers the where-is-my-order question on the call, not in a follow-up email.

Inventory position across plants

A planner asks for on-hand, allocated, and on-order quantity for an item across every plant in one question.

Touches: SAP MARD/MCHB, SyteLine im_itemwhse, Infor LN whinh

Outcome: Planners see the combined position in one query instead of exporting three reports and joining them in Excel.

Overdue PO follow-up list

Procurement pulls a ranked list of late purchase order lines each morning without rerunning and re-filtering the same saved report.

Touches: SAP EKKO/EKPO, SyteLine po_ohdr and po_itemw

Outcome: Procurement starts the day with a ready list instead of manually rebuilding the filter each time.

Headcount and labor cost by cost center

FP&A answers a CFO's ad hoc headcount or labor cost question during a meeting instead of promising a follow-up email.

Touches: SAP HCM infotypes and CO cost center reports, Dynamics 365 F&SCM data entities

Outcome: FP&A answers in the room instead of deferring the question to next week.

Quality hold and NCR volume trend

A quality or finance leader asks whether nonconformance volume by supplier is trending up ahead of the monthly quality report cycle.

Touches: SyteLine qcs_nc_main, SAP QM notifications (QMEL), Infor LN quality sessions

Outcome: Spots a rising trend without waiting on the next scheduled quality report.

Reference architecture

The pattern is the same across ERPs: read the schema through an existing API or a read replica, map it to business terms and permissions, generate a constrained query rather than free-text SQL, execute it read-only, and log everything, so the system can be audited the same way a human-written report would be.

1
ERP connectors
Read-only access via SAP OData/CDS views, Infor IDOs, Oracle EBS reporting views, or NetSuite SuiteQL pulls schema and data without touching the OLTP write path.
2
Data and semantic layer
Maps raw tables to business terms, such as vendor, cost center, or work order, so the model queries an 'AP aging' concept rather than reconstructing BSEG joins from scratch, and mirrors row and column-level permissions from ERP roles.
3
Model serving
An open-weight model in the Llama, Qwen, or Mistral class is served with vLLM or Ollama on customer-owned or private-cloud GPUs, so no question or answer is sent to a public model API.
4
Query generation and retrieval
Translates the question into a constrained SQL or OData call against approved views only, executes it read-only, and returns the result together with the generated query for audit.
5
Governance and audit
Every question, generated query, and result is logged and tied to the requesting user's existing ERP role, so nobody sees data they could not already see inside the ERP itself.

Integration notes for your ERP team

SAP: exposed through OData or CDS views with existing SAP authorization objects respected, using a read-only technical user, not a direct table dump.
Infor SyteLine: read access via IDO where available, falling back to a read replica for heavier reporting tables so the transactional database is never queried directly.
Oracle EBS: uses public reporting views and existing GL security rules rather than direct APPS schema access.
NetSuite: SuiteQL and saved searches respect role-based record permissions already configured in NetSuite.
The connection is typically to a read replica or a reporting instance, not the transactional primary, to avoid any load or locking impact.
Question and answer logs are retained under the customer's own document retention policy and are never sent to a third-party model provider.

Deployment options

Air-gapped on-prem

Finance teams under strict data-residency or audit requirements that cannot send GL or vendor data anywhere outside their own network.

The model, semantic layer, and query engine run on GPU hardware inside the customer's data center, with no outbound calls to a model API.

Private or sovereign cloud

Teams that want to avoid GPU procurement but still keep the deployment single-tenant and outside public model APIs.

The same architecture runs inside the customer's own cloud tenant, whether Azure, AWS, or a sovereign provider, with no data shared across tenants.

Hybrid

Organizations phasing AI in: pilot in private cloud, then move to on-prem once the use case is proven and GPU budget is approved.

The pilot runs in a private cloud tenant, and model serving migrates on-prem once volume or compliance requirements justify the capex.

Compliance and data control

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

SOX financial controls

Every generated query and its result are logged, giving internal and external auditors a testable record of how a reported number was produced, which supports SOX 404 evidence requests.

Segregation of duties

Query permissions mirror existing ERP roles table by table, so the system cannot surface data a user's ERP role would not already permit.

GDPR and data residency

For global operations, on-prem or in-region private cloud deployment keeps EU personal and financial data from crossing borders through a third-party model API.

Internal data classification

Tables and fields already tagged as restricted under the customer's own data classification scheme are excluded from the semantic layer by default, not opted out after the fact.

Where Netray fits

ERPray

ERPray is built for exactly this: grounded question answering and dashboards over live ERP data, read-only by default, with the underlying query always visible.

How an engagement runs

Phase 1 . 2-3 weeks

Discovery

-Inventory of report requests and BI tickets over the past quarter
-Mapping of the 15-20 highest-frequency finance questions to source tables
-Review of existing ERP roles for permission mapping
-Data classification pass on candidate tables

Phase 2 . 6-8 weeks

Pilot

-Semantic layer covering the pilot scope
-Model serving stood up on-prem or in a private cloud
-15-20 pilot questions answered end to end with the generated query shown
-Finance user acceptance testing

Phase 3 . Ongoing

Production

-Expanded question coverage beyond the pilot set
-Role-based access wired to live ERP security tables or groups
-Monitoring and a searchable query audit log
-Training for the finance team

Phase 4 . Ongoing

Scale

-Additional modules or domains, such as procurement or quality, added to the semantic layer
-Dashboards built on top of the same semantic layer
-Agent workflows added where write-back is wanted, with approval gates

Questions to ask any vendor, including us

A short list that separates real SAP S/4HANA AI work from a chatbot demo.

Does the tool execute against a read-only replica or API, or does it touch the production transactional database directly?
Can it show the exact query it ran against which table, for every answer, not just a summary?
How does it map to our existing ERP roles, and can a user get data their ERP role would not otherwise permit?
Where does the model run, and does any question or ERP data leave our network or tenant?
How is a wrong or hallucinated answer caught before it reaches a report or a board deck?
What happens when a question cannot be answered from the mapped schema, does it guess or say so?
What is the audit trail retention, and can our external auditors review it during SOX testing?
How much of the semantic layer carries over if we later add another ERP module or a second ERP instance?

Frequently asked questions

Is natural language query over ERP data accurate enough to trust for financial reporting?

Accuracy depends on grounding, not the model alone. A system that translates questions into constrained SQL against a mapped, permissioned schema and shows its generated query is verifiable in a way a free-text chatbot answer is not. Treat early outputs the way you would a new report writer's first drafts: spot-check against known totals during the pilot, then trust the pattern once it holds.

Does this replace our BI tool or reporting team?

No. It handles the long tail of ad hoc, one-off questions that do not justify a formal report, and it reduces the backlog feeding the BI team. Recurring, board-level reports still belong in your BI tool or ERP reporting module, where formatting and version control matter.

Can it write data back to the ERP, not just answer questions?

The question-answering layer is read-only by default. Write-back, such as updating a PO or closing a work order, is a separate agent capability that requires an explicit approval step and is scoped module by module, not enabled by default.

How does this differ from the AI features SAP, Infor, or Oracle are shipping natively?

Vendor copilots such as Joule, Infor GenAI, or Oracle AI are tied to that vendor's cloud roadmap and typically assume you are on their latest release. A private deployment sits beside your ERP, works the same way whether you are on SAP, Infor, or a mix after an acquisition, and keeps model choice and data location under your control.

What does grounding actually mean in practice?

The model does not answer from its training data. It generates a query against your real schema, the query runs against your actual ERP data, and the result plus the query are returned together, so the answer is only as good as your data, not the model's memory.

We are on multiple ERPs after an acquisition. Does this work across all of them?

Yes, that is a common starting point. The semantic layer maps to each ERP's schema separately behind one question interface, so 'show me AP aging' works whether that vendor's invoices live in SAP or in the acquired company's NetSuite instance.

How long before finance sees value?

Most pilots cover the highest-frequency 15-20 questions from the existing report-request backlog within 6-8 weeks, which is usually enough to show a measurable drop in report-writer ticket volume before deciding on a wider rollout.

Related guides

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.

Agents + approval gates

AI Agents for ERP, Running On-Prem

A practical guide to on-prem AI agents for ERP: what they can safely automate, where human approval belongs, and how to design the guardrails.

Infor SyteLine / CSI + AI

AI for Infor SyteLine and CloudSuite Industrial

Add grounded AI to Infor SyteLine or CloudSuite Industrial: natural-language answers, agents over IDOs and ION, on-prem or CloudSuite deployment.

SAP S/4HANA + private AI

AI for SAP S/4HANA, Running On-Prem or in Your Private Cloud

Run AI on SAP S/4HANA without sending ERP data to a public API. On-prem and private-cloud architecture, CDS views, OData, and honest deployment trade-offs.

ERP AI readiness

Is Your ERP Ready for AI? A Readiness Assessment Checklist

Is your ERP actually ready for AI? A practical checklist covering master data quality, access and permissions, GPU sizing, and governance before you fund a pilot.

CFO + finance close + on-prem AI

AI for the ERP Month-End Close: Variance Commentary Without the All-Nighter

AI for the ERP month-end close: draft variance commentary, flag journal entry anomalies, and speed audit support, grounded in the general ledger, reviewed by finance before anything posts.

Plan it with numbers

Free Tool

Talk it through with an engineer who knows SAP S/4HANA

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