Internal chatbots for ERP data: grounding conversational AI

The demonstration is always persuasive. Someone types "what did we invoice Customer A last quarter" and a fluent, well-formatted answer appears. Everyone in the room can immediately think of five questions they would ask. The project gets approved.

Then two problems surface, and they are the same problem in different clothes. The first is that the answer has to be right — not plausible, not approximately right, but correct in the way a figure in a management pack has to be correct, because someone will act on it. The second is that the answer has to be right for the asker: a salesperson asking about margin, a warehouse supervisor asking about a customer's credit status, and a finance analyst asking the same questions are not all entitled to the same response.

A chatbot over ERP data is therefore not a conversational interface project. It is a retrieval, permissions and verification project with a conversational interface on top — and the ordering of those words is the whole difference between something useful and something that quietly misinforms your company.

Why this matters

The upside is genuine and it is not really about convenience. Most mid-market ERP systems contain answers that nobody retrieves, because retrieving them requires knowing which saved search to run, which is knowledge concentrated in three or four people. Those people become a bottleneck on routine questions, and everyone else either guesses or works from an exported spreadsheet that was current last month. Making the data actually reachable is a real change in how a company operates.

The downside is proportionate. A system that answers fluently and occasionally wrongly is more dangerous than one that is hard to use, because errors arrive with the same confidence as correct answers and there is no natural moment of doubt. A salesperson quoting a margin figure to a customer, or a manager making a stocking decision on a misread number, will not know that this particular answer was one of the wrong ones.

And there is an exposure risk that is easy to create accidentally. A chatbot connected with broad service-account permissions will happily tell whoever asks about salaries, margins by customer, or supplier pricing. The interface makes previously obscure data trivially reachable, which is the point, and it means access control that was adequate when queries required expertise is no longer adequate.

At a glance: question types and whether to allow them

The distinction that matters runs between retrieval and reasoning. Questions answerable by fetching a number and applying an agreed definition are safe. Questions requiring interpretation of why something happened invite a fluent narrative that may be entirely constructed, and users cannot tell the difference. Keep the system on the retrieval side of that line and say so openly to users.

What works, and what to be honest about

What works:

Queries against defined, deterministic sources rather than free interpretation. The chatbot maps a question to one of a curated set of parameterised queries — saved searches, reports, defined metrics. If no query matches, it says so. This is less impressive in a demonstration and dramatically more trustworthy in production.

Permissions inherited from the asking user, always. Every query executes with that individual's ERP permissions, not a service account's. This is the single most important design decision in the entire project and it is the one most often deferred because it is inconvenient.

Every answer showing its working. The figure, the source, the filters applied, the period, and a link to the underlying record or report. Users need to be able to verify, and the presence of a citation changes how they treat the number — appropriately.

Explicit refusal over inference. When the question is ambiguous or unsupported, the correct behaviour is to say so and offer what it can answer. A system that guesses to appear helpful will be wrong occasionally and trusted uniformly, which is the worst combination.

Agreed definitions before deployment. If "revenue" or "margin" or "active customer" means something different in three departments, the chatbot will pick one and present it as fact. Settle the definitions first; the exercise is valuable independently.

Logging every question and answer. This gives you an audit trail, a view of what people actually want to know, and the evidence to detect a systematically wrong answer before it spreads.

What to be honest about:

Aggregation is where errors hide. A wrong single-record lookup is obvious. A subtly wrong aggregation — a filter excluding intercompany, a period boundary off by a day, a currency not converted — produces a plausible number nobody questions. Aggregation queries need testing against known-correct reports, and re-testing when the underlying reports change.

Users will over-trust fluent output. This is a property of the medium, not of your configuration. Mitigate through citations, explicit scope statements, and telling people plainly what the system is not for. Expect to repeat that message.

It will surface your data quality problems as user-facing errors. Duplicate customer records mean a customer query returns partial results. Inconsistent item data produces incomplete answers. The chatbot does not create these problems; it publicises them.

Consolidation is not summation, and the system will not know that. Group figures require elimination and translation logic. Unless that logic is explicit and used, cross-entity questions should be blocked rather than answered approximately.

Scope creep is the main failure mode. It starts with order status and definitional questions, works well, and then someone asks for forecasting. The forward-looking and explanatory question types are where trust gets lost, and the boundary needs holding deliberately.

Decision framework: designing it safely

Run in order. Stop at the first match.

