Quotes, inventory, production, and bookkeeping all run on the same database. The open-source architecture keeps the data model and API fully open, so AI agents can read and write ERP records and master data directly. GN-AI builds and maintains the Taiwan regulatory compliance.
A modular management system that puts order-taking, inventory, production, and accounting into a single database.
ERP (Enterprise Resource Planning) is management software that links order-taking, purchasing, inventory, production, and bookkeeping in one database. Departments no longer need to maintain separate spreadsheets.
Odoo is developed by Odoo S.A. in Belgium and has been in development for over 20 years. It differs from traditional ERP in two ways, both directly useful when deploying AI:
The release cycle is predictable: one major version a year, with minor versions roughly every quarter in between. Upgrade planning is part of the project scope from day one. Vendor version updates and security advisories are tracked continuously under annual maintenance. For the overall evaluation logic for ERP deployment and the AI deployment service scope, see ERP Business Management.
With the data model and API fully open, AI agents don't need to wait for the vendor to open an interface, and no separate integration license is required.
The bottleneck in putting AI into ERP is usually not model capability, but not being able to read or write data. Odoo exposes its entire ORM as a public API, rather than opening a window onto a handful of tables. Table structures, field meanings, and method definitions are all readable in the source code. This is the main reason to choose Odoo.
Odoo runs on PostgreSQL, and both the code and table structures are fully public. A read-only replica can be set up for BI, RAG knowledge-base indexing, or data analysis, without affecting production performance. Field meanings can be checked in the source code rather than inferred.
Any public method on any model can be called through XML-RPC, JSON-RPC, or the JSON-2 API; internal methods starting with an underscore are not exposed. Custom models and fields added through Studio get an API automatically as soon as they are created. There is no extra integration layer to build, and no waiting on the vendor's release schedule.
Odoo 19's External JSON-2 API provides a /doc endpoint that dynamically generates API documentation based on the modules and custom fields actually installed on that database. ir.model and ir.model.fields can also be queried to list models, fields, and types. For an AI agent, this is a tool list and schema source that stays in sync with the system.
External calls always run as the user bound to the API key, subject to model-level access rights (ir.model.access), row-level record rules (ir.rule), and field-level permissions. What an agent can see and change is configured entirely within Odoo. There is no need to build a separate permission layer on the agent side.
Some closed-source ERPs charge a separate indirect-access license fee when third-party systems create records in them. An AI agent is by nature a high-frequency record creator, so this cost compounds over time. Odoo has no such charge.
Custom modules can be developed on Community and Enterprise on-premises deployments and on Odoo.sh; only Odoo Online (SaaS) does not allow custom code. On licensing, the Community core uses LGPLv3, which can be freely modified and redistributed; Enterprise modules use the vendor's proprietary license, which grants source code for your own modification but not redistribution. Local fields common in Taiwan, such as e-invoice number-track management, discounts and allowances, and supplementary premium calculation, can be built in-house. The AI provider layer can also be extended with a custom module pointing to a self-hosted endpoint.
The following reflects the current feature set as documented in Odoo 19's official documentation. All of it is part of Enterprise modules.
From Odoo 19, AI is a standalone app that serves as the base for cross-module assistance. The AI button in the top right and the Ctrl+K command bar support natural-language questions, opening views, rewriting content, translating messages, summarizing conversation history, and suggesting next steps. The standard Ask AI only retrieves information; it does not change database content.
Agents can also be built in-house. Topics (renamed Skills from 19.4) define behavior scenarios and available tools; Tools are actions the agent can actually carry out in Odoo, such as creating a lead, opening a view, or editing a record; Sources specify what data can be referenced, including PDFs, URLs, Documents files, and Knowledge articles. Once source restriction is turned on, the agent only cites the specified data. Built-in scenarios include natural-language search, information retrieval, and lead creation.
Fields whose value is suggested by AI can be created through Studio or property fields, covering text, multi-line text, HTML, integer, decimal, monetary, date, time, checkbox, relational, and tag types. The prompt can reference other fields on the same record with the /field command, and a scheduled action can fill in blank fields daily. AI server actions wrap a prompt into a server action attached to an automation rule for batch processing.
Converts a query written in Chinese or English into an Odoo domain filter, applied directly to the list view. Users can pull up the records they want without first learning Odoo's filter syntax.
Email templates can include an AI prompt, generating the body text dynamically from record content at send time, with drafting and copy-editing support. Documents can classify a file by prompt, file it automatically, and trigger follow-up actions. Website Live Chat can be handed to an AI agent for greeting visitors and collecting leads; from 19.4, a clickable card appears when a supported record is mentioned.
Meetings are transcribed live and summarized; from 19.4, instructions can also be dictated directly to an agent. The same release adds MCP (Model Context Protocol) support, 30-day retention of AI conversations, uploading and linking files within a conversation, and a website assistant that generates web pages through conversation.
Provider and key setup. The official 19.0 documentation lists OpenAI (ChatGPT) and Google Gemini as inference providers: you enter your own key in the system, and cost follows the provider's pricing. Odoo.sh and on-premises databases must supply their own API key to use the vendor's AI features. So "Odoo runs in our own server room" and "AI inference stays in our own server room" are two separate things that need separate planning. See the next section for how to keep inference in-house too.
Build agents on top of Odoo's API and permission model, and fit them into your existing approval workflow.
The traditional XML-RPC and JSON-RPC interfaces run through /xmlrpc/2/common and /xmlrpc/2/object, calling model methods with execute_kw, covering search, search_read, read, create, write, unlink, fields_get, and search_count. The External JSON-2 API added in Odoo 19 uses endpoints in the form POST /json/2/{model}/{method}, authenticated with an API key in the HTTP header. Each call runs inside its own SQL transaction: it commits on success and is discarded whole on error, which guarantees consistency for batch writes.
An agent connects as its own dedicated Odoo user, never with an administrator key. Groups, model access rights, and record rules are set on a least-privilege basis, with visibility and write access limited to the models and rows actually needed. Every action is logged in that record's message history, so it can be traced afterwards: who wrote it, when, and from what source.
Writes always land in draft or pending-review status: a quotation stops at draft, a purchase suggestion stops at pending approval, a reminder email stops in the drafts folder. Actions that take external effect, such as confirming an order, posting, or sending an email, are still carried out by a person. The agent's job is to gather, compare, and fill in data. Decision points and the existing approval hierarchy stay unchanged.
Tasks involving financial figures, customer lists, pricing strategy, and payroll data go to an on-premises model. Lower-sensitivity tasks such as general copy rewriting can consider cloud models instead. On-premises inference has two routes: develop your own AI provider module and point Odoo's inference calls at a self-hosted compatible endpoint, or leave Odoo's AI module untouched and let an external on-premises agent read and write data through the API, with inference running entirely on your own GPUs. The second route needs no customization on the Odoo side, carries lower upgrade risk, and permissions still stay under Odoo's control.
For the full AI deployment service chain (process review and feasibility assessment, data preparation, RAG knowledge-base build, agent development and integration, on-premises LLM deployment, training, and post-deployment tuning), see ERP Business Management. An on-premises GPU resource pool and model-serving platform can be paired with a hyperconverged cluster, keeping ERP and inference in the same server room. See Hyperconverged Infrastructure & VMware Alternatives for how.
Map your customization needs, data residency requirements, and IT capacity to the right edition, plan, and deployment location.
Open-source license, no per-user fee, and can be installed on your own server. Includes CRM, Sales, Purchase, Inventory, basic Manufacturing (MRP), Project, Invoicing, Website, and eCommerce. Suited to companies with in-house technical staff, or a proof of concept (POC, a small-scale trial) stage to confirm a process works. External AI agents can still connect through the API.
Commercial license, subscription-priced by number of users. Adds full accounting, a payroll engine, document OCR, spreadsheets and reporting, marketing automation, approvals, a knowledge base, advanced manufacturing features (shop-floor work order kanban, capacity scheduling), a mobile app, and vendor support, upgrade service, and built-in AI feature modules on top of Community.
Works straight from a browser, with the vendor handling hosting, backups, and platform operations. Suited to companies whose processes are close to standard functionality and can be met with Studio tweaks; it is also the fastest starting point for a phased deployment.
Supports custom modules, Git version control integration, and staging environments, while the vendor still operates the hosting. Projects that need custom modules, or code-level integration with local payment, logistics, or existing HR systems, typically fall here.
Installed on your own server or private cloud, keeping data on your side with the most customization freedom. This is also the only deployment option that lets ERP and AI inference stay in the same server room together. GN-AI provides architecture planning, build, upgrade assistance, and annual maintenance (business-hours support).
Plan recommendation. Odoo's subscription plans split into Standard and Custom. Standard is enough for projects close to standard functionality, a single company, and no code-level integration. Custom is needed for Studio, external API, multi-company setups, or Odoo.sh and on-premises deployment. AI agent development needs the external API, so any project deploying AI should plan its edition, plan, and deployment location around Custom from the assessment stage. Licensing is subscription-based, priced by number of users. Contact us for an actual quote.
For selecting the underlying platform for on-premises deployment, see Hyperconverged Infrastructure & VMware Alternatives. If the ERP is opened up for external users or eCommerce front-end logins, that becomes an additional public-facing service; see Web & API Protection (WAF).
Planning the deployment order around these five groups is the easiest way to align with each department.
CRM (lead and opportunity tracking), Sales (quotation to order), Subscriptions (recurring billing), Rental, POS (retail and F&B checkout, can run offline).
Inventory (multiple warehouses, lot/serial numbers, barcode picking), Purchase (requisitions and suppliers), MRP Manufacturing (BOM, work orders, capacity scheduling), Quality (inspection), PLM (engineering changes), Maintenance (equipment upkeep).
Accounting (general ledger, receivables and payables, bank reconciliation, tax filing, and financial statements), Invoicing (issuing invoices and collecting payment), Expenses. Full Accounting is an Enterprise feature.
Employees (staff records), Recruitment, Time Off, Appraisals, Project (projects and Gantt charts), Timesheets (hours convertible to billing), Helpdesk (support tickets), Planning (shift scheduling).
Website Builder (drag-and-drop site editor), eCommerce (B2B/B2C), Blog, eLearning, Live Chat. Products, inventory, orders, and invoices share the same data as the ERP, with no integration needed.
The above is an overview of module scope. Advanced modules such as full accounting and financial statements, the payroll engine, appraisals, helpdesk, scheduling, quality inspection, and engineering changes are Enterprise features. Which modules sit in which edition, and which ones you actually need, gets confirmed item by item during requirements interviews.
The vendor provides a chart of accounts and a value-added-center e-invoicing module (Taiwan's government-mandated e-invoice system). Direct Ministry of Finance integration and payroll regulatory rules are built and maintained by GN-AI under current law.
The vendor's Taiwan financial localization package has four modules: l10n_tw (Taiwan chart of accounts), l10n_tw_reports (Taiwan local financial report templates), l10n_tw_edi_ecpay (issuing e-invoices through the ECPay value-added service center, including B2B/B2C, credit notes, and voiding), l10n_tw_edi_ecpay_website_sale (automatic invoicing on eCommerce payment completion). That is where the vendor's scope ends. Whether Odoo actually works in Taiwan comes down to the four build items below.
Using a Ministry of Finance-approved value-added service center such as ECPay lets you use the vendor module directly. GN-AI handles account integration, issuing and voiding workflows, carrier and credit-note setup, and automatic eCommerce invoicing, for the shortest deployment time. Message spec revisions, platform integration changes, and certificate maintenance are handled by the value-added center. The company only needs to confirm data was sent and a success response was received.
The Ministry of Finance provides the transmission software free of charge; GN-AI develops the Odoo-side integration: MIG 4.1 XML message generation, invoice number-track allocation and remaining-number management, exchange directory and response file parsing, voiding and credit-note workflows, lottery and carrier information handling, and monitoring and alerts for the certification deadline (48 hours for a non-business buyer, 7 days for a business buyer). Invoice data flows only between the company's server room and the Ministry of Finance platform, never through a third party. MIG spec and transmission software version updates are tracked continuously under annual maintenance.
Odoo's official payroll localization does not cover Taiwan. GN-AI builds the salary structure and payroll rules under current law: labor insurance and employment insurance, occupational accident insurance, health insurance contribution grading, labor pension contributions (employer contributes at least 6% of wages monthly), the second-generation health insurance supplementary premium (employer and individual portions), income tax withholding and overtime pay calculation, and enrollment, withdrawal, and change filing files for labor insurance, health insurance, and labor pension. Rates, contribution grades, and withholding thresholds follow the competent authority's annual announcements. Maintained every year as the minimum wage and regulations change.
The chart of accounts is mapped to your existing bookkeeping structure, business tax settings, local financial report formats, and account mapping that ties in with filing work. As soon as a custom local field is created, it appears automatically in the API and dynamic interface documentation, so AI agents can read and write it directly with no extra intermediary layer. Accounting and tax practices are confirmed jointly with a partner professional accounting and tax advisor.
How to choose between e-invoice paths. Three questions decide it: how many invoices you issue a year, whether you have staff or a vendor to operate the server and certificate, and whether invoice data is allowed to pass through a third party. The value-added center is billed by service, with low upfront cost. Turnkey direct integration software itself is free, but the cost is in integration development, the server and certificate, and keeping up with the spec each year. You can also start with the value-added center for a fast launch, then migrate to direct integration later as invoice volume grows or security requirements rise. The invoicing data model on the Odoo side can be shared.
It is set out clearly upfront who is responsible for deployment, localization, and ongoing maintenance.
Five steps that turn a non-standard process into a standalone module that stays maintainable long-term.
Upgrade planning is part of the project scope from day one: customizations are always built as standalone modules, anything standard functionality can do is solved with configuration, a full run-through in staging happens before each version update, and annual maintenance keeps tracking vendor versions and security advisories. This is what keeps the system upgradeable, instead of getting stuck on one version.
Five phases, each with clear deliverables and a named party for acceptance.
These are indicative ranges. The actual timeline depends on the number of modules, the scope of customization, and the resources you can commit; a phased deployment can usually shorten the first stage. See Services for the full service content.
The six questions most often asked when evaluating Odoo, answered here.
Community has no per-user license fee. Full accounting, vendor support, upgrade service, and AI feature modules commonly used in production are part of the Enterprise subscription. Deployment consulting, custom development, and training are labor costs. We recommend putting licensing, operations, and labor on the same worksheet before choosing an edition.
The vendor's AI modules are part of Enterprise. On Community, an external agent can still read and write data through XML-RPC or the JSON-2 API, with inference done outside Odoo. This path also works with on-premises models.
Plan deployment location and inference location separately. To use the vendor's AI features, on-premises and Odoo.sh databases need their own OpenAI or Google Gemini key, and inference runs at that provider. To keep inference in your own server room, there are two options: develop your own AI provider module pointing to a self-hosted compatible endpoint, or have an external on-premises agent read and write Odoo through the API, with inference running entirely on your own GPUs. See Hyperconverged Infrastructure & VMware Alternatives for the on-premises GPU resource pool and model-serving platform.
The vendor provides a Taiwan chart of accounts, local financial report templates, and a module for issuing e-invoices (Taiwan's government-mandated e-invoice system) through the ECPay value-added service center. Direct Turnkey integration with the Ministry of Finance's e-invoice platform, and Taiwan payroll rules for labor insurance, health insurance, labor pension, and income tax withholding, are outside the vendor's scope. GN-AI builds and maintains these under current regulations, updated annually.
Odoo runs on a PostgreSQL database. Both the database and the custom module source code can be handed over in full. Switching consultants means taking the whole system with you, not just an export file.
A small-scope deployment of a single module typically takes two to three months. Cross-department projects with customization and integration usually run around six months. For staffing, assign one decision-making contact for each module being deployed (usually a department head), plus one project lead to coordinate cross-department decisions. A dedicated IT headcount is not required; day-to-day server tasks for on-premises deployment can be covered under annual maintenance.
Want to work out whether Odoo fits your company, which module to start with, or which processes suit an AI agent? Start with a single requirements interview and scoping session.
Contact us See the ERP solutionOther brands: Hitachi JP1 | All brands | Insights
Odoo is a trademark or registered trademark of Odoo S.A. GN-AI is an independent systems integrator.
Leave your contact details and a description of your needs, and an engineer will get in touch to help assess deployment scope, deployment option, localization build items, and annual maintenance content.