AI Inside Your ERP: What Can the Built-In Intelligence Actually Do?

First of all: which Odoo are you running?

A word on scope. The title says ERP, but the examples are about Odoo throughout. The reason is simple: Odoo is what we work with primarily, so that is what we can write about at a level of detail that is actually usable — down to the verbatim sentences of the vendor documentation. The mechanism it demonstrates, though, holds for the built-in AI of every large ERP: the model is not the vendor's, the limit lives in the code, and nobody measures accuracy for you. Where there is a figure for another large player, I put it in explicitly.

Most write-ups skip this question, and it is the one that decides everything. The question is not what Odoo's AI can do, but whether it is there at all on your system. There are four different answers, plus a fifth.

Community: no built-in AI — and less of it since 2025 than there used to be. The ai module does not appear in Odoo's public, Community source: it is missing from it in exactly the way every other Enterprise-only module is. Odoo never states this in words anywhere — the source code, however, is unambiguous. And there has been a step backwards: the Community text editor in 18 still carried a ChatGPT function through Odoo's own credit service, and that was removed in 19. Anyone on Community cannot switch on factory AI today; they have to install a third-party module.

Enterprise 18: there is no AI section in the documentation. The AI pages do not exist in the 18 docs; the only thing there is the credit-based document digitisation under Documents, which is an old service and not part of the AI application. If you run on 18, most of what follows cannot be switched on; it means a version upgrade.

Enterprise 19: there is AI, within limits. This arrived in September 2025, and the complete AI application is new in this release. The most important sentence, though, comes from the documentation itself: the standard assistant cannot make changes to the database. It opens views and displays reports, but it does not create leads and does not alter data — for that you have to assign a topic and a tool to it. That is what the rest of this article is about.

Enterprise 20: not yet. Odoo unveils version 20 at its 2026 conference, between 24 and 26 September 2026 — a week and a half after this article. There is no official release note and no version 20 documentation today. What the developer branch docs foreshadow: an MCP server through which an external AI agent can directly modify the database; image generation; the renaming of "topics" to "skills"; and — this is the most telling one — the sentence saying the assistant cannot make changes to the database has been removed. This is a development branch, it can change before release, and Odoo does not officially use the word "agentic" for version 20. If you are planning around it, wait for the announcement.

The release rhythm, for the record, looks like this: the latest major release is 19.0 (September 2025), available on all three deployment types, with support planned until September 2028. On top of that, intermediate "SaaS" versions appear every two or three months, but those live only in the cloud edition and are not eligible for extended support.

Some of what the reader takes for AI is not AI at all

Bank transaction matching is, according to the documentation, a deterministic chain of rules — exact match, then discounted match, then looking for the amount in the payment reference — and the additional rule models are based on regular expressions. Duplicate detection runs on amount, date and invoice number. None of that is machine learning. That is not a problem: rule-based matching is more reliable. But it is not AI, and it is better to know which is which.

What it can do exactly — feature by feature

The table below applies to the Enterprise 19 release. On Community and on 18, none of these is available.

According to the documentation some features work without installing the app at all — the app is what you need if you want to use your own API key, or pick a different provider per agent.

Under the bonnet: there is no in-house model

The documentation is unambiguous: the system supports Gemini and OpenAI as providers, and several versions of each.

So Odoo supplies the orchestration — the prompt, the tools, the permissions, the context — and an American provider supplies the model. It is worth understanding that precisely, because everything about money and about data follows from it.

The architecture that is the point of this article: manager and worker

The documentation describes a separation of responsibilities, and this is the most important technical detail in the whole thing.

The AI is the manager. It reads the record, interprets the prompt, and decides which tool to call and with what arguments. And the documentation adds, in so many words, that the server action does not enforce business rules, does not modify records directly, and does not guarantee that the operation is correct. Its role is limited to the decision.

The tool is the worker. This is a conventional, hand-written server action with AI use switched on. Business rules have to be enforced explicitly in the Python code — and if the AI calls the tool, it runs unconditionally, unless the code itself prevents it.

