The Disadvantages of Odoo

A closer look at Odoo’s limitations and how well it might fit your specific business needs

Odoo is exceptionally capable software. Its entry-level paid hosting option, a product with the rather generic name Odoo Online, costs around R480 per user per month in South Africa and provides access to an unusually broad collection of integrated business applications. Accounting, CRM, sales, purchasing, inventory, manufacturing, projects, field service, website, e-commerce, marketing, POS Retail, POS Restaurant, human resources and many other functions can operate on the same platform and share the same underlying business information.

Few business platforms available at anything close to its price offer comparable breadth.

Odoo nevertheless has important disadvantages. Its apparent simplicity can conceal considerable process and technical complexity. Its broad applications may not provide sufficient specialist depth for every business. Standard features do not automatically produce complete, workable business processes. Odoo Online specifically also restricts the custom modules and third-party integrations that can be added, while the subscription price excludes much of the cost of implementing, operating, supporting and upgrading the complete system.

Some of these challenges exist in other business systems, but this is not a feature-by-feature comparison. Those comparisons are useful when choosing between named products, but they can obscure the more important question: whether the software fits the business that intends to use it. We have published more direct product comparisons which you can find here:

Odoo Compared with Three other Comparable ERP packages
https://www.hattonlocks.co.za/odoo-vs-netsuite-vs-sap-one-vs-zoho

More Specifically Odoo vs Zoho One
https://www.hattonlocks.co.za/odoo-vs-zoho

Odoo vs the Sage Range of Accounting and ERP Products 
https://www.hattonlocks.co.za/odoo-vs-sage

The limitations discussed here will be minor for some organisations and decisive for others. The question is not simply whether Odoo has an application or feature. It is whether Odoo can support the way your business needs to operate without unacceptable compromises, manual work, cost or risk.

Odoo can be more complex than it initially appears

Odoo makes many ordinary tasks remarkably simple. A user can create a customer, prepare a quotation, confirm an order, reserve stock and generate an invoice without understanding the technical machinery connecting those transactions. For a small business with conventional processes, Odoo may provide almost everything it needs through standard applications and settings.

The boundary appears when the business stops asking Odoo to perform a standard function and begins asking it to enforce a company-specific set of rules.

Consider purchase approvals. A business might decide that orders above R50,000 must be approved by the managing director. Odoo can handle this. It can also apply approval conditions, use several approval stages, assign approval to users or groups, prevent the same person from approving successive stages and allow an approver to delegate authority temporarily.

The process becomes more substantial when approval depends on a combination of transaction value, legal entity, department, expenditure category, project, budget owner and country. Capital expenditure may follow a different path from operating expenditure. A long-term contract may need legal approval regardless of value. The person requesting a purchase may not be permitted to approve the supplier bill or release the payment.

Odoo may still support the outcome, but the company is no longer enabling an approval option. It is constructing and maintaining a Delegation of Authority system across several applications.

Company size is not the only source of complexity. A small business can cross the same boundary through a specialised process.

Making an online shop available only to registered customers appears simple. A B2B operation may also need to accept customer applications, verify company information, obtain an agreement from an authorised signatory and approve the account before revealing trade prices. Several contacts may belong to the same customer, while having different rights to place orders, view invoices or administer colleagues.

Odoo contains the contacts, company relationships, portal accounts, price lists, documents, signatures and access controls from which such a process can be built. The difficulty lies in joining them into the exact customer journey the business needs. A website setting can therefore become a systems-analysis exercise and, where standard configuration cannot close the remaining gaps, a software-development project.

These examples are not intended to define the limits of Odoo’s approval or e-commerce applications. They illustrate the point at which an ordinary feature becomes a company-specific business system. Similar boundaries appear in pricing, product creation, warehouse scanning, manufacturing, contracts, commissions and reporting.

It is useful to think of Odoo as having three layers.

The first is the simple and obvious layer: documented settings and standard workflows that closely match the way Odoo expects the process to work.

The second is the “that escalated quickly” layer: several roles, applications, rules or exceptions must be coordinated to produce one business outcome. Odoo may still achieve it through process design and advanced configuration, but specialist knowledge becomes increasingly important.

The third is the engine-room layer: the business needs to alter standard transaction behaviour, introduce new application logic or connect an unsupported external service. The solution now involves custom modules, APIs, hosting decisions or software development.

There is no universal boundary determined by employee numbers. A 20-person company with unusual pricing, regulated processes and several external systems may be more difficult to implement than a 600-person company following standard workflows. Nevertheless, scale increases the likelihood of encountering the boundary because it usually introduces more roles, approval levels, locations, transaction volume, exceptions and integrations.

Practical warning signs include repeated phrases such as “only when,” “except if,” “automatically according to,” “different for this group” and “synchronised with our other system.” These do not prove that custom development will be needed, but they indicate that the business is moving beyond activating a feature and into designing system behaviour.

Odoo’s disadvantage is therefore not simply that it is complex. It is that an interface designed to make a vast system approachable can make the distance between standard use, specialist configuration and software engineering difficult to see during an initial evaluation. Establishing where the company’s important processes cross those boundaries is one of the most important tasks before selecting the product and deployment.

Breadth doesn't always provide specialist depth

Odoo’s breadth is one of its greatest strengths. The same platform supports accounting, sales, purchasing, inventory, manufacturing, projects, field service, e-commerce and many other functions. For a small or moderately complex business, this can replace several separate systems.

Each application still has a functional boundary. In manufacturing, Odoo is strongest where production can be described through defined products, bills of materials, operations, work centres and production orders. It supports capacity planning, dependencies, by-products, material consumption, quality checks and traceability.

Consider an industrial bakery producing several types of bread and rolls. Products may share mixers, proofing equipment, ovens and packaging lines while following different recipes, processing times and temperatures. Cleaning and changeovers affect equipment availability, while actual ingredient consumption and production yield vary between batches.

Machine-control systems are usually separate from the ERP. Programmable controllers and factory-automation software operate the equipment, while a manufacturing execution system may collect detailed production information. Odoo sits above this operational layer, using production data for inventory, planning, costing and financial control.

Odoo’s standard manufacturing model fits operations where:

• Products follow known production routes.
• Work centres adequately represent available resources.
• Expected operation times provide useful capacity plans.
• Staff can record material consumption, output and waste against production orders.
• Variations between the planned process and factory activity remain manageable.

The boundary appears as production becomes more dynamic. Warning signs include:

• Several products competing for tightly constrained shared equipment.
• Routes that split, merge or change according to production conditions.
• Setup and cleaning times determined by the sequence of products.
• Materially variable recipes, yields and by-products.
• Frequent rescheduling around breakdowns, delays and changing priorities.
• Costing that depends on detailed machine time, energy use, intermediate output or waste.
• Live production information held in factory-floor systems.
• Advanced finite-capacity or constraint-based schedule optimisation.

At this boundary, the business may need a specialised manufacturing execution or planning system connected to Odoo. Odoo then remains the system for commercial transactions, inventory and financial control while the specialist platform manages detailed production execution.

The accuracy of that connection matters. Where detailed production information cannot pass into Odoo, the implementation begins using averages and estimates. Several operations may be bundled together, machine time averaged across products and standard ingredient consumption substituted for actual consumption.

In a large food-production operation, a persistent 1% variance in flour usage could represent thousands of kilograms. A detailed production model can help connect that variance to dispensing, product weight, waste, recipes, rework or stock leakage. An averaged model reveals only that expected and actual stock differ.

The resulting reports may be arithmetically precise while remaining operationally inaccurate.

Businesses whose production fits defined materials, routes, work centres and production orders are generally within Odoo’s standard manufacturing territory. Businesses whose profitability depends on dynamic factory conditions, advanced scheduling and detailed machine information are approaching its boundary and should assess the production architecture in greater depth.

Odoo may still support almost every administrative function. The decisive gap can sit in the operation that creates the company’s value.

If your business does not manufacture, the manufacturing limitations described above are unlikely to affect it directly. Food-service businesses are a partial exception. Odoo’s Restaurant features form part of Point of Sale, although Manufacturing and bills of materials can also be used to represent recipes, prepared ingredients and stock consumption.

For many restaurants, a standard recipe model is sufficient: Odoo calculates expected ingredient use from the meals sold, while stock counts reveal the overall difference between expected and actual consumption. The boundary appears where the restaurant needs detailed control over variable yields, preparation waste, substitutions, batch production, commissary transfers or ingredient traceability. Large restaurant groups, central kitchens and food-production businesses may therefore encounter some of the same modelling limitations as manufacturers.

Standard features do not create complete business processes

Odoo provides the records, transactions and controls from which a business process can be built. The business must still decide who performs each task, which information must be captured, who verifies it and how exceptions are handled.

Product creation in a distribution business illustrates the difference.

A salesperson may need a new product immediately to prepare a quotation. Purchasing needs the supplier’s product code, cost, lead time and minimum order quantity. Warehouse staff need barcodes, units, pack sizes, dimensions and storage information. Accounting needs the correct product category, tax treatment and valuation method. E-commerce needs attributes, descriptions, images and customer-facing prices.

