What an Odoo implementation actually costs in Sri Lanka, and what drives the number

We are not going to put a price on this page, and you should be suspicious of anyone who does.

Not because the number is a secret, but because an implementation quoted before anyone has looked at your data is a number that gets walked back, and the walking back is where projects turn adversarial. What is knowable, before anyone talks to a vendor, is the structure of the cost: which components exist, which of them you control, and which three things quietly double a budget.

That is what this article covers. By the end you should be able to read any Odoo proposal you receive and tell whether it has been thought about.

The five components

Every Odoo implementation cost, anywhere, breaks into the same five parts. Proposals that present a single figure are hiding which one grew.

1. Licensing

Paid to Odoo, not to your implementation partner, and priced per user per month with a version and edition attached. Two things follow from that.

First, the user count is a design decision, not a headcount. Shop-floor terminals, kiosk users and portal users are not the same as full internal users, and getting this right is frequently the largest single saving available on a project. Ask your partner to walk through who genuinely needs an internal user account and who does not.

Second, Community versus Enterprise is a real fork. Community has no licence fee. It also has no Gantt view, no studio, and a shorter list of official applications. A well-designed custom module can be community-safe, depending only on base, mail, sale, product and resource, while a Gantt-dependent design forces Enterprise whether or not you wanted it. If licence cost matters to you, ask specifically which features disappear on Community and get the answer in writing before you choose.

A partner who quotes licensing bundled invisibly into their own fee is not doing you a favour. Ask for it separately.

Third, and specific to us: licensing is a currency position, not a fixed cost. It is priced per user per month in dollars and paid abroad, while your revenue is in rupees. Every other component on this list is settled once, in the currency you earn in. This one recurs monthly for the life of the system and moves with the exchange rate, which is why the user count design in the first point above is worth more attention here than the same decision would get elsewhere. Model it over five years at more than one rate before you agree the user list.

2. Configuration

Setting up Odoo to match how your business runs, without writing code: chart of accounts, taxes, product categories, warehouses and routes, work centres, approval rules, user groups and access rights, reports and dashboards.

This is the largest honest line on most projects, and it is where a partner’s experience actually shows. It is also where padding hides. If a proposal quotes custom development for things that are configuration, such as a tax rule, an approval, an email template or a report layout, ask why.

3. Custom development

Proper Odoo modules for things Odoo does not do. In our apparel work that means the critical path and Time and Action engine, fabric wastage, BoM-line sourcing, material codes, per-line delivery dates, costing sheets and a shared operations library. Nine modules, because that is genuinely the size of the gap between a manufacturing ERP and an apparel one.

The cost driver here is not the number of modules. It is how much of your process you are unwilling to change. Every custom module is a piece of Odoo you have agreed to maintain forever, across every future version. Some of them are worth it because the process is your competitive advantage. Many are worth it only because “that is how we have always done it”, and those are the ones to interrogate.

4. Data migration

Consistently the most underestimated line, and the one most likely to move the go-live date.

Migrating a chart of accounts and open balances is bounded work. Migrating fifteen years of product masters, customer records with three spellings of the same company, historical transactions and a stock position nobody has counted since 2019 is not. The determining question is not how much data you have; it is how clean it is, and who is going to clean it.

That work is yours, not the vendor’s, and beginning it before the project starts is the cheapest scheduling decision available to you.

5. Training, change and support

Training scales with the number of distinct roles, not the number of people. Twelve warehouse operators doing one job is one training track. Four departments doing four jobs is four.

Then post-go-live support, which should be a named arrangement with a response time, not goodwill. Budget for the first three months after go-live specifically: that is when the real questions arrive, because that is when people finally have to use the thing.

The three things that quietly double a budget

Independent of size or industry, these are the three we see most often.

Scope that grows one reasonable request at a time. No single change is unreasonable. The sum is a different project. The defence is not saying no; it is a written scope with a change process that prices each addition when it is requested rather than at the end.

