Quoting, order intake, purchasing, inventory, production, and bookkeeping all run in one system and one database. Built around Odoo open-source ERP, we provide deployment planning, custom development, AI agent integration, Taiwan regulatory compliance, and annual maintenance.
In short: the company's central ledger and switchboard. From quote to bookkeeping, the whole company keeps one set of data.
ERP (Enterprise Resource Planning) puts a company's entire process, from order intake to bookkeeping, into one system and one database.
Sales issues a quote; once the customer orders, it converts straight into a sales order. The system checks stock, and if there isn't enough, it raises a purchase request or a manufacturing order. After shipment, the invoice and receivable are generated automatically, and the books are already updated. From start to finish there is one set of data - nothing gets keyed in twice.
Companies without ERP usually run on separate tools: sales keeps a quote spreadsheet, the warehouse keeps an inventory spreadsheet, accounting has its own bookkeeping system, and the factory runs on a whiteboard and paper work orders. Each looks fine on its own, but they don't reconcile with each other, and closing the books at month-end means days of manual matching.
These four terms often get mixed together, but what they manage, who uses them, and which budget line they sit under are all different.
Manages what happens after the deal: orders, purchasing, inventory, production, receivables/payables, and bookkeeping. Users are sales assistants, warehouse staff, production planners, and accountants.
Manages what happens before the deal: the customer list, which stage each opportunity has reached, and quote history. Odoo includes a built-in CRM module.
Manages real-time dispatch and machine data on the shop floor. ERP hands it work orders; it reports back actual output.
Manages whether servers are up and whether overnight batch jobs finished. This isn't part of ERP - GN-AI covers it with Hitachi JP1.
An open-source business management system from Belgium; the vendor, Odoo S.A., has been operating for over twenty years. GN-AI is an Odoo partner.
When choosing a platform, module count matters less than how open the data and interfaces are. That determines whether you can bring AI into daily workflows later, and who ends up in long-term control of the system.
Over 80 modules that can be added independently. Start with CRM or inventory to prove the results, then expand company-wide once it's working - no need to commit the whole budget up front.
Built on PostgreSQL, with open source code and table structures. You can run a read-only replica for reporting, analysis, and knowledge-base indexing without affecting production performance.
Any model's public methods can be called via XML-RPC or the JSON-2 API added in 19.0. Custom modules and fields added through Studio get an API automatically the moment they exist - no separate integration layer to build.
External calls run as the bound user, applying that user's model access rights, record rules, and field-level permissions. External programs don't need to reimplement permission logic.
Can be fully self-hosted, with data on your own servers or private cloud. You decide the timing of upgrades and testing, instead of being tied to a single cloud vendor's release schedule.
From a trading company with a handful of staff to a manufacturer with hundreds, the same architecture scales. Add users as headcount grows, add modules as processes get more complex.
For an AI agent to act on a company's behalf, it first has to be able to read and write ERP data. Closed-source ERPs have APIs too, but their coverage is set by the vendor. A table or a custom field outside the published list has to wait for the vendor to open it up.
Odoo works the other way round. The moment a model exists, it automatically has an API, including custom-built modules and fields created in Studio. Code can also introspect ir.model and ir.model.fields to enumerate what models, fields, and types exist in a given database. The JSON-2 API in 19.0 adds a /doc endpoint that generates API documentation dynamically, based on the modules and custom fields actually installed. For an AI agent, that's a tool list it can fetch automatically, with no manual upkeep.
Taiwan-specific fields common among local customers - invoice number series, invoice allowances, supplementary health insurance premiums - show up in the API and dynamic documentation the same way once built as custom modules. Agents can read and write them immediately, with no extra integration layer.
There's also one less cost layer. Some commercial ERPs charge separately for indirect access by third-party systems, and an AI agent is by nature a high-frequency creator of records, which magnifies that kind of fee (source: market reports). Odoo has no equivalent indirect-access charge.
Two things need to be kept separate. Whether you can develop: Community and Enterprise self-hosted deployments, as well as Odoo.sh, all support custom module development; only Odoo Online (SaaS) cannot install custom code, and is limited to no-code adjustments via Studio. How licensing works: the Community core is LGPLv3, which can be freely modified and redistributed; Enterprise modules use the vendor's proprietary license - a subscription gives you the source code to modify for your own use, but you may not redistribute it.
Every scenario below follows one principle: the agent produces a draft or a list, and it only takes effect after a human confirms it. Writes always land in draft or pending-review status; order confirmation, payment, and outbound emails remain human actions.
Open source is the technical precondition for this: with table structures and the API fully open, an external agent can read and write ERP data directly. The diagram shows an external agent paired with an on-premises model, with inference running entirely on your own GPUs.
Reads the email body and spec attachments, matches part numbers against that customer's price list, and produces a draft quote with the source email attached. Sales checks items and prices before confirming; the agent never confirms an order itself.
Matches supplier invoices against purchase orders and goods receipts every day for quantity, unit price, currency, and tax rate. Discrepancies are logged as a comment on the invoice and flagged for follow-up. Accounting moves from checking every invoice to reviewing only the exceptions.
Reads current stock, stock in transit, twelve months of shipment history, and supplier lead times to calculate a suggested reorder quantity, then writes it back to the reordering rule or produces a draft purchase order. Safety stock adjusts continuously with actual sales patterns.
Determines whether an incoming email is about a quote, delivery, repair, or billing, files it under the right ticket category and priority, and looks up that customer's orders and shipment status to fill in the draft. The delivery dates and order numbers in the draft are pulled straight from the system.
Ask a question in Chinese; the agent turns it into a query, aggregates it against journal entries and analytic accounts, and answers with the actual filters used, the record count, and links back into the system for finance staff to verify.
Compares the sale price of each order against that product's actual cost every day, and flags orders where the margin falls below a threshold or deviates sharply from that customer's history on the same item. Pricing errors and missed freight charges are caught before shipment, not at month-end close.
Grades unpaid invoices by age, checks them against the customer's credit limit and any orders not yet shipped, and produces a draft collection letter plus a suggested hold-shipment list. Collection letters always go out after human review; holding a shipment is a manager's call.
Compares tax ID numbers, phone numbers, and address similarity to find likely duplicate customers or suppliers, listing the orders and invoices tied to each. Merging is always done manually, to avoid distorting receivables aging and credit limits.
At month-end, rolls up orders, invoices, shipments, and timesheets in sequence to produce profit and loss by project or business unit, recording which source document backs each figure. Accounting only needs to spot-check, and every number traces back to a single document.
Starting with 19.0, Odoo has built-in AI features - AI agents, AI fields, AI server actions, AI mail-template commands, automatic document classification, an online support agent, and voice transcription - all Enterprise-edition features. The standard Ask AI agent only answers questions and helps with navigation; it doesn't change the database. Creating or modifying records requires separately configuring the agent's behavior and the tools it's allowed to use. Version 19.4 adds MCP (Model Context Protocol) support.
The other path leaves Odoo's AI modules untouched: an external agent reads and writes data through the API, with inference running in the company's own environment. Odoo itself needs no customization, so upgrade risk stays low, and permissions follow the system's native access rights and record rules directly. See "On-premises deployment: data stays in your data center" below for how to choose between the two and how the data flows.
Six stages from process assessment to post-launch tuning, each with a deliverable you can sign off on. You can stop after the first two stages just to confirm feasibility - there's no need to do the whole program at once.
Keeping the ERP on-premises and keeping inference on-premises are two separate things to plan.
Odoo can be fully self-hosted, with both the database and the application running in your own data center or private cloud - an option SaaS-only ERPs simply can't offer. One thing to settle when planning the architecture: the vendor's own AI features currently support only OpenAI and Google Gemini as providers, and a self-hosted or Odoo.sh database has to supply its own API key - the content sent for inference still leaves the data center. Keeping inference on-premises too requires a separate architecture.
On-premises inference needs a GPU resource pool and a model-serving endpoint. A hyperconverged cluster can host both Odoo and GPU nodes together, with the model service and ERP talking over the internal network. Financial reports, customer lists, quoting strategy, and payroll data never leave the data center and never pass through a third-party cloud provider. See Hyperconverged Infrastructure & VMware Alternatives for the underlying platform and hardware planning.
If you need custom modules, external API integration, a multi-company setup, or on-premises deployment, choose a subscription tier that supports customization. Module scope, deployment method, and plan tier should all be confirmed at the selection stage, not adjusted midway through development. Licensing is a per-user subscription. Vendor pricing and promotions change, so the actual figure is quoted at the time.
On-premises model-serving platforms are still quite new - run a proof of concept (POC) before moving to production. How to grade tasks: anything touching finance, customer lists, payroll, or quoting strategy stays on-premises; only low-sensitivity work like general copy editing should be considered for the cloud.
The modules Taiwan customers use most. Enable them as needed, and add more later.
Manages leads and opportunities, showing which stage every deal has reached.
Issue a quote online, convert it to an order with one click once confirmed, and keep every version and its history in the system.
Purchase requests, RFQs, purchase orders, and supplier management, with rule-based automatic reorder suggestions.
Multiple warehouses and storage locations, lot/serial traceability, barcode picking, and stocktaking.
Bills of materials (BOM), work orders, capacity, and scheduling, turning material shortages and progress into numbers you can see.
General ledger, receivables/payables, bank reconciliation, tax, and financial reports - operating data becomes accounting data directly.
Employee records, recruitment, leave, and appraisals. Taiwan payroll rules are built by GN-AI, see the localization section below.
Project tasks, Gantt charts, and time tracking; timesheets can convert directly into billing.
Products, stock, orders, and invoices share the same data as ERP - no separate integration needed.
Retail and restaurant checkout, with offline order entry when the network drops and sync once it's back.
If an e-commerce site or customer login portal will face the public internet, we recommend also assessing protection for it - see Web & API Protection (WAF).
Taiwan regulatory compliance is built and maintained by GN-AI. The vendor provides the chart of accounts, financial report templates, and the value-added-center e-invoicing module; everything else is implemented against current regulations.
Odoo's own Taiwan localization covers four modules: l10n_tw (chart of accounts and business tax defaults), l10n_tw_reports (Taiwan-format financial report templates), and l10n_tw_edi_ecpay and l10n_tw_edi_ecpay_website_sale (issuing and uploading e-invoices through ECPay, a value-added service center, including B2B, B2C, and automatic invoicing for e-commerce orders). The vendor has no module for a direct Ministry of Finance link, and its payroll localization doesn't cover Taiwan. GN-AI builds both of these.
Uses the vendor's module directly; GN-AI configures the setup and process: invoice categories, number-series mapping, allowance and voiding workflows, and automatic invoicing for e-commerce orders. The value-added center absorbs message-format revisions, platform integration changes, and certificate maintenance. Fastest to deploy.
GN-AI develops the integration, connecting directly to the Ministry of Finance's e-invoice integration platform. Scope includes: generating XML per the e-invoice data exchange message specification, number-series allocation and remaining-number management, exchange directory and return-file parsing, monitoring and alerting for the mandated retention deadlines, voiding and allowance workflows, and handling carrier and lottery-winning information. We keep up with spec and Turnkey version updates. Invoice data only ever moves between your data center and the Ministry of Finance platform.
Three questions settle it: how many invoices you issue a year, whether you have staff to run the server and certificates, and whether invoice data is allowed to pass through a third party. High volume, or a requirement to keep data in-house, favors a direct Turnkey link; moderate-to-low volume, or wanting to outsource the technical risk, favors a value-added center. The two paths can also be sequenced: launch quickly through a value-added center first, then migrate once volume grows or security requirements tighten. The invoicing data model can be shared across both.
Odoo's payroll module is a rules engine - you can define your own salary structures and rules - so Taiwan payroll isn't impossible, it just needs someone to build the rules and update them every year. Scope of setup includes:
The competent authority publishes new contribution brackets and rates every year, and the rules have to be updated to match. Annual maintenance keeps tracking this.
Starting from the vendor's Taiwan chart of accounts, we adjust account levels and mappings to match your actual bookkeeping structure. Business tax categories and input/output VAT mapping are set up as well, producing financial reports in Taiwan format. Anything involving accounting policy or tax determination is confirmed first with your professional tax advisor partner and your accountant or certifying CPA, before it's configured in the system.
Labor and health insurance enrollment and withdrawal carry statutory deadlines and bracket obligations. A scheduled job comparing employee onboarding/status changes against the insurance roster suits this well - it surfaces inconsistencies like someone who started but wasn't enrolled, or a raise that wasn't reflected in the insured bracket, and produces a to-do list for HR to act on. On the invoicing side, a daily scan can likewise catch documents stuck unissued, avoiding a missed retention deadline.
An ERP project spans both IT and finance/accounting expertise. Getting the division of labor clear up front is what makes preparation possible.
- Deployment planning: process interviews, document inventory, module and deployment recommendations
- Custom development: building modules for gaps in standard functionality
- Module configuration: fields, form layouts, approval workflows, and report setup
- Taiwan regulatory compliance: e-invoicing implementation, payroll rule setup, and annual updates
- AI adoption: process assessment, data preparation, knowledge base setup, agent development, and on-premises model deployment
- Integration with existing systems: sales/inventory, e-commerce platforms, logistics, and HR systems
- Data migration: customers, suppliers, part numbers, opening inventory, and open documents
- Training and knowledge transfer: hands-on training by department and operating manuals
- Annual maintenance contract: business-hours support, configuration changes, and upgrade assessment
- Designing and adjusting the chart of accounts
- Determining tax setup and filing procedures
- Confirming financial report formats and accounting policy
- Confirming and carrying forward opening balances
Accounting and tax determinations are confirmed jointly by your professional tax advisor partner, your company's accountants, and your certifying CPA. Once confirmed, GN-AI configures the resulting rules into the system. CPA certification and tax certification are part of their own professional scope of service.
Eight stages, each with a deliverable you can sign off on.
An ERP deployment is measured in months. Most of the time goes into clarifying internal processes and ownership, not system configuration. Phased go-live lets the first results show up sooner, and gives you real evidence for how to scope what comes next.
The questions most often asked during requirements interviews.
The Community edition is free and its source code is public. The full accounting, payroll, vendor support, and version upgrades needed for production use are Enterprise-edition subscriptions, and the AI features are Enterprise-only too. Deployment planning, process adjustments, custom development, and training are all real labor costs. ERP cost is never just the license line - we recommend costing it all out together at the selection stage.
Three principles: use standard functionality where it fits, use Studio configuration before writing code, and when customization is unavoidable, extend it with an independent module rather than touching the core. With Odoo.sh or self-hosting, you decide when to upgrade, and test it in a staging environment first. Tracking vendor updates and security advisories is part of annual maintenance; upgrade work itself is a separate line item in the contract.
The source code of custom modules, the database, and the delivered documentation all belong to your company. If you later maintain it yourself or switch consultants, whoever takes over can see the full picture - they won't be stuck because the code is hidden.
No. The agent uses a dedicated system account with the minimum necessary model access rights and record rules. Writes always land in draft or pending-review status. Actions like order confirmation, invoice posting, and sending collection letters stay manual, and every action is logged and traceable in the system. The full scenario is also run in a test environment before go-live.
Yes. An AI agent reads and writes data through an API, so any existing system with a usable interface can be integrated. If the interface isn't good enough, exporting data or using an intermediate database is an option. With Odoo as the data layer, models and fields get an API the moment they exist, so the integration effort is relatively low.
Yes, and it's the recommended approach. CRM or inventory is a common starting point: small scope, visible results, and low impact on daily operations. Expand into purchasing, manufacturing, or accounting once it's running smoothly.
Yes - choose an on-premises deployment with a subscription tier that supports customization. If you're also evaluating the underlying servers, virtualization platform, and GPU resources, we can plan those together - see Hyperconverged Infrastructure & VMware Alternatives.
Two parts. Odoo's license subscription is priced per user and plan tier, set by the vendor. The deployment service fee is estimated from module count, the scope of customization and AI work, and data-migration complexity. Vendor pricing and promotions change, so we don't post numbers on the page - contact us for a quote.
Want to know more about Odoo as a product, or see how we work first?
Odoo brand overview See our servicesLeave your contact details and a description of your needs, and we'll have a consultant and engineer follow up. We can help assess process scope, module and plan selection, AI adoption, Taiwan regulatory compliance items, and annual maintenance.