Odoo can store this information and import large product catalogues, including attributes and variants. Its shared product record allows sales, purchasing, inventory, accounting and e-commerce to work with the same underlying data. That integration creates substantial value, while making mistakes in the product master equally far-reaching.

A tightly centralised process gives one product-management function control over creation. This improves consistency but can delay quotations, purchases and receipts. Staff may respond by using generic products, keeping information in spreadsheets or waiting for an administrator.

A decentralised process improves speed. It also increases the likelihood of duplicate products, inconsistent names, incorrect units, missing costs and inappropriate accounting settings.

The practical solution is often a staged product-onboarding process:

1. An authorised employee requests or creates a provisional product.
2. Each responsible function completes the information it owns.
3. A designated person validates the record.
4. The product is released for purchasing, sale, stocking or publication.

The boundary appears when the business needs Odoo to manage this progression rather than simply store the finished product. Different users may need permission to complete particular fields, while approval status controls where the product can be used. Supplier catalogue updates may also need validation before they change costs, descriptions or variants across thousands of records.

At that point, product creation has become a master-data governance process. Odoo supplies the product model, import tools and access controls, while the complete request, enrichment, validation and release workflow may need advanced configuration or customisation.

The same boundary appears elsewhere. Serial-number tracking becomes a designed process when shared scanners, individual accountability and damaged labels must be handled. Customer pricing becomes one when discounts depend on rolling purchases, contract status and approval. Returns become one when inspection, credit, repair, supplier recovery and stock disposition involve different functions.

A standard feature is usually sufficient where one function owns the transaction, the required information is clear and exceptions are limited. Several contributors, staged approval, conditional access and frequent exceptions indicate a complete business workflow that needs deliberate design.

Odoo’s disadvantage here is subtle: its applications make the individual transactions look complete before the surrounding responsibilities and controls have been defined. The software may contain every necessary component while the usable business process still needs to be engineered.

Odoo Online can restrict essential integrations

Odoo eCommerce is one of the platform’s strongest applications. Products, customers, price lists, inventory, sales orders, payments, invoices, deliveries and portal records all operate within the same system. An online order is already an Odoo sales order, ready to reserve stock and flow into accounting and fulfilment.

The practical boundary often appears where Odoo meets external services.

An online store depends on payment providers, couriers, fulfilment partners, marketplaces and other services. In South Africa, commercial suitability depends on support for the providers customers recognise and the delivery services that can move the product economically.

Odoo Online, the entry-level Odoo-hosted product, provides the lowest infrastructure burden and the tightest technical restrictions. It supports Odoo’s standard functionality and native integrations, while custom server modules and applications from the Odoo Apps Store need Odoo.sh or a self-hosted installation.

That distinction can determine whether the store has a viable operating model.

A South African merchant may need PayFast or another local payment provider, together with The Courier Guy, RAM, Bob Box or another commercially appropriate delivery service. Native Odoo support focuses on a particular selection of international and regional providers. Where the preferred local service falls outside that selection, Odoo Online offers no route for installing an ordinary third-party connector.

The business then has four practical choices:

• Use one of Odoo Online’s supported providers.
• Process part of the transaction manually.
• Move to Odoo.sh or self-hosted Odoo and add the connector.
• Select another e-commerce platform.

The first option works when the supported provider offers suitable prices, services and coverage. Technical compatibility alone provides limited value when a courier’s charge makes the sale commercially unviable.

Manual processing transfers the integration work to the business. An employee or founder must check payments, obtain delivery prices, book collections, capture shipment details, print labels, send tracking information and reconcile discrepancies.

This creates a particular risk for startups. Odoo Online looks attractive while the company is bankrolling the venture and pursuing the lowest possible monthly cost. Low order volumes make manual work appear manageable. Yet the founder’s time moves from finding customers to administering transactions that customers, payment providers and logistics partners could otherwise complete.

Growth then creates a sharp transition. The business must employ someone, build the missing integration, move to Odoo.sh or migrate to another platform. The cheapest deployment can produce the most labour-intensive operating model.

The general boundary is clear:

• Odoo Online is a strong fit where its native payment, delivery and commercial workflows match the business.
• Odoo.sh becomes the practical starting point where important operations depend on third-party modules, custom integrations or server-side development.
• Another platform may fit better where the cost of Odoo.sh and continuing technical support outweighs the value of Odoo’s broader integration.

Odoo.sh creates the ability to install or develop the missing connector. The business must still fund its evaluation, configuration, testing, monitoring and maintenance.

