Introduction
One of the less talked-about features in the Odoo data model is the company dependent field. It is a small attribute that makes a big difference once you start working with multi-company configurations.
In most Odoo setups, a field on a record holds a single value that every user across the database can see. But what happens when two companies share the same product catalog, and each company needs its own internal reference code? Or when different companies need different default accounts on the same product?
That is exactly the problem the company_dependent attribute solves. Whether you are doing odoo development, odoo customization, or just exploring the odoo framework, understanding this field type will give you a real edge in multi-company projects.
What Is a Company Dependent Field in Odoo
A company dependent field is a field that stores a separate value per company, on the same record. When a user belonging to Company A reads the field, they see their company's value. When a user from Company B reads the same record, they see a different value.
From the outside, it looks and behaves like a normal field. Users interact with it the same way in the Odoo interface. The magic happens behind the scenes in the Odoo ORM.
How It Appears in the Interface
In the Odoo UI, a company dependent field looks identical to a regular field. There is no visible indicator telling a user the value they see is company-specific. This is intentional: the behavior is transparent to end users.
From a developer perspective, this is one of the odoo field types that can be applied to many base types: Char, Boolean, Integer, Float, Many2one, and others. The company_dependent=True attribute is what activates this behavior in the Odoo ORM.
In Odoo Studio, some company dependent fields are already exposed on standard models (like product-related fields for accounts). Custom company dependent fields can also be created, though Studio support for this specific attribute is limited in some Odoo versions.
How the Field Works
Under the hood, company dependent fields work very differently from regular fields. Understanding the mechanism helps avoid surprises when building or debugging Odoo customizations.
Storage in ir.property
In Odoo 16 and earlier, company dependent field values are not stored in the model's own database table. Instead, they are stored in a separate system table called ir.property.
Each entry in ir.property links:
- A specific record (e.g., product with ID 42)
- A specific field (e.g.,
property_account_income_id) - A specific company
- The actual value for that combination
This is why the values look transparent to users: the ORM retrieves and writes to ir.property automatically based on the current company context.
Changes in Odoo 17+
Starting with Odoo 17, the storage mechanism was refactored. Company dependent fields are now stored directly in the model's table using a jsonb column, with company values stored as a JSON dictionary. This significantly improves performance and simplifies queries.
The interface and developer-facing API remain the same, but queries on company dependent fields are now much faster at scale.
Default Values
Company dependent fields support company-specific default values. When no value has been explicitly set for a given company, the field falls back to the default defined on the field itself. This default can also be set per company through the ir.property model (Odoo 16 and earlier) or directly on the model (Odoo 17+).
Interaction with the ORM
In the odoo orm context, accessing a company dependent field always respects the current company in the environment (self.env.company). This means:
- Reading the field returns the value for the active company
- Writing to the field only updates the value for the active company
- Switching company context (
record.with_company(company)) lets you read or write values for a specific company
Business Use Cases
The company dependent field is not just a technical curiosity. It solves real, everyday problems in multi-company Odoo setups. Here are five common scenarios where it genuinely earns its place.
1. Accounting: Per-Company Income and Expense Accounts
This is the most common example in Odoo out of the box. The property_account_income_id and property_account_expense_id fields on products are company dependent.
In practice: Company A sells the same product as Company B, but each company has a different chart of accounts. Instead of duplicating the product record, each company just configures its own accounting lines. The product is shared; the accounting logic is not.
2. Sales and CRM: Per-Company Pricelists
In a group that runs multiple sales entities, each company may use different pricing strategies. With a company dependent pricelist field, a shared customer record can carry different default pricelists depending on which company is processing the sale.
This keeps the CRM data centralized while allowing each company to apply its own commercial rules.
3. Inventory: Per-Company Stock Valuation Method
Some groups operate warehouses across multiple legal entities with different local regulations. A product may require FIFO costing in one country and average cost in another. Using company dependent fields on the product or category avoids duplicating the entire product catalog.
4. Manufacturing: Per-Company Default Supplier
When a shared product is purchased from different suppliers depending on the company, a company dependent many2one field pointing to res.partner can hold the preferred supplier per entity. Each company sees its own preferred supplier without any conflict.
5. Custom Fields for Regulatory Data
Groups operating across multiple countries often need to store country-specific compliance references on shared records. For example, a product might need a different HS code or tax classification per jurisdiction. A company dependent Char field is a clean, low-overhead way to handle this without creating model variants.
Creating or Customizing the Field
There are two main ways to create company dependent fields in Odoo: using Odoo Studio or writing Python code directly.
Using Odoo Studio
Odoo Studio lets you create fields without any code. However, Studio does not expose a dedicated toggle for company_dependent in all versions. In Odoo 16 and 17, the option is available on some field types when creating new fields on standard models.
If you need full control over this attribute, technical development is the more reliable approach. Studio is a good starting point for simpler cases, but it has limits when it comes to advanced odoo customization scenarios.
Technical Approach: Python Fields
In a custom Odoo module, declaring a company dependent field is straightforward. This is the standard pattern used in odoo python fields development:
from odoo import fields, models
class ProductTemplate(models.Model):
_inherit = 'product.template'
x_internal_ref = fields.Char(
string='Internal Reference (per company)',
company_dependent=True,
)
x_preferred_carrier_id = fields.Many2one(
comodel_name='res.partner',
string='Preferred Carrier',
company_dependent=True,
)Adding company_dependent=True to any field declaration is all it takes. The ORM handles the rest automatically.
Setting Default Values Per Company
In Odoo 16 and earlier, you can set a company-level default via the ir.property model. This is useful when you want a sensible default for all records in a company, without setting it record by record:
self.env['ir.property']._set_default(
'x_internal_ref',
'product.template',
'DEFAULT-VALUE',
company_id=self.env.company.id,
)In Odoo 17+, the default value is stored directly on the model record and is also accessible via the field definition.
Odoo Studio Fields and Limitations
When working with odoo studio fields, keep in mind that the x_ prefix is required for custom fields. The company dependent behavior may not be visible in the Studio UI, but it can still be configured from the technical menu under Settings if developer mode is active.
Best Practices
Working with company dependent fields is straightforward once you know the patterns. Here are the practices that will save you time and prevent headaches.
1. Only Use It When Values Genuinely Differ Per Company
Company dependent fields add complexity. If the value is the same across all companies, use a regular field. Reserve company_dependent=True for fields where different companies genuinely need different values on shared records.
2. Always Test in Multi-Company Context
When building or testing features that involve company dependent fields, always test with at least two companies active. It is easy to miss issues in a single-company setup that will surface immediately in production.
3. Use with_company() for Cross-Company Operations
If your code needs to read or write company dependent field values for a company other than the current one, use record.with_company(target_company). Avoid manually switching the environment company without restoring it.
4. Be Careful with Exports and Imports
When exporting records that contain company dependent fields, the exported values reflect the company of the user doing the export. Importing the same file under a different company context will set the values for that company. This is often the correct behavior, but be explicit about it in migration and data import workflows.
5. Document Which Fields Are Company Dependent
End users rarely know which fields are company dependent. A short note in your internal Odoo documentation or onboarding materials goes a long way. It prevents confusion when a user switches companies and sees different values on the same record.
6. Prefer Many2one Over Char for Structured Data
When the per-company value is a reference to another record (account, pricelist, partner), use a Many2one company dependent field rather than storing a name as text. This keeps the data model clean and makes reporting more reliable.
Common Pitfalls
Even experienced Odoo developers run into issues with company dependent fields. Knowing what to watch for will prevent wasted debugging time.
Pitfall 1: Forgetting the Company Context in Automated Actions
Scheduled actions and server actions often run in a context where the company is the first company in the database, not necessarily the one you expect. If your automated action reads or writes a company dependent field, verify the company context explicitly. Use with_company() to be safe.
Pitfall 2: Assuming the Field Behaves Like a Computed Field
Company dependent fields are not computed fields. They do not have a compute method. The per-company variation comes from storage, not calculation. Trying to add compute= alongside company_dependent=True will not work as expected and may cause errors in the Odoo framework.
Pitfall 3: Searching Across Companies
Standard ORM searches on company dependent fields only return results matching the current company context. If you need to search across all companies, you need to query ir.property directly (Odoo 16 and earlier) or handle the jsonb column carefully (Odoo 17+). This is a common source of confusion in reporting and data extraction work.
Pitfall 4: Not Setting Defaults for All Companies
When you introduce a company dependent field in a live system, existing records will return False or None for any company that has not explicitly set a value. If your business logic expects a default, set it proactively for all relevant companies using a data migration script.
Pitfall 5: Confusing It with Access Rights
Company dependent fields control what value is shown, not whether the user can see the field at all. If you need to hide a field entirely from certain companies or users, that is a job for record rules or field-level access rights, not company_dependent.
Conclusion
The company dependent field is one of those features in Odoo that feels invisible until you need it, and then becomes indispensable. It is the right tool for any situation where the same record needs to carry different values across companies: accounting configurations, pricing rules, regulatory references, or any business-specific attribute that varies by legal entity.
Understanding how it works at the ORM level, which version of Odoo changed the storage model, and what pitfalls to avoid will save you significant time on multi-company projects. Whether you encounter it in a standard Odoo odoo developer guide or discover it while debugging a live system, knowing this field type is a mark of real Odoo expertise.
If you are building on the odoo framework and need to handle per-company data cleanly, company_dependent=True is the answer you were looking for.
Need Help with Your Odoo Implementation?
At Dasolo, we help companies implement, customize, and optimize Odoo across all scales and configurations, including complex multi-company setups. Whether you need a tailored data model, a custom field strategy, or a full Odoo rollout, our team has the technical and functional depth to get it right.
If you have questions about company dependent fields or any other aspect of your Odoo implementation, we are happy to help. Reach out to us and let's talk about what you are building.