Key Takeaways: What most people describe as an “AI-built ERP” is a well-functioning business app: genuinely useful, impressive to build, and adequate for simple operations. The gap between that and a real ERP is not a featureAn individual measurable property or characteristic of the data used as input to a model. Feature engineering — selecting, transforming, and creating features — is a critical step in the ML pipeline. list. It’s a decade of edge cases, compliance depth, data integrity guarantees, and ecosystem integrations that no promptThe input text provided to an LLM to guide its response. Prompt design — choosing words, structure, and examples — significantly affects output quality. Also referred to as the user message or query. session has yet produced. The right question is not “replace or not?” It’s where AI fits in the ERP stack, and what it changes about how ERPs get customised and extended.
The question arrives in some form every few months, and it’s getting more concrete. Someone builds a working invoicing tool with Claude in an afternoon: client records, VAT calculation, PDF output, the lot. It works. They show it to a colleague. The colleague says: could you just keep going and replace Odoo entirely?
It’s a fair question. Worth taking seriously.
What Actually Gets Built
The tools AI generates quickly are real. An invoice generator that calculates VAT, manages a client list, and produces PDF documents is not a toy; it’s functional software that a small business could run on. The time to produce it has gone from weeks to hours. That’s a genuine shift, not hype.
But there’s a naming problem. An invoicing app is not an ERP. The conflation is understandable; both touch invoices. But the difference isn’t cosmetic.
An ERP is an integrated system where financial transactions, inventory movements, sales commitments, purchase obligations, HR records, and production plans are all the same data, updated in real time, with constraints that prevent the data from becoming incoherent. When a sales order is confirmed, stock is reserved. When goods are received, accounting entries are created. When a payment is posted, the receivable is cleared. This isn’t a collection of features; it’s a data architecture with decades of business logic baked in.
Generating invoices is not hard. What’s hard is the whole thing holding together when a customer partially pays in a different currency, the goods were returned against a credit note issued in a prior fiscal year, and the auditor needs a report that ties back to the original transaction.
The Parts Claude Doesn’t Know Are Missing
The features that make ERP difficult are mostly invisible to someone who hasn’t needed them yet. A few specifics:
Accounting compliance is not VAT. VAT calculation is the entry ticket. A compliant accounting system handles deferred revenue recognition, intercompany eliminations, fiscal year locking (you cannot post to a closed period), chart of accounts standards that vary by jurisdiction, tax declarations in machine-readable formats for government submission, and audit trails that satisfy actual auditors, not just developers. Miss any of these in a real business and the problem is legal, not technical.
Data integrity at scale is architectural. A promptThe input text provided to an LLM to guide its response. Prompt design — choosing words, structure, and examples — significantly affects output quality. Also referred to as the user message or query.-generated app typically produces a data modelA mathematical function trained on data that maps inputs to outputs. In ML, a model is the artifact produced after training — it encapsulates learned patterns and is used to make predictions or… that works for the demo and degrades under load. Relational databases with proper foreign key constraints, transaction isolation, and rollback semantics exist because it took the industry decades to learn what happens without them. When you have ten years of invoices, fifty thousand inventory movements, and concurrent users posting in multiple sessions, “it works in testing” is not a guarantee of anything.
Integrations are not optional additions. Odoo connects to banks via bank statement import protocols, to payment gateways, to shipping carriers, to e-commerce platforms, to government e-invoicing systems. In Vietnam, that means the Cục Thuế’s electronic invoice format; in other markets, it means something else. Each integration has its own protocol, edge cases, and compliance requirements. They don’t come from a promptThe input text provided to an LLM to guide its response. Prompt design — choosing words, structure, and examples — significantly affects output quality. Also referred to as the user message or query.. They come from years of implementation work.
Schema migration is where vibe-coded systems collapse. The first version of any software is easy. The second version, which needs to change the data modelA mathematical function trained on data that maps inputs to outputs. In ML, a model is the artifact produced after training — it encapsulates learned patterns and is used to make predictions or… while preserving three years of existing records, is not. ERPs have formal migration frameworks. PromptThe input text provided to an LLM to guide its response. Prompt design — choosing words, structure, and examples — significantly affects output quality. Also referred to as the user message or query.-generated systems usually don’t, because the person building them hasn’t needed a migration yet.
Context windows have a ceiling. The Odoo codebase is millions of lines. No AI modelA mathematical function trained on data that maps inputs to outputs. In ML, a model is the artifact produced after training — it encapsulates learned patterns and is used to make predictions or… today can hold it in context, reason about the full interaction between modules, and generate a coherent extension. Building individual features is tractable. Building something with the same depth of integration, where every module understands the state of every other module, is not a prompt engineeringThe discipline of designing and optimizing prompts to elicit desired outputs from generative AI models. Effective prompt engineering involves choosing the right instruction format, context, examples,… problem. It’s an architecture problem.
Where the Comparison Actually Has Force
Dismissing this entirely would be wrong. There are scenarios where an AI-built system is the right answer:
A very small business with simple, stable operations and no compliance requirements beyond basic VAT may genuinely be better served by a lightweight tool built to exact spec than by a full ERP implementation. Odoo implemented badly is not better than a well-built simple app. The “right tool for the job” argument is real.
AI is also changing what’s possible at the top of the stack. Generating Odoo modules, writing custom reports, scaffolding new workflows: these are tasks where AI-assisted development is already dramatically faster than traditional development. The foundation stays solid; the customisation layer gets built faster. This is probably the most practically significant shift in Odoo implementation work right now.
And the ERP vendors themselves are moving. Odoo has already announced Claude integration. The future of ERP is not AI instead of ERP; it’s AI operating inside a structured, compliant, auditable ERP environment that handles the hard parts the AI was never designed to handle.
The Right Mental Model
Think of it this way. A contractor who knows construction can build a house that meets code, handles load-bearing walls correctly, has proper electrical earthing, and will still be standing in thirty years. A talented amateur using good tools can build something that looks like a house and functions like a house, until the thing it got wrong matters.
For small, controlled, low-stakes operations: the talented amateur’s house is fine.
For a company with employees, auditors, multiple currencies, government reporting obligations, and data it cannot afford to lose or corrupt: the contractor exists for a reason.
The AI moment doesn’t change what ERPs are for. It changes who can build things quickly and what it costs to customise them. That’s genuinely important, but it’s not the same claim as “Odoo is replaceable.”
What This Means in Practice
If you’re evaluating this question for a real business, the honest framing is:
What are your actual compliance requirements? A business with straightforward needs in a single jurisdiction with standard accounting can run lighter software. A business with multi-entity structures, regulated industry requirements, or government e-invoicing mandates cannot.
What happens when something goes wrong? An AI-generated system has no ecosystem, no certified consultants, no documented upgrade path, and no community of people who’ve seen the same bug before. When something breaks, the cost of recovery is entirely on whoever built it.
What’s the five-year view? Software that can’t be upgraded or maintained by anyone other than its original builder is a liability that grows over time. The VBA macro that nobody dares touch is not a hypothetical; it’s the standard outcome for tools built outside a maintainability discipline.
The businesses most likely to regret AI-built ERP replacements are the ones that adopted them during a period of simplicity and discovered the limitations at precisely the moment the business became complex enough to need them.
At Trobz, we build on Odoo and we use AI to do it faster. If you’re thinking about what AI-assisted customisation looks like in practice, let’s talk.