1. Can every query execute with the asking user's own permissions?
If not, resolve this before anything else. A chatbot on a shared service account is a data exposure with a friendly interface, and it will be used by people whose access was previously limited by their inability to write queries rather than by policy.

2. Do your key metrics have one agreed definition each?
If not, settle them. Revenue, margin, active customer, on-time delivery. The chatbot will otherwise present one department's definition as the company's answer.

3. Have you defined the supported question domain, and what happens outside it?
Write the boundary down, implement explicit refusal outside it, and communicate it to users. Start narrow — status lookups, defined aggregations, policy and process questions.

4. Does every answer carry its source, filters and period?
If not, add this before launch rather than after. It is what makes verification possible and it changes user behaviour for the better.

5. Have you tested aggregation answers against known-correct reports?
Build a test set of questions with verified answers and re-run it whenever the underlying reports or configuration change. This is a regression suite, and it is what prevents quiet drift.

6. Is every interaction logged with the user, question, query executed and answer?
Implement this from day one. It is your audit trail and your best source of information about what to build next.

7. All of the above and users still not adopting it?
Usually the supported domain is too narrow to be useful, or the answers are correct but slower than asking a colleague. Look at the logged questions it refused — that is your roadmap.

Indicative cost and effort

Assumes one ERP instance and a defined initial question domain. Multi-entity consolidation, or extending to unstructured document sources, extends this materially. Get a quote for a scoped estimate.

Frequently asked questions

Can it generate queries dynamically rather than using a curated library?
Technically yes, and we would not recommend it for financial and operational data at mid-market scale. A generated query that is subtly wrong produces a plausible number with no error signal. A curated library is less flexible and its failures are visible, which for numbers people act on is the right trade.

How do we stop it answering questions it should not?
Two layers: permissions, so it cannot retrieve what the user may not see; and domain scoping, so whole categories — personal data, forward-looking questions, explanatory analysis — are excluded by design rather than filtered case by case.

What about hallucination?
Grounding every answer in a retrieved result and requiring a citation addresses most of the risk for retrieval questions. The residual risk sits in how results are summarised, and in explanatory questions where the system is invited to construct a narrative — which is why those should be excluded rather than mitigated.

Should it write to the ERP as well as read?
Not initially, and read-only is a defensible permanent position for a conversational interface. Write actions belong in agents with defined authority boundaries, audit trails and escalation paths — the design discussed elsewhere in this series — rather than in a chat window where intent is inferred from natural language.

How do we measure whether it works?
Questions asked, questions refused, verified accuracy against your test set, and the change in demand on the two or three people who previously answered these questions. The last one is the real business case.

How quickly can the chatbot actually be connected to live ERP data?
The connection is usually fast — a certified partner like Stacksync can have real-time, governed sync between the ERP and the chatbot's data layer running within weeks. Getting the chatbot to answer only from what it's actually allowed to see, as covered above, is the part that needs real design time.

Closing — Next steps

An internal chatbot over ERP data is the most demonstrable and most misunderstood item in this series. What makes it work has almost nothing to do with the conversation: it is per-user permissions, agreed metric definitions, curated deterministic queries, visible sources and a boundary the system refuses to cross.

A useful starting point that costs a week: collect the twenty questions your finance and operations teams are actually asked most often. Sort them into retrieval questions and reasoning questions. The first pile is your initial scope, and it is usually large enough to justify the project on its own.

About the author

Bruno Galo is the founder of Atypical Tech, a NetSuite consultancy serving mid-market clients across Iberia. He specializes in connecting CRM and ERP systems for seamless order-to-cash workflows, building automated order management pipelines that eliminate manual data entry between sales and finance teams. As an official Stacksync implementation partner, Bruno designs and deploys AI agents on integration platforms to handle exception routing, document processing, and reconciliation — turning fragmented order flows into reliable, self-monitoring systems.

LinkedIn: https://www.linkedin.com/in/brunogd

Sources

URLs are publisher-level and should be verified before publication.

• Oracle NetSuite, roles, permissions and saved search documentation — https://docs.oracle.com/en/cloud/saas/netsuite/
• NIST, AI Risk Management Framework — validity, reliability and transparency — https://www.nist.gov/itl/ai-risk-management-framework
• European Commission, EU AI Act — transparency obligations — https://digital-strategy.ec.europa.eu
• European Data Protection Board, guidance on data minimisation and access control — https://www.edpb.europa.eu
• Atypical Tech engagement experience, mid-market ERP and conversational deployments across Iberia
• Stacksync, real-time integration and sync platform blog — https://www.stacksync.com/blog