# Natural Language Query for ERP Data: Ask SAP, Infor, or Oracle a Question in Plain English > Source: https://netray.co/erp-ai/natural-language-query-erp > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: AI for ERP ## 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. ## Kind use-case ## Erp Family multi-erp ## Erp Products - SAP S/4HANA - Infor SyteLine - Infor LN - Oracle E-Business Suite - NetSuite - Dynamics 365 Finance & Supply Chain ## Industries - Manufacturing - Distribution - Aerospace - Defense - Electronics ## Region Global ## Persona Finance Director ## Eyebrow Ask your ERP anything ## Intro 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. ## Pain Points ### Report-writer bottleneck **Detail:** 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 **Detail:** 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 **Detail:** 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 **Detail:** 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 **Detail:** 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. ## Use Cases ### AP aging by vendor **Description:** A finance analyst asks how much is owed to a specific vendor past 60 days without waiting on a scheduled report. **Erp Objects:** 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 **Description:** A controller asks why a specific G/L account moved materially month over month, ahead of the close variance call. **Erp Objects:** 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 **Description:** Sales operations checks the status of a customer's open orders while the customer is still on the phone. **Erp Objects:** 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 **Description:** A planner asks for on-hand, allocated, and on-order quantity for an item across every plant in one question. **Erp Objects:** 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 **Description:** Procurement pulls a ranked list of late purchase order lines each morning without rerunning and re-filtering the same saved report. **Erp Objects:** 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 **Description:** FP&A answers a CFO's ad hoc headcount or labor cost question during a meeting instead of promising a follow-up email. **Erp Objects:** 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 **Description:** A quality or finance leader asks whether nonconformance volume by supplier is trending up ahead of the monthly quality report cycle. **Erp Objects:** 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. ## Architecture **Overview:** 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. **Layers:** #### ERP connectors **Detail:** 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. #### Data and semantic layer **Detail:** 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. #### Model serving **Detail:** 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. #### Query generation and retrieval **Detail:** 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. #### Governance and audit **Detail:** 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. ## Deployment Options ### Air-gapped on-prem **Fit:** Finance teams under strict data-residency or audit requirements that cannot send GL or vendor data anywhere outside their own network. **Detail:** 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 **Fit:** Teams that want to avoid GPU procurement but still keep the deployment single-tenant and outside public model APIs. **Detail:** 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 **Fit:** Organizations phasing AI in: pilot in private cloud, then move to on-prem once the use case is proven and GPU budget is approved. **Detail:** The pilot runs in a private cloud tenant, and model serving migrates on-prem once volume or compliance requirements justify the capex. ## Compliance ### 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. **Framework:** SOX financial controls ### Query permissions mirror existing ERP roles table by table, so the system cannot surface data a user's ERP role would not already permit. **Framework:** Segregation of duties ### 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. **Framework:** GDPR and data residency ### 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. **Framework:** Internal data classification ## Integration Notes - 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. ## Product Fit ### ERPray **Why:** 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. ## Engagement ### Discovery **Duration:** 2-3 weeks **Deliverables:** - 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 ### Pilot **Duration:** 6-8 weeks **Deliverables:** - 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 ### Production **Duration:** Ongoing **Deliverables:** - 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 ### Scale **Duration:** Ongoing **Deliverables:** - 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 ## Buyer Questions - 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? ## Faq ### Is natural language query over ERP data accurate enough to trust for financial reporting? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms natural language query ERP, text to SQL ERP, ask ERP questions in plain English, ERP AI query tool, on-prem AI for ERP reporting, ERP copilot for finance, ERP generative AI, natural language BI ERP, SAP natural language query, NetSuite AI query, ERP chatbot finance, text-to-SQL governance, grounded LLM ERP data, ERP self-service reporting AI --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json