No decision-maker. The single largest cause of overrun is not technical. It is a project where every question needs a meeting because nobody is authorised to answer. If two departments disagree about how a process should work, the ERP cannot resolve it, and every day of that disagreement is billed. Name one person who can decide, before the project starts.

Dirty data discovered late. Everyone assumes their master data is fine. It is fine as long as humans are interpreting it. A system will not interpret it. The duplicate suppliers, the three spellings, the products with no category, the stock that does not exist. These surface during migration, which is the worst possible moment, because the go-live date is already public by then.

What actually makes a project cheaper

Four things, in rough order of impact:

1. Adopt the standard process where you have no real reason not to. Every deviation is configuration or code, forever.
2. Clean your data before the project, not during it. Duplicate customers, uncategorised products, an unreconciled stock position. Every one of these is cheaper to fix in a spreadsheet in advance than in a migration script under deadline.
3. Phase it honestly. Finance and one operational area first, then expand. But be careful which thing you defer: deferring the module that made you want a system in the first place guarantees people keep the spreadsheet through go-live, and the spreadsheet becomes the real system.
4. Get the user licensing design right early, because it recurs every month for the life of the system.

How the number scales with the shape of your business

Without quoting figures, it is still useful to know which shape you are, because the components above sit in very different proportions in each.

Shape A: finance and distribution, standard processes. A trading or distribution business putting accounting, inventory, purchasing and sales onto one system. Configuration dominates. Custom development can legitimately be zero. Migration is the risk, because it is all master data and open balances. If a proposal for this shape carries a large development line, ask what is being built and why the standard applications will not do it.

Shape B: one specialised operation plus the standard back office. A hotel, a garment factory, a property manager. Configuration is still the largest line, but there is a real custom layer over the part of the business no general ERP models, and that layer is where the value is. Here the question is not whether to build, but whether the boundary between standard and custom has been drawn deliberately.

Shape C: multi-entity, multi-currency, or heavily regulated. Consolidation, intercompany flows, several tax regimes, audit requirements. The cost driver moves away from features and towards design decisions, most of them in accounting. The expensive mistake in this shape is starting configuration before the entity and consolidation structure is settled, because redoing it later means redoing everything downstream of it.

Most Sri Lankan mid-market projects are Shape B. Knowing which you are tells you where to spend your own attention during scoping.

What is different about doing this in Sri Lanka

Most published guidance on Odoo cost is written for Europe or North America. The five components are the same everywhere, but four things sit differently here, and all four land in the configuration and scoping lines rather than in licensing.

Statutory configuration is work, not a checkbox

Payroll and tax are where a general assumption that “the standard localisation covers it” gets expensive. EPF at 12% employer and 8% employee, ETF at 3% employer, your VAT and SVAT position, withholding, and the Factories Ordinance caps of eight ordinary hours a day and forty-five a week all have to be represented correctly, along with a working calendar that carries poya days and both new years. None of it is difficult. All of it is billable, and a proposal that has not named it has not been through a Sri Lankan payroll run.

If your operation is a factory floor of several hundred people, treat payroll as one of the two modules users will notice on day one if it is wrong. The apparel side of this is covered in more depth in what an apparel ERP has to cover for a Sri Lankan factory.

The bench is thin, and that changes the arithmetic

There are not many people in the country who have taken an Odoo implementation from scoping to a stable second year. That scarcity shows up in rates, but the rate is the smaller half of it. The larger half is that a team learning Odoo on your project bills the learning to you, in rework and in decisions that get revisited after they have been built on.

The honest comparison is therefore almost never a partner against no partner. It is a partner who has delivered against one who has not, and the second is usually more expensive by the end of the first year even when the day rate is lower. Ask to speak to a customer who went live more than eighteen months ago. That single conversation prices more risk than any line in a proposal.

Hosting, and where the data actually sits

Odoo Online is the simplest answer and removes an entire operational line from your budget. It is also a decision about latency, about what happens to your working day when an undersea cable has a bad afternoon, and about whether anything in your data has a residency requirement attached to it. Local or regional hosting answers those, and in exchange you take on backups, a staging environment, monitoring and someone to call at two in the morning.

Neither is wrong. What is wrong is discovering after configuration has started that the answer was forced by a requirement nobody asked about.

For exporters: the reconciliation nobody scopes

If you import materials under inward processing, relief from duty is conditional on those materials leaving the country again as finished goods, and proving it is your obligation rather than your supplier’s. In software terms the system has to be able to state, per export shipment, how much of which imported material went into it, wastage included.

This is the requirement most often discovered late on manufacturing projects here, and late is the expensive time to discover anything. If it applies to you, put it in the scope in writing before you compare proposals, because a system that models consumption as a flat bill-of-materials quantity cannot produce that number and somebody will end up rebuilding it in a spreadsheet every month for the life of the system.

The costs that arrive after go-live

Implementation is a project. Ownership is a subscription, and it has four recurring parts worth budgeting from day one.

Licensing, monthly, forever, scaling with users.

Hosting and operations, unless you are on Odoo’s own cloud. Backups that have actually been restored at least once, a staging environment, monitoring, and someone whose job it is when the server does not come back after a reboot.

Version upgrades. Odoo ships a major version annually and supports a rolling window of them. Standard configuration upgrades cheaply. Custom modules need work at each major version, and Studio customisations are the least predictable of all. This is the single strongest argument for keeping the custom layer small, deliberate and in version control with tests. The cost of that discipline is paid once and the saving repeats annually.

Continuous change. The business will not stop changing. Budget for a small ongoing capacity rather than treating every request as an exception, or you will find yourself choosing between paying project rates for a two-hour change and not making it at all.

A five-year total cost of ownership that ignores the upgrade path is not a total cost of ownership.

Fixed price or time and materials

Both are defensible. What is not defensible is either one without a scope.

Fixed price transfers risk to the partner, and the partner prices that risk. It works when the scope is genuinely knowable in advance, which usually means after a paid discovery phase, not before one. Its failure mode is an adversarial change process, where both sides spend the project arguing about what was included.

Time and materials is honest about uncertainty and can be cheaper when the partner is good, because you are not paying a risk premium. Its failure mode is a project with no natural end. Cap it: agree a not-to-exceed figure per phase and a review point.

The practical answer for most mid-market projects is a paid discovery phase, then fixed price per phase against the specification discovery produced, with a named change rate. That way each side takes the risk it can actually control.

Seven questions that reveal a weak proposal

Read any proposal with these in hand.

1. “Which lines here are configuration and which are code?” A proposal that cannot separate them has not been estimated, it has been guessed.
2. “What did you assume about our data?” If the answer is nothing, migration is unpriced and will return as a change request.
3. “Which customisations are Studio?” And what happens to each at the next major version.
4. “What is not included?” A proposal with no exclusions section is not a scope.
5. “Who from our side do you need, and for how many hours a week?” Your people are a real cost of the project, and a partner who has not thought about it has not run many.
6. “What happens in the first month after go-live?” The correct answer involves named people and a response time.
7. “What would make this project fail?” A partner who cannot answer this has either not delivered many or is not being straight with you. The honest answers are always the same: no decision-maker, dirty data, and scope that was never written down.

What to require from a proposal

Whoever you are talking to, including us, require these:

• Licensing shown separately from services, with the user types named
• Configuration and custom development as separate lines, with the custom modules listed
• A statement of which customisations are modules and which are Studio, and what happens to each at the next major version
• Data migration scoped against your actual data, after someone has looked at it
• A named change process with a rate, agreed before work starts
• Post-go-live support as a defined arrangement, not an implication
• A timeline in writing, produced after a scoping exercise rather than before one

Why we scope before we quote

We would rather do a paid scoping exercise and give you a number we can stand behind than win the work with an optimistic figure and spend the project defending it. It is a slower sales process and it produces fewer surprises for both sides.

If you want a realistic figure for your business, the fastest route is to send us the shape of it: how many users, which departments, what you are running today, and how bad the data honestly is. We will tell you what the drivers above look like for you, including the ones that make it more expensive than you were hoping. You can see how we run an implementation before you contact anyone.