How to add an AI chatbot to SAP Business One
Short answer
A useful B1 chatbot is a web or chat front end backed by a service that answers from live Service Layer data and approved documents, applying the asking user's permissions. Internal staff bots are the safer start; customer-facing bots need stricter filtering and a hard limit on what can be shown.
Business One has no built-in conversational interface, so questions get answered by whoever knows where to click. In a smaller company that is usually one overworked person: where is my shipment, what is the price for this item, did we receive the PO. A chatbot can absorb a large share of those questions.
The risk is a bot that sounds confident and is wrong. The fix is grounding: every answer comes from a defined lookup or a retrieved document, with the source shown, and the bot says plainly when it cannot find something.
The sections below cover who should use it first, what data it reads, how to keep users from seeing what they should not, and what to do when customers, not staff, are the audience.
What teams use it for
Internal order and stock helper
Sales and customer service staff ask about order status, stock and expected receipts instead of interrupting the warehouse or purchasing.
Customer order status portal
Customers ask about their own orders and shipments. The bot only reads documents linked to that customer's business partner code.
Procedure and policy answers
Staff ask how to handle returns, credit notes or inventory counts, answered from your own SOP documents rather than general knowledge.
New user onboarding
Explains which B1 screen to use for a task, such as entering a goods receipt PO, using your internal guides.
Quote and price lookups
Reads price lists and special prices for a customer and item, then presents the price with the list it came from.
Service ticket triage
If you use the service call module, the bot searches past calls and solutions to suggest a first response.
SAP Business One integration surface
- Service Layer reads: Orders, DeliveryNotes, Invoices, Items, BusinessPartners and price list data. The chatbot's backend calls these with a restricted user.
- Direct read-only database access: possible for lookups on a reporting copy, with care because it bypasses B1 authorisations.
- Attachments and linked documents: SOPs and customer documents may sit in the attachments folder or a separate file share and can be indexed for retrieval.
- Web Client or add-on surfaces: a chat panel can be embedded in a separate intranet page; deep embedding in the desktop client usually needs an add-on using the UI API.
- Identity: map the chat user to a B1 user or business partner so the answers respect who is asking. Single sign-on options depend on your setup.
How it works
- 1
Decide the audience
Start with internal staff. Customer-facing use adds identity verification, abuse handling and legal review of what may be shown.
- 2
List the questions
Collect a month of real questions from email and chat. Group them into lookups, document questions and things that need a human.
- 3
Build lookup tools and a retrieval index
Lookups call the Service Layer; document questions use retrieval over SOPs and policies. Keep the two separate so a policy answer never pretends to be live data.
- 4
Apply permissions
Filter by the asker's role or by business partner code. Test that one customer can never ask about another's orders.
- 5
Show sources
Display document numbers, dates and links for every answer, and a clear "I could not find that" response.
- 6
Add a hand-off
When the bot is unsure, it should open a ticket or email a named person with the conversation attached.
Example flows
Internal stock question
Trigger: A salesperson asks, "Do we have 50 of item A-1200 by the 30th?"
- The bot calls the availability tool for the item.
- It adds open purchase order receipts with dates before the 30th.
- It compares with committed quantity from open sales orders.
- It answers yes, no or partial, with the numbers.
Result: A quote can go out without a call to purchasing.
Customer shipment query
Trigger: A customer asks about order status on a portal.
- The user is authenticated and mapped to their business partner code.
- The bot reads only that customer's orders and delivery notes.
- It returns status and shipping reference.
- If an invoice or delay needs a person, it creates a ticket.
Result: Routine status calls reduce, and exceptions reach a human with context.
Keeping data on-prem
A chatbot over Business One can run fully on-prem. Host the lookup service next to the Service Layer, keep the document index on a local vector store, and serve an open-weight model on a GPU server in your own environment. Staff reach it through an intranet page, and customers, if allowed, through a reverse proxy that exposes only the chat service, not B1. Small and mid-sized open models cope well with status lookups and SOP questions, though response quality on long, messy policy documents should be tested with your own files.
Security checklist
- Enforce row-level filtering by user role or business partner code in the backend, not in the prompt.
- Never expose cost, margin or other customers' data to customer-facing bots.
- Keep the Service Layer off the internet; expose only the chat endpoint through a proxy.
- Add rate limits, session timeouts and abuse monitoring for public bots.
- Retain conversation logs under a defined policy and mask sensitive values.
Ways to get it done
Generic chatbot platform with a custom connector
Effort: Days for FAQ, weeks for live data.
Works for simple FAQ bots; live B1 lookups still need your own API layer.
Build in-house over the Service Layer
Effort: Two to six weeks for an internal bot.
Good if you have developers and want control over permissions and hosting.
Partner delivery including Netray
Effort: Pilot then roll out by audience.
Suited to on-prem models, customer-facing safeguards and B1 knowledge in one project.
Pitfalls
- !Letting the model answer from memory when a lookup fails, producing invented order status.
- !Mixing customer-facing and internal data in one retrieval index.
- !Forgetting that closed, cancelled and draft documents look different in the data.
- !No measurement, so nobody knows whether answers are correct or used.
- !Indexing outdated SOP versions that contradict current practice.
Frequently asked questions
Can the chatbot live inside the Business One client?
A deeply embedded panel generally requires an add-on built with the UI API, which is more work. Most teams start with a separate intranet page or chat tool and link into B1 by document number. Check what your version and deployment support before committing.
How do I stop customers seeing other customers' data?
Enforce it in code. The backend maps each authenticated customer to a business partner code and filters every query on it. Never rely on the model to refuse. Test with deliberate attempts to ask about other accounts before launch.
Does it need SAP HANA?
No. The chatbot talks to the Service Layer or a reporting copy of the database, and works on SQL Server or HANA editions. HANA can help with fast analytics, but it is not a prerequisite for status and policy questions.
Can it run without internet access?
Yes. With an open-weight model and a local vector store, everything can stay on your network, including air-gapped sites. Plan GPU capacity for peak concurrent users and test answer quality on your own documents.
When is it not worth building?
If you only get a handful of questions a week, a shared inbox and a good report are enough. A chatbot pays off when the same lookup questions repeat daily and interrupt people who should be doing other work.
Want AI chatbot working on your SAP Business One?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment