Chat with Your ERP: Natural-Language Reporting on Odoo Data

Chatting with your ERP means asking "what did we invoice last month by salesperson?" and getting an answer computed from live data. The safe design turns the question into constrained, read-only queries run by a read-only user, and shows the filters used. A model must never write free-form queries against your database.

Key takeaways

• The model's job is translation, not arithmetic. Odoo does the counting and summing; the model picks the query and explains the result.
• Use a dedicated read-only Odoo user. Access rights and record rules then limit what any question can reach.
• Prefer a small set of pre-defined report tools over open-ended querying. Add a constrained generic query only where needed.
• Every answer should show its working: the model queried, the date range, the filters and the grouping.
• Agree on business definitions first. "Revenue" and "active customer" must mean one thing.

Why people want this

Most ERP data is locked behind someone who knows where to click. A manager wants to know which customers have overdue invoices above a certain amount. The answer is in Odoo, but getting it means opening Accounting, building a filter, adding a grouping and exporting a list. So the manager asks an analyst, and waits.

A natural-language reporting assistant shortens that loop for the routine questions. It does not replace dashboards for numbers you check every day, or a proper analysis for a board paper. It covers the long tail of one-off questions in between.

The unsafe pattern and the safe one

The difference between a demo and a system you can trust is how much freedom the model has.

	Unsafe pattern	Safe pattern
Access	Direct database connection, or an admin API user	Dedicated read-only Odoo user through the external API
Query	Model writes free-form SQL or arbitrary calls	Model fills in parameters of approved tools
Permissions	Bypasses Odoo access rights and record rules	Enforced by Odoo on every call
Numbers	Model may calculate or estimate in its head	Odoo aggregates; the model only reports
Verification	Answer only	Answer plus model, filters, period and row count
Failure mode	Confident wrong number	"I could not answer that" or a clarifying question

Direct database access is tempting because it is flexible. It also skips every protection Odoo gives you: multi-company rules, salesperson-only visibility, restricted HR and payroll records. Going through the API keeps those in force.

How the safe pattern works, step by step

1. The user asks. "Top ten customers by invoiced amount this quarter, excluding credit notes."
2. The agent picks a tool. It has a list of report tools with clear descriptions. Here it chooses an invoicing summary tool.
3. The agent fills in parameters. Date range, grouping by customer, document type, limit of ten. Parameters are validated in code: dates must be real dates, fields must be on an allow-list, limits have a maximum.
4. Odoo runs the query. The tool calls the API as the read-only user. Odoo applies that user's rights and returns grouped totals.
5. The agent answers. It presents the table and states what it did: posted customer invoices, the date range, credit notes excluded, grouped by customer.
6. The human verifies. The filters shown can be reproduced in the Odoo interface in a minute.

Report tools versus a generic query tool

Pre-defined report tools are the most reliable option. Each one encodes a business definition once, in code. For example, sales_summary(date_from, date_to, group_by) always counts confirmed orders in the same way, however the question is phrased.

A generic tool, such as a wrapper around search_read or a grouped read, covers questions you did not anticipate. Constrain it hard:

• An allow-list of models, for example sales orders, invoices, stock quantities, leads and tickets.
• An allow-list of fields per model, leaving out sensitive ones.
• Read methods only. No create, write or unlink exists in the tool at all.
• A row limit and a timeout, so a broad question cannot pull the whole database.

The connection details are covered in how to connect an AI agent to Odoo.

Showing the working

An answer without its filters cannot be trusted, even when it is right. Design the reply format so every answer carries the same footer:

• Source: which Odoo records were queried, in business terms.
• Period: exact start and end dates, not "last month".
• Filters: status, company, document type, anything excluded.
• Grouping and measure: what was summed or counted, and in which currency.
• Row count: how many records the figure is based on.

This does two things. People catch a wrong assumption quickly, such as draft invoices being included. And they learn to phrase better questions.

Where it goes wrong

Ambiguous business terms

"Sales" can mean confirmed orders, delivered goods or posted invoices. Write a short glossary and bind each term to one tool. When a question is still unclear, the agent should ask, not pick.

Relative dates and time zones

"This week" depends on the week start and the user's time zone. Resolve dates in code and print them in the answer.

Arithmetic by the model

Language models are unreliable at adding long columns of numbers. Any total, average or comparison should be computed by Odoo or by code, then handed to the model as a finished value.

Custom fields and messy data

The assistant reports what is in the system. If salespeople leave the expected revenue empty, the pipeline answer will be wrong in the same way the standard report is. A chat layer does not fix data quality; it makes it more visible.

Too much access

If the assistant is shared across the company, one read-only user is not enough. Either run queries with rights that match the person asking, or restrict the shared assistant to data everyone may see.

Questions it handles well, and ones it should refuse

• Good fit: counts, totals and lists with clear filters. Overdue invoices by customer, stock on hand below a threshold, open tickets by team, quotations awaiting confirmation.
• Possible with care: comparisons across periods and simple trends, when computed by tools.
• Poor fit: forecasts, causes ("why did margin drop"), and anything that needs data not in Odoo. The agent can supply the numbers behind such a question, but should say plainly that the explanation is a human's job.
• Refuse: requests to change records. Reporting assistants should be read-only by construction. Writing to the ERP is a different project with different controls.

How to test it

Build a set of real questions with known correct answers, taken from reports your finance and sales teams already trust. Run the set after every change. Check three things for each question: did the agent choose the right tool, were the parameters right, and does the number match. Include trick questions, such as a model the user may not see and a term with two meanings, and confirm the agent declines or asks.

Related guides

• AI for Odoo Inventory: Reordering, Forecasting and Stock Questions
• AI Agents for Odoo: What They Are and What They Can Do
• Building an AI Support Agent on Odoo Helpdesk
• Odoo Automated Actions vs AI Agents: When Rules Are Not Enough
• Service: AI Agents for Odoo and ERP

Frequently asked questions

Can the assistant change data in Odoo?

Not in the pattern described here. The Odoo user has read access only and the tools expose read methods only, so there is no path to a write even if the model tried.

Is it safe to let an AI model see our ERP data?

The model sees the question and the query results you return to it, so limit both. Use field allow-lists, keep sensitive models out of scope, and review the data terms of the model provider you choose.

Does this replace Odoo's own reports and dashboards?

No. Standard reports and dashboards remain the right tool for recurring figures. The assistant is for one-off questions that would otherwise need custom filters or an export.

Does it work with other ERPs?

The pattern is the same for any ERP that exposes an API with per-user permissions: constrained read tools, a read-only identity, and answers that show their filters.

Sources and further reading

Primary documentation and research behind this guide.

• Odoo 18 documentation: External API
• OpenAI: Structured outputs guide
• OWASP: Top 10 for large language model applications

A reporting assistant is only useful if people can check its answers. Build it narrow, read-only and transparent, and expand the tool list as real questions come in. Growmerz builds these as part of our AI agents for Odoo and ERP work. If you want to see which of your recurring questions could be answered this way, book a free AI audit.