A company evaluating Odoo Online for e-commerce should therefore confirm its payment, delivery, fulfilment and customer-account processes before committing to the platform. These services sit at the edge of Odoo’s system, but at the centre of completing an online sale.

The subscription price is not the total cost of Odoo

Odoo Online starts at around R480 per user per month in South Africa. That price provides access to an extraordinary range of applications, but it covers the software subscription rather than the complete cost of creating and operating the business system.

The initial cost may include:

• Process analysis and design
• Configuration and testing
• Data cleaning and migration
• User training and documentation
• Reports and document layouts
• Payment, courier and other integrations
• Barcode scanners, printers, labels and other hardware
• Custom modules
• Odoo.sh hosting

The importance of these costs depends on where the business sits relative to the boundaries described earlier. A small company using standard sales, purchasing, inventory and accounting processes may stay close to the subscription price. A company with complex approvals, specialised production, B2B customer onboarding or unsupported integrations will need more implementation work.

The cost also continues after launch.

Business processes change. New products, locations, companies and sales channels are added. External providers update their APIs. Users need support. Reports evolve. Incorrect data must be repaired. Access rights need adjustment as people join, leave or change roles.

A capable Odoo partner or internal specialist therefore forms part of the operating model for many implementations. Even a stable system benefits from access to someone who understands its configuration when stock stops reconciling, an integration fails, accounting produces an unexpected result or growth introduces a new process.

Customisation increases that continuing responsibility. A custom module may remove hours of manual work, preserve a valuable business process or connect an essential local service. It also becomes software that must be documented, secured, tested and maintained.

Upgrades make this obligation visible. Odoo releases a major version each year and provides standard support for each major version for three years. Standard implementations are generally easier to move forward. Custom modules, integrations, reports and automated processes need testing and may need modification during an upgrade.

An upgrade project can therefore include:

• Database migration
• Custom-module remediation
• Integration testing
• End-to-end process testing
• User-acceptance testing
• Updated procedures and training
• Production cutover and post-upgrade support

The general cost boundary follows the technical boundary. Standard processes on Odoo Online can remain close to a predictable per-user subscription. Advanced configuration introduces implementation and support costs. Custom applications and integrations add development, hosting and maintenance. Each move into a deeper layer increases both the initial investment and the continuing ownership obligation.

This makes the advertised subscription price a useful starting point and a poor project budget.

A realistic Odoo budget should cover three periods: implementation, continuing operation and periodic upgrades. It should also include the internal time spent defining processes, preparing data, testing the system and helping employees adopt it.

Odoo can remain exceptionally good value after all these costs are included. The disadvantage lies in how easily its low entry price and approachable interface can cause a business to budget for access to the software rather than ownership of the completed system.

When Odoo may be the wrong choice

Odoo works best when its standard applications closely match the business, important processes can be modelled accurately and the available deployment supports every essential integration.

Another system deserves serious consideration where:

• A business-critical operation needs greater specialist depth than Odoo provides.
• Accurate reporting depends on simplifying processes, averaging material differences or maintaining extensive spreadsheet reconciliations.
• Essential payment, delivery, factory or industry systems lack an economically viable integration.
• Odoo Online blocks necessary modules or development, while the cost of Odoo.sh exceeds the value Odoo would provide.
• Manual workarounds would consume substantial employee or founder time.
• Company-specific rules push many processes into advanced configuration and custom development.
• The organisation lacks an internal process owner and has no budget for continuing specialist support.
• Maintaining customisations through upgrades would create disproportionate cost or risk.

The position becomes clearer when these factors are assessed together. One unsupported courier presents a solvable integration problem. Specialist manufacturing, complex authority structures, several unsupported external systems and a limited implementation budget may point to a fundamental mismatch.

Odoo remains particularly strong for businesses that value broad integration and whose important processes fit within its standard model. A smaller company can gain accounting, CRM, sales, purchasing, inventory, projects, website and e-commerce on one platform at a price few comparable systems can approach. Larger organisations can gain the same breadth when they budget for the analysis, technical architecture and continuing support their complexity demands.

The decision therefore rests on four questions:

1. Can Odoo represent the processes that create and protect the company’s value?
2. Which important workflows need specialist configuration, custom development or external systems?
3. Does the selected deployment allow those additions?
4. What will the complete system cost to implement, operate, support and upgrade?

Odoo’s long application list answers the question, “What functions are available?” A sound selection process answers the more important question: “How well will those functions support this business?”

Hatton Locks approaches Odoo from that starting point: assess the fit, identify the boundaries and establish the realistic operating model before implementation begins.