In this article
- What you pay Odoo for Enterprise licences
- Standard versus Custom changes the delivery model
- User counting is where licence budgets often fail
- What you pay an Odoo implementation partner
- A worked budgeting example
- A multi-entity example
- Tax, hosting and renewal costs that sit outside the headline price
- Local VAT on partner invoices
- Odoo.sh and custom-code maintenance
- Renewals and version coverage
- How to build an auditable Odoo cost model
- Questions to put to Odoo and your implementation partner
- Frequently Asked Questions
- Is there one Odoo Enterprise licence price for Africa?
- Does the Odoo Enterprise subscription include implementation?
- Do customer portal users need paid Odoo licences?
- Should we include VAT in our Odoo budget?
A CFO approves an Odoo budget based on a per-user figure, then receives a second proposal for data migration, integrations, training and local tax configuration. Neither document is necessarily wrong. They cover different obligations, and mixing them is how an apparently approved ERP budget becomes a board escalation.
The Odoo Enterprise licence cost is the amount paid to Odoo for the software subscription. Your implementation partner separately prices the work required to make that software operate across your entities, processes, users and compliance obligations. As of 5 October 2026, that distinction should be the starting point for every African ERP business case.
When comparing Odoo pricing / Odoo implementation cost, we recommend that finance teams request two linked schedules: one from Odoo for subscriptions and hosting, and one from the delivery partner for professional services, support and localised compliance work. A single total without those divisions is difficult to audit.
What you pay Odoo for Enterprise licences
Odoo does not publish one Africa-wide Enterprise price. Its pricing is configured by the customer’s selected country and billing term. We therefore do not recommend taking a displayed US dollar figure and presenting it as the recurring licence cost for Zambia, Kenya, South Africa, Zimbabwe, Nigeria or any other African market.
For reference, Odoo’s publicly displayed US annual-billing promotion is US$24.90 per Standard user per month and US$49.00 per Custom user per month for the first 12 months of initial users. The stated regular prices are US$31.10 for Standard and US$61.00 for Custom, per user per month. These are pricing-page reference points, not an Africa-wide price list.
The practical rule is simple: ask Odoo to quote the selected billing country, the intended term, the edition and the user assumptions. That quote is the number your board should approve for the subscription.
Standard versus Custom changes the delivery model
| Cost area | Standard plan | Custom plan | Why it matters | | Deployment | Odoo Online only | Odoo.sh or self-hosting available | Hosting and technical control affect the implementation scope. | | Studio | Not included in the published Standard description | Included | Configuration requirements should be agreed before build begins. | | Multi-company | Not included in the published Standard description | Included | Group structures often need multi-company controls and intercompany visibility. | | External API | Not included in the published Standard description | Included | Integration to banks, payroll, fiscal devices or legacy systems may require API access. | | Odoo.sh | Not applicable | Separately charged | Hosting variables can add cost beyond the Custom user subscription. | Standard is suitable only where Odoo Online and its available configuration meet the operating requirement. If the programme needs multi-company capability, external API integration, Studio, Odoo.sh or self-hosting, Custom is the relevant starting point.
That does not mean every business should choose Custom. If a single-entity distributor has no required external integrations and can operate within Odoo Online, paying for a more technical deployment model may not produce measurable ROI. The decision should follow the operating design, not a preference for flexibility.
User counting is where licence budgets often fail
Odoo charges for active backend users. Portal users are not charged in the same way. This distinction matters because customers and suppliers who only use a portal should not automatically be included in the Enterprise licence count.
There is a less obvious point: Odoo’s pricing treatment includes an employee HR record without login credentials as a paying user. Finance and HR teams must therefore validate the exact user definition in the Odoo quotation rather than counting only named system logins.
Ask these questions before signing:
1. How many active backend users will transact, approve or administer records?
2. How many employee HR records are included in the billable user assumption?
3. Which external users will use the portal only?
4. Which entities need access under the same subscription design?
5. What is the licence position if headcount rises during the term?
The step most teams skip is reconciling the HR employee list to the user quote. It should happen before procurement approval because a payroll of 400 people and a named-login list of 90 people may produce materially different licence assumptions.
What you pay an Odoo implementation partner
The partner contract covers work that an Odoo subscription does not include. Odoo does not publish a universal partner implementation fee, hourly rate or fixed percentage of licence cost. A partner proposal is a separately scoped professional-services contract.
For projects with more than 50 users, Odoo itself recommends local-partner delivery. That recommendation reflects the volume of decisions involved in process design, master-data preparation, training, security, migration and go-live support. Software access alone does not complete those decisions.
A credible Odoo implementation proposal should separate the following workstreams.
| Workstream | What should be defined | Why boards should require it | | Discovery | Entities, processes, gaps, reporting requirements and decision owners | Undefined requirements become change requests later. | | Configuration | Modules, workflows, roles, approval rules and chart-of-accounts design | This determines whether controls are auditable in daily use. | | Data migration | Data sources, cleansing rules, opening balances, history and reconciliation sign-off | Poor master data creates operational errors after go-live. | | Tax localisation | Tax treatment, invoice fields, reporting needs and local compliance scope | Each jurisdiction has its own tax authority and operating practice. | | Integrations | Systems, APIs, ownership, test cases and failure handling | An interface is not complete until exceptions are tested. | | Training | Role-based sessions, attendance and user readiness | Training reduces dependency on a small group of system administrators. | | Go-live and support | Cutover plan, hypercare period, support hours and escalation route | The first close cycle exposes issues that testing did not reveal. | We advise procurement teams to require stated assumptions, deliverables, exclusions, acceptance criteria, change-control rules and support hours. A low professional-services figure with broad exclusions is not automatically the lower-cost option.
A worked budgeting example
Take a retailer with 12 staff and a US$40,000 monthly payroll. It has one operating entity, basic inventory requirements and no confirmed need for external API integrations. It may be tempted to use the promotional US Standard reference price multiplied by 12 users, then treat that result as the full ERP budget.
That approach omits migration, configuration, training and any tax localisation assessment. It may also miscount staff if employee HR records are treated as billable under the agreed Odoo terms. We would first establish whether each of the 12 people requires a backend role, whether customers need only portal access, and whether Odoo Online meets the required control model.
If the business has not documented its processes or cleaned product and customer data, it should not seek a fixed implementation number yet. The better decision is a defined discovery phase, because the cost of correcting opening balances after go-live is usually greater than validating them before migration.
A multi-entity example
Take a regional wholesaler with five entities, 85 operational users and a requirement to integrate an external system. The team initially budgets the US$49.00 Custom promotional reference figure for 85 users over 12 months, or about US$49,980 before any country-specific quote, hosting, VAT or partner services.
That number is only a licence reference calculation. The Custom plan can require separately priced Odoo.sh hosting, where workers, storage and staging environments affect the cost. The implementation scope also needs multi-entity configuration, user permissions, data migration by entity, integration testing, consolidated reporting design and training across the group.
For this profile, do not bother trying to approve a licence-only business case. The integration and group-control requirements make the delivery scope material. We would require a phased implementation plan and a clear split between Odoo charges, hosting charges and partner charges before approving the programme.
Tax, hosting and renewal costs that sit outside the headline price
A board-ready ERP budget needs more than a per-user rate. The following items routinely appear after the initial subscription discussion.
Local VAT on partner invoices
A locally VAT-registered implementation partner may add local VAT to implementation and support invoices. Illustrative standard VAT rates are Zambia 16%, Kenya 16%, South Africa 15%, Zimbabwe 15.5% and Nigeria 7.5%. The applicable tax treatment for a cross-border Odoo subscription requires country-specific tax advice.
Zimbabwe increased VAT from 15% to 15.5% from 1 January 2026. South Africa’s 2026 SARS guidance states a 15% VAT rate and compulsory VAT registration above R2.3 million in annual taxable supplies. These details matter because the supplier location, invoice structure and imported-services treatment can affect the cash budget even where input VAT may be recoverable.
We recommend that the finance lead asks for invoices to be modelled separately for subscription, Odoo.sh hosting and implementation services. That gives tax advisers enough information to assess the correct treatment before contracts are signed.
Odoo.sh and custom-code maintenance
Odoo.sh is not included in the displayed Custom user price. Odoo’s configurator separately presents hosting variables, including workers, storage and staging environments. Treat it as an Odoo cost in addition to licences, not automatically as partner revenue.
Where custom code is introduced, also price the maintenance obligation. A change in an integration, an upgrade requirement or a defect can require technical support beyond the original build. The contract should state who owns the code, who supports it, what is included and what triggers a change request.
Renewals and version coverage
Enterprise subscriptions renew automatically for the same term unless either party gives at least 30 days’ termination notice. Put that date in the procurement contract register, with a named owner. Missing it can extend a commitment that the business intended to review.
Odoo also states that running a version outside its three covered major versions can trigger a 25% surcharge on the annualised price. This is why an upgrade plan is a financial control, not only an IT housekeeping activity.
How to build an auditable Odoo cost model
We use a four-part structure when reviewing Odoo ERP budgets for African enterprises.
6. Subscription schedule: Record the selected country, plan, billing term, chargeable-user assumption and recurring subscription price from Odoo.
7. Platform schedule: Record Odoo.sh or self-hosting requirements, storage, workers, staging environments and the owner of platform administration.
8. Implementation schedule: Record discovery, configuration, tax localisation, migration, integrations, training, go-live and support as separate deliverables.
9. Tax and contingency schedule: Record VAT assumptions, imported-services advice where relevant, change-control allowance and upgrade obligations.
This structure makes comparison possible. It also prevents a common procurement error: comparing one partner’s comprehensive delivery proposal with another party’s licence-only estimate.
For multi-entity organisations, add a fifth schedule for rollout sequencing. A first entity may expose chart-of-accounts, stock, approval or data-quality decisions that should be resolved before the next entity is deployed. The ROI case should therefore distinguish the initial implementation cost from repeatable rollout effort.
Questions to put to Odoo and your implementation partner
Before approving the contract, ask Odoo:
● What is the quoted price for our selected country and billing term?
● Which employee records and users are billable under this quotation?
● Is Odoo.sh included, and if not, what hosting variables drive the cost?
● What date must we give notice to avoid automatic renewal?
Ask the implementation partner:
● Which tax localisation requirements are included for each legal entity?
● Which integrations are included, and what test evidence will prove they work?
● What migration reconciliation must finance sign before go-live?
● How many training, hypercare and continuing support hours are included?
● What is excluded, and how are changes priced and approved?
The response should be specific enough for a CFO to reconcile it to the programme budget. “ERP implementation support” is not a deliverable. “Migrate approved opening balances for five entities, reconcile to signed finance extracts, and support the first month-end close” is a deliverable.
Frequently Asked Questions
Is there one Odoo Enterprise licence price for Africa?
No. Odoo pricing is country-configured. Use the quote for your selected country and billing term rather than treating publicly displayed US promotional pricing as an Africa-wide rate.
Does the Odoo Enterprise subscription include implementation?
No. The subscription pays Odoo for software access. Discovery, configuration, data migration, tax localisation, integrations, training, go-live and partner support are separately scoped professional services.
Do customer portal users need paid Odoo licences?
Portal users are not charged in the same way as active backend users. Confirm the planned access model in the Odoo quote before buying licences for customers or suppliers.
Should we include VAT in our Odoo budget?
Yes. Include VAT assumptions for local partner invoices and obtain country-specific advice on cross-border subscription and imported-services treatment. Illustrative VAT rates should not replace a tax review.
Odoo pricing deserves the same control as any significant ERP investment: a quoted subscription, a scoped implementation contract and a documented tax position. Request a Consultation to build an auditable Odoo ERP cost model for your entities, users and compliance requirements.