Yes, under Odoo 20 Enterprise licensing, an active HR employee record can count as a Light User even when that employee does not have a normal internal-user account.
That makes the Light User definition particularly important for companies with large workforces planning an Odoo 20 implementation or upgrade.
A business may have only 20 people working directly inside Sales, Accounting, Inventory, Purchase or CRM, but hundreds of employee records inside Odoo HR. Looking only at the number of traditional Odoo logins can therefore give an incomplete picture of the subscription impact.
The important question is not simply:
How many employees have an Odoo login?
Businesses evaluating Odoo 20 should also ask:
How many active employee records do we have, what type of access does each person require, and how does Odoo classify them?
This guide explains the distinction. One clarification first: this definition is not new in Odoo 20. The same wording appears in Odoo's Enterprise Subscription Agreement for versions 17, 18 and 19, and it applies "where supported by the Customer's version of the Software". An upgrade is simply a good moment to check it.
What is a Light User in Odoo 20?
Odoo's current Enterprise Subscription Agreement defines a Light User as an active account designated as a Light User or an active employee record in the HR application that is not linked to an active non-portal user account.
That second part is important.
An employee does not necessarily need a traditional internal Odoo login to be relevant to the subscription calculation.
According to Odoo's agreement, subscription charges are based on the number of Users, Light Users and the selected Subscription Plan.
Official source: Odoo 20 Enterprise Subscription Agreement
This is why companies using Odoo HR should review their workforce data before estimating the cost of an Odoo 20 deployment or upgrade.
Does Odoo 20 charge for every employee?
The more accurate answer is:
An active employee record can qualify as a Light User under the Odoo 20 Enterprise subscription terms.
That is different from saying that every person associated with your company automatically requires a normal full Odoo license.
The distinction between a Full User, Light User and portal/external user matters.
For example, consider a company with:
- 20 employees who actively work in Odoo Sales, Accounting, Purchase and Inventory;
- 180 additional active employees maintained in Odoo HR.
It would be misleading to estimate the subscription using only the 20 traditional internal users.
The active HR employee population must also be reviewed against Odoo's Light User definition and the company's actual subscription agreement.
How much does an Odoo 20 Light User cost?
Odoo's public pricing page varies by country. When we checked it on 11 October 2026, it displayed a Light User price of US$5.90 per user per month. The same page says a Light User licence is arranged through an Odoo advisor, who provides a quote for the organization.
Current pricing should always be verified directly with Odoo because prices, discounts, currencies, regions, contract terms and commercial offers can change.
Official pricing: Odoo pricing
To understand the scale, consider an illustrative example.
If 180 employees were billed as Light Users at US$5.90 per month:
180 × $5.90 = $1,062 per month
or:
$12,744 per year
That figure covers only the illustrative Light User calculation. It does not include Full Users, implementation, hosting choices, custom development, taxes, discounts or any negotiated commercial terms.
It is not a quotation for an actual Odoo subscription.
For a company with hundreds or thousands of employees, however, the calculation shows why workforce structure should be considered before an Odoo 20 migration.
Full User vs Light User vs Portal User
These categories should not be treated as interchangeable.
Full User
A Full User is typically someone who needs normal internal access to business applications and workflows.
Examples can include:
- accountants;
- salespeople;
- purchasing teams;
- inventory managers;
- CRM users;
- administrators;
- operational managers.
The exact access should still follow the principle of least privilege.
Light User
A Light User is designed around more limited usage.
The important licensing point in the current terms, including Odoo 20, is that the definition also covers certain active HR employee records even when they are not linked to an active non-portal user account.
Companies with large HR databases therefore need to understand the Light User model even if most employees never use the traditional Odoo backend.
Portal User
Portal access serves a different purpose.
Portal users are generally external parties such as customers or suppliers who need controlled access to information exposed through Odoo's portal.
A portal user should not simply be considered an alternative name for an employee Light User.
When designing an Odoo environment, classify people according to their real relationship with the business and the access they genuinely require.
"But most of our employees never log in to Odoo"
This is exactly where the Light User definition becomes important.
Imagine a company with 500 employees.
Only 35 people use the traditional Odoo backend.
The remaining workforce may interact with HR processes such as:
- employee profiles;
- attendance;
- time off;
- documents;
- payslips;
- approvals;
- expenses;
- scheduling;
- internal HR services.
Historically, management may have focused almost entirely on the number of backend users when estimating ERP licensing.
Under the Odoo 20 Enterprise terms, the active employee records themselves need to be reviewed because an active HR employee without an active non-portal user account falls within Odoo's Light User definition.
For workforce-heavy businesses, that can materially change the commercial assessment.
Which businesses should pay particular attention?
The Light User model is especially relevant when Odoo is used as the HR system of record for a large workforce.
Examples include:
- construction companies;
- healthcare providers;
- hospitality groups;
- retail chains;
- facilities-management companies;
- logistics businesses;
- security companies;
- manufacturing organizations;
- companies with large field-service teams;
- multi-branch organizations.
A business might have relatively few ERP power users while maintaining hundreds or thousands of active employees in HR.
That makes employee count and access architecture an important part of Odoo 20 planning.
Should we simply archive employees to reduce the subscription?
Do not manipulate legitimate employee status simply to avoid licensing.
Instead, use the licensing review as a reason to improve HR data hygiene.
Before an upgrade, review whether your database contains:
- former employees still marked active;
- duplicate employee records;
- test employees;
- obsolete imported records;
- inactive contractors incorrectly represented as active employees;
- users with unnecessarily broad access;
- old environments containing production-like employee data.
Former employees who genuinely left the organization should already be handled correctly for operational, reporting and security reasons.
The objective is an accurate database—not artificial employee counts.
Does every employee need to become a Full User?
No.
The important question is what the employee actually needs to do.
An accountant who manages journals, payments and financial operations has very different requirements from an employee who only needs limited HR interactions.
Do not grant full ERP access simply because it is easier during implementation.
A good Odoo access design should map roles to actual business requirements.
That improves security and can also prevent unnecessary licensing complexity.
What should companies check before upgrading from Odoo 19 to Odoo 20?
Do not evaluate the upgrade purely as a technical migration.
Include a licensing and access audit.
1. Count active employee records
Determine how many legitimate active employees currently exist in Odoo HR.
Separate them from archived employees, test records and duplicates.
2. Count active internal users
Identify employees who already have active internal Odoo accounts.
Document which applications and permission groups they actually require.
3. Identify external portal users
Separate customers, suppliers and other external portal identities from the internal workforce.
4. Map employee workflows
Document what employees actually need from Odoo.
For example:
Employee A
→ attendance
→ time off
→ payslips
Manager B
→ employee self-service
→ team approvals
→ attendance review
Accountant C
→ accounting
→ invoicing
→ payments
→ reportingThe required capabilities are different, so the access design should be different.
5. Review the commercial impact before production migration
Do not discover the licensing impact after completing the technical upgrade.
Ask Odoo or your authorized Odoo partner to confirm how the current subscription terms apply to your specific database, region, edition and contract.
What about custom employee mobile apps?
This is an important architectural question.
Many companies use a custom Flutter application or employee portal instead of exposing the full Odoo backend to every employee.
A mobile application can provide a much simpler experience for:
- attendance;
- leave requests;
- payslips;
- HR letters;
- announcements;
- documents;
- approvals;
- tasks;
- field operations.
But building a custom interface does not automatically remove or alter Odoo licensing obligations.
Licensing and application architecture are separate questions.
If Odoo remains the system of record, the company's Odoo agreement and the way employee records and users are represented still need to be evaluated.
For more on mobile architecture, see Odoo Mobile App Development That Stays Connected.
A 1,000-employee example
Consider a business with:
1,000 active employees
but only:
60 traditional ERP users.
Management might begin its budgeting discussion with those 60 users.
Under the Enterprise terms, that is not enough information to evaluate the subscription.
The company should determine:
Total active employees
↓
Employees linked to active internal users
↓
Remaining employee records potentially falling under Light User definition
↓
Portal/external identities
↓
Required applications and access
↓
Applicable Odoo subscription termsOnly after this audit can the business build a meaningful licensing estimate.
For organizations at this scale, even a small per-employee pricing assumption can have a significant annual impact.
Do not rely on an old Odoo pricing spreadsheet
Odoo evolves quickly.
A pricing calculation prepared for an older version may not correctly represent an Odoo 20 deployment.
Before approving an upgrade, verify:
- current Odoo Enterprise terms;
- current Light User definition;
- current public pricing;
- your existing contract;
- regional/commercial conditions;
- active employee count;
- active Full User count;
- portal usage;
- required applications;
- hosting and customization requirements.
Most importantly, distinguish official Odoo pricing from estimates made by implementation partners or internal teams.
The takeaway
The biggest misunderstanding around Odoo 20 Light Users is assuming that only employees with normal backend logins matter.
Under Odoo's current Enterprise Subscription Agreement, which covers Odoo 20, an active HR employee record that is not linked to an active non-portal user account can fall within the definition of a Light User.
For a company with 20 employees, the commercial effect may be relatively small.
For a company with 500, 1,000 or 5,000 employees, it deserves serious attention before an upgrade or new implementation is approved.
The right response is not to avoid Odoo HR or manipulate employee records.
It is to understand the licensing model, clean the HR database, classify users correctly, design access around actual business requirements and calculate the impact before production.
If you are planning an Odoo 20 implementation or upgrade, Octivex Tech can review your current users, employee structure, custom applications and integration architecture to identify the technical and licensing questions that should be resolved before migration.