And a third detail that is surprising at first: the AI does not invent arguments from the code. Whatever you did not declare in the tool's schema, it will not pass on — not even if the code refers to it.

In one sentence: in an ERP the AI does not "do" anything. It decides which pre-written button to press. The safety limit is in the button, not in the AI.

That is good news. The same pattern holds for every agent — Tool Use and Function Calling, Explained unpacks the details.

What the agent can do, and what it cannot

It is built from three pieces: topics (instructions plus tools), tools (the functions that actually get executed) and sources (PDF, web link, document, knowledge base article, indexed — which is effectively a built-in RAG).

The most important limit, straight from the documentation: if an agent has no topic assigned, it can only give information — it cannot perform a task and cannot change anything in the database. The topics available out of the box: natural-language search, information retrieval, and — only if the CRM module is installed — lead creation.

And a setting that is disqualifying in an accounting environment: there is a "response style" per agent, and about the creative variant the documentation itself says it gives a different answer every time. The analytical setting is the one that will very likely give the same answer to the same question — the description recommends it when accuracy matters more than diplomacy. In an ERP that is not a style choice, it is a baseline requirement.

A third route: the Community fork

Full disclosure: this one is ours. eYssen is a fork of Odoo Community, and its version 18 has built-in AI — the kind that factory 19 does not have. What follows comes from its own public documentation, limits included, because without those this section would be an advert.

The substantive difference is not the feature list but the operating model. There the assistant is a tool-calling loop, not a single tool choice: by default at most ten consecutive calls, and ten tool calls per turn. Everything else follows from that.

Autonomous agent with its own user. An agent can be linked to a user record and runs with that user's rights — in the documentation's words, "like a human employee" — but a supervisor is mandatory for that. The module refuses the link if you point it at the superuser, a portal user, an administrator, or a user holding an API key.

Scheduled runs. A scheduled action running every five minutes starts the agent tasks that are due, with an interval configurable per task. A "standing" task can break the work into per-record child runs — at most 200 identifiers per call, and at most eight items started per tick.

Persistent memory. Four memory types (working, episodic, semantic, archive) and five scopes (user, company, system, agent, run), with maintenance running every six hours that archives expired entries. This is memory across conversations, not the context of a session.

Skills. Reusable instruction packs the assistant loads mid-task. The factory set includes a vendor bill playbook that never posts anything, leaves the bill in draft, creates a review task, and has a separate route for handling duplicates imported from the tax authority.

Five providers. OpenAI, Anthropic, xAI, Google Gemini, OpenRouter and compatible APIs. Your own key is required, and the key field is write-only.

And the security model, which bears out this article's main thesis. The governing principle, verbatim: no sudo on business data — Odoo's access lists and record rules always apply, and the AI policy can only narrow. There is a "hard-deny floor" that no rule can open: users, access rights, API keys, system parameters, scheduled actions, views, server actions, payment tokens, bank accounts — and every AI-owned model. Writing is a denied capability by default, and there are three write modes: automatic, always confirm, and create automatically but confirm changes. The global setting does not override the per-task one — no single switch can put every unsupervised agent on automatic.

What its own documentation says it cannot do. This part matters more than the feature list:

• the module installs with an "experimental" label;
• there is no perfect resistance to prompt injection, and the base rules "reduce but do not eliminate hallucinations";
• an empty violations list is not proof — a structural rejection at field level leaves no trace and raises no warning;
• cancelling a run is not immediate: about two minutes on factory defaults, and closing out a stuck run takes up to half an hour in the worst case;
• monitoring gives an audit log — not token consumption and not per-call cost; cost is only configurable as a soft daily cap;
• a local, self-hosted model does not appear in the documentation.

The two lists together are the truth of it: not better AI, a different trade-off on the same problem. Factory Odoo chose to have the default assistant never touch the data; the fork chose that it may, but only with narrowable permissions, a supervisor and a log. Which one is right depends on how much you trust your own approval process.

The money: two completely separate models

Almost nobody writes this part down correctly.

(A) Document digitisation is credit-based, per document. One document is one credit:

Page limits per document: invoice 8, expense 1, résumé 8, bank statement 30. Above the limit, the documentation says the first n−1 pages and the last page are processed — so on a twelve-page invoice with many line items, pages 8 to 11 are lost.

(B) For the AI app Odoo publishes no price. The documentation only says that using API keys may incur further charges at the provider, and that the exact cost depends on the model and the account type. Which means:

• in the cloud edition your own key is not mandatory — there Odoo covers or offsets it in some form (I found no public source on exactly how);
• on your own server and on the managed hosting it is mandatory, and then your provider invoice pays for it.

For comparison, the invoice reader of a large international ERP: 100 transactions a month are included, above that 1,000 transactions cost 300 dollars — that is 0.30 dollars each, and the allowance is monthly and expires if you do not use it up, which is why the vendor's own documentation says you have to size for peak load.

A two- to six-fold difference — not because one is better AI, but because it is packaged differently. And the general lesson: in large ERPs built-in AI is never free and almost never unlimited. You either pay per transaction or you pay the model provider. "It is included in the licence" means, in practice, that the entry-level allowance is included.

Where the data goes — two promises of different strength

This is the most important part of the article, and this is where the two get blurred together.

The invoice-reading OCR: the service behind it is a large search company's image recognition, with the European regional restriction switched on, and Odoo's servers are in Belgium and France. From a data protection point of view that is good news.

But: submitted files, together with their structured data, stay on Odoo's server for six months, and according to the notice they are used for the continuous improvement of the service. After that the file is deleted and the data anonymised; deletion on request is also possible. That is the sentence most write-ups leave out.

With the AI app the situation is different. The data goes to OpenAI or to Google, and the notice says only that under terms intended for business use it is not stored and not trained on. There is no geographic guarantee in the text, though. What gets transmitted: the prompt, the conversation history, the relevant system context, and the passages retrieved from the configured sources.

One reassuring detail in the same place: where the agent accesses information stored in the database, access follows the current user's permissions and the agent's configuration. So the agent does not see more than the person using it.

These are therefore two promises of different strength, and they must not be blurred: one has a written EU restriction with six months of storage, the other has processing without storage but without any geographic guarantee.

On your own server: freedom and responsibility at the same time

In own-key mode there are no Odoo credits, no intermediary, and no six-month storage on Odoo's side. But the European restriction is not there automatically either — you have to set that up at the provider yourself, along with a data processing agreement. On that, GDPR and AI gives you the order to decide things in.

The limits — itemised, from the vendor's own documentation

1. The agent knows nothing it has no tool for. Without a topic it only talks.
2. The AI does not enforce business rules. Those live in the code.
3. The AI does not invent arguments. Whatever you did not declare, it does not pass on.
4. The document sorter does not split a multi-page PDF — it only flags that it has to be done by hand.
5. Page limits, see above. The invoice with many line items is precisely the bad case.
6. The "creative" response style is not repeatable.
7. Empty AI fields refill themselves once a day through a scheduled action that is on by default — this is a hidden token cost.
8. The property-based AI field only exists in form view.
9. Installing Studio may affect your subscription plan, according to the documentation — and one of the routes for creating AI fields assumes it.
10. There is no published accuracy figure. Not for the OCR, not for the AI fields, not for the agents.

The tenth is the most important. If the vendor gives you no accuracy, you have to measure your own — and that is exactly why a measurement scheme is worth having. Document Processing and Accounting works it through for invoice scanning, with the formula.

What to take away

Built-in AI is the entry point, not the solution. What is good about it: the orchestration, the permission handling, and the fact that you do not have to build an integration. What is limiting about it: the model is not the vendor's, you have to write the rules into code yourself, nobody measures accuracy for you — and above all it takes the Enterprise 19 release, because on Community and on 18 it simply is not there.

And the single most important decision is not a technical one: which button you let the AI press, and what happens when it presses it at the wrong moment. As for placing the human approval, Human in the Loop is about exactly where that goes.

This article reflects the state of play on 14 September 2026. Version 20 is unveiled between 24 and 26 September — the article will be updated after that.