What is grounded ERP AI?
Grounded ERP AI defined: four testable properties — per-account dictionary, schema validation, shown queries, refusal — and how to test a vendor on each.
Grounded ERP AI is AI that answers questions about your ERP using only your own account's schema and data, and can prove it. It has four testable properties: queries are generated from a per-account data dictionary, validated against the real schema before they run, shown to you in full, and refused when the answer is not knowable.
Key takeaways
- Grounded ERP AI has four properties: grounded in a per-account dictionary, validated against the real schema before execution, verifiable through a shown query, and bounded by refusal.
- All four are testable in a ten-minute demo. If a vendor can only demonstrate three, ask which one is missing and why.
- "Connected to your ERP" is not the same claim as "grounded in your ERP". A connection gives access; grounding constrains what can be generated.
- Grounding is stricter than retrieval-augmented generation, because ERP answers require computation over live rows rather than retrieval of relevant text.
- Grounding removes invented fields. It does not remove ambiguous intent or repair bad source data, which is why the shown query still matters.
Every AI-over-ERP product now says it is grounded. The word is doing no work, because nobody has said what would have to be true for it to be false. This page defines grounded ERP AI as four properties you can test, in a demo, in ten minutes — and says plainly what grounding still does not fix.
- Grounded ERP AI
- An AI system that answers questions about a specific ERP account using only that account's actual schema and data, and exposes its work. Four properties make it testable: grounded — every query is generated from a per-account data dictionary; validated — every query is checked against the real schema before it executes; verifiable — the exact query is shown with the answer; bounded — the system refuses when the question falls outside what it knows.
The four properties of grounded ERP AI
Each property is a constraint on what the system is permitted to produce, not a claim about how clever it is. That is the point. Cleverness is unfalsifiable in a demo; constraints are not.
| Property | What it requires | How to test it | Failure signal |
|---|---|---|---|
| Grounded | Queries are generated from an inventory of your account: record types, all fields including custom, real join paths, observed status values, row counts. | Ask a question that depends on one of your custom fields, using your own label for it. | It answers using a standard field instead, or produces a field name that looks like yours but isn't. |
| Validated | Every generated query is checked against the real schema — tables, columns, join paths, status literals — before it is allowed to run. | Ask for something that sounds reasonable but has no field behind it, like a promised delivery date you don't record. | You get a number anyway, or an ERP error surfaced as a chat error rather than a caught validation failure. |
| Verifiable | The exact query is shown with the answer, in full, in a form you can read and re-run yourself. | Ask "show me the query" for any answer, then read the WHERE clause. | A paraphrase of "reasoning", a partial snippet, or "the logic is proprietary". |
| Bounded | Questions outside the dictionary, outside the connected role's permissions, or outside a defined metric get a refusal with a reason. | Ask for data the connected role cannot see, or a metric you have never defined for it. | A confident best effort. Anything other than a refusal tells you what happens when it doesn't know. |
Grounded: the dictionary comes first
Grounding means the system reads your account before it answers anything, and generates queries from what it found rather than from what it remembers about ERPs in general. The inventory it builds is a per-account data dictionary: every record type with row counts, every field including custom ones with their types and labels, the join paths that actually exist, and the status values that actually occur in your data rather than the ones in a manual.
The consequence is structural. If a field is not in the dictionary, it cannot appear in a generated query. That is a different guarantee from instructing a model not to invent fields, which is a request rather than a constraint. It is also why grounding is per account and not per product: two companies on the same ERP have different dictionaries, and an answer that is correct in one is wrong in the other.
Validated: check before you execute
Generation and execution must be separated by a validation step. Before a query touches your ERP, it is parsed and checked: do these tables exist, do these columns exist on these tables, is this join path real, does this status literal appear in the observed domain, is this query read-only. Anything that fails is rewritten or refused.
This step is what converts the worst failure mode into the mildest one. Without it, a plausible-but-wrong query runs and returns a number nobody can distinguish from a right answer. With it, the same query never runs and you get told why. The mechanism behind that failure mode is worth understanding on its own — see why AI hallucinates on ERP data.
Verifiable: the query travels with the answer
An answer without its query is a claim. An answer with its query is evidence. Showing the query does three things: it lets a competent person check the definition in about fifteen seconds, since almost every disagreement is about a filter; it gives your auditors a trail; and it makes the vendor's engineering visible, which changes how carefully the system gets built.
The practical test is whether the query is complete and re-runnable, not whether it is pretty. If it arrives as one unbroken line, paste it into the SuiteQL formatter and read it properly before you argue with the number.
Bounded: refusal is a feature
The least impressive behaviour in any demo is the one that matters most in production. "I can't answer that — there is no field in your account recording customer promise dates" is a genuinely useful answer. It tells you the limit is in your data, not in your phrasing, and it saves you from a number you would have believed.
Bounded also covers permissions. A grounded system sees exactly what the connected role can see, and says so when a question needs more. That is a security property as much as an accuracy one, which is why it appears in both this list and the AI and ERP security checklist.
Grounded is not the same claim as connected
A connection gives a system access to your data. Grounding constrains what it is allowed to generate against that data. Most tools in this space have the first and describe it as though it were the second. Here is where the honest comparison lands, including where our own category is weakest.
| Approach | Genuinely good at | Where it breaks |
|---|---|---|
| Native reports and saved searches | Exact, repeatable, governed output. The definition is visible and owned by a human. | Every new question is a build. Join and summary limits force exports, and the queue forms at the one person who knows the account. |
| BI dashboards over a warehouse | Fast reads across large history, blended sources, proper visualisation. | You answer the questions the model was built for. New questions mean modelling work, and data is as fresh as the last load. |
| General chatbot plus a pasted export | Explaining, summarising and drafting narrative around numbers you supply. | It only knows the rows you pasted. Nothing is live or checkable against source, and the file goes wherever the chat goes. |
| Text-to-SQL over a schema dump | Turning clear questions into runnable SQL when the schema is small and well named. | A schema list is not a dictionary: no observed status domains, no row counts, no per-account meaning. Accuracy falls hardest on ambiguous questions. |
| Grounded ERP AI | Ad-hoc questions answered live from your own account, with the query shown and invented fields structurally impossible. | Needs a mapping step before it is useful. Refuses more often than a consumer chatbot, deliberately. Cannot answer judgement questions or fix bad source data. |
Why grounding here is stricter than RAG
"Grounded" entered general use through retrieval-augmented generation: retrieve relevant documents, put them in the prompt, and the model's answer is anchored to real text. That works well for policies, contracts and manuals, where the answer exists as prose somewhere.
ERP answers rarely exist as prose. "How much AR is overdue across three subsidiaries, net of credit memos" is not retrieved, it is computed — a filter, a join and a sum over rows that changed this morning. So grounding here has to anchor two things: the schema the query is written against, and the computation the answer comes from. Retrieval helps with definitions. It does not save you from a wrong join.
Model the benefit side of an ERP AI business case with your own hours, error rates and working-capital numbers.
Six questions to ask any ERP AI vendor
Ask these in a demo, on their account or yours, and ask for the answers in writing afterwards. The written version is where vague claims fall apart.
- 1."Show me the dictionary you built for this account." You want record types, field counts, custom field counts and observed status values — not a marketing diagram of a pipeline.
- 2."Show me the query behind this number." Complete and re-runnable. Then read the filters and check the date field it chose.
- 3."Ask it something it cannot know." A field that does not exist, or data outside the connected role. You are testing for a refusal with a reason.
- 4."Ask the same question two ways." Same number both times, or the definition is being re-guessed on each turn.
- 5."What happens when my admin adds a custom field tomorrow?" You want a described refresh mechanism and a stated staleness window, not "it learns automatically".
- 6."Which permissions does the integration role need, and can it write?" Read-only by default, an explicit permission list, and writes off until you enable them per record type.
If you are building the internal business case alongside the evaluation, keep the benefit claims as testable as the technical ones. Hours recovered from report-building is the easiest to defend — the reporting time savings calculator gets you a number from your own headcount rather than a vendor average.
What grounding does not give you
A definition that only lists strengths is marketing. Four things grounding does not solve:
- Ambiguous intent. If "revenue" means three things in your business, grounding cannot pick the right one. The correct behaviour is to ask, and the shown query is how you catch it when the wrong one was assumed.
- Bad source data. If due dates are wrong in the ERP, every correctly-computed answer about lateness is also wrong. An AI layer inherits your data quality exactly.
- Judgement. "Should we extend terms for this customer?" is not a query. A grounded system can assemble the evidence — history, ageing, disputes — but the decision is yours.
- Certification. Grounding is an accuracy property, not a compliance one. Access scope, retention, tenancy and audit are separate questions with separate answers.
There is also a modelling limit worth stating: even with a validated schema, a system can choose a defensible-but-wrong join or the wrong date field. Grounding shrinks the space of possible errors and makes the remaining ones visible. It does not reduce them to zero, and any vendor claiming it does has skipped the part where you check.
How implements the four properties
Mapped directly, so you can hold us to the same test. Grounded: a data dictionary of your NetSuite account is built during onboarding — record types, every standard and custom field, subsidiaries, real join paths — and queries are generated from it. Validated: every query is checked against your account's real schema before it runs, which makes hallucinated fields structurally impossible rather than merely discouraged. Verifiable: every answer carries the exact SuiteQL that produced it. Bounded: questions outside the dictionary get a refusal, and the connection is read-only until you enable writes per record type and field — each one previewed, confirmed, audited and undoable.
Two honest notes. is pre-launch: NetSuite first, with Infor SyteLine, M3 and LN ready, and everything above is a product property rather than a customer testimonial. And grounding is not a compliance claim — before you decide anything, run us through the same security checklist you would use on any vendor, including the question about certifications we do not yet hold.
Frequently asked questions
What does grounded mean in AI?
Grounded means the answer is derived from a verified source rather than from the model's own prediction. In an ERP context that source is your account: its schema and its live rows. A grounded system generates queries from your real fields, checks them before running, and shows the query, so every number can be traced back to data you own.
What is the difference between grounded AI and RAG?
RAG grounds language in retrieved documents, which suits questions whose answer already exists as text. Grounded ERP AI has to anchor two things: the schema a query is written against, and the computation that produces the number. Most ERP questions are sums and joins over live rows, so retrieval alone does not protect you from a wrong join.
Is text-to-SQL the same as grounded ERP AI?
Text-to-SQL is one component. Grounded ERP AI adds the parts that make it safe on a real account: a per-account dictionary including custom fields and observed status values, validation against the real schema before execution, the query shown with every answer, and refusal when the question falls outside what is known.
Can grounded ERP AI still be wrong?
Yes. Grounding makes invented fields impossible, but a system can still pick a defensible-but-wrong join, choose the transaction date when you meant the posting period, or answer a differently-scoped question than you intended. That is precisely why the query is shown — so the remaining errors are visible in fifteen seconds rather than at audit.
Do I need a data warehouse for grounded ERP AI?
No. Grounding needs a dictionary of your account's schema, not a copy of your data. Queries run live against the ERP, so the answer reflects what the system of record says right now and your ERP stays the source of truth. A warehouse is still useful for long-history analytics and blending non-ERP sources.
Do I need to know SuiteQL to use grounded ERP AI?
No. You ask in plain English and the query is generated for you. Being able to read the query is useful rather than required — someone on the team should check the filters on any number that is going into a board pack, a covenant calculation or a customer conversation. That review takes seconds, not SQL fluency.
Calculators for this
Format SuiteQL and SQL in your browser: keyword casing, clause line breaks, indented joins and subqueries, plus a one-line minify mode.
Build an ERP ROI case from your own numbers: hours saved, inventory and receivables released, rework avoided. Get ROI %, payback months and 3-year NPV.
Reporting time savings calculator — price the hours your team spends building reports, the annual cost, hours recovered and the FTE equivalent.
Calculate days sales outstanding from your AR and credit sales. See days beyond terms, cash tied up in receivables, and what each day of improvement is worth.
Keep reading
Why AI hallucinates on ERP data: the mechanism behind confident wrong numbers, and the four controls that stop it — grounding, validation, shown queries.
What a data dictionary is in ERP terms: record types, custom fields, join paths, observed status values — and why AI answers need a per-account one.
An AI and ERP security checklist: 18 questions on access, retention, tenancy, writes, audit and model hosting — with good and bad answers for each.
ERP reporting tools compared: native reports, saved searches, a BI stack and conversational AI — with the real weaknesses of each, including ours.