Once a single Odoo database serves several legal entities, the native multi-company model shows its limits. Odoo lets a user belong to multiple companies and switch between them, but a user's security groups (groups_id) are global — a person who is Accounting Manager in the parent company carries that same manager profile into every subsidiary the moment they toggle the company selector. Record rules (ir.rule) filter which records are visible, but they do not cleanly grant a user Sales-Manager rights in Company A while pinning them to a read-only role in Company B. Finance and compliance leads discover this during audits: a shared controller can post journal entries in an entity they were only meant to review, and there is no per-company access boundary to show an auditor.

Multi-Company Access Rights closes that gap. We build a custom module that introduces a per-company access mapping — a model (models.Model) linking a user, a company, and a chosen security profile — and enforces it so that a user's effective permissions change with the active company context. Technically this is delivered through purpose-built security groups, ir.model.access.csv entries for model-level CRUD, and company-aware ir.rule record rules whose domains reference the active company and the user-company profile mapping. Where menus and actions must differ per entity, we drive visibility with group-conditional <menuitem groups="..."> and action bindings, so a user simply does not see the models, buttons, or reports they are not entitled to in the company they are currently in.

Under the hood we lean on Odoo's own primitives rather than fighting them. Compute fields with @api.depends derive the user's effective profile for the active company; overrides on the relevant models respect self.env.company and self.env.companies so that reads, writes, and create() all honor the per-company rule set. We add automated actions or server actions where a change of company must trigger a reassignment, and every enforcement path is covered by Python unit tests so the boundary holds after future upgrades. The same rules are honored by the XML-RPC/JSON-RPC API, because record rules apply at the ORM layer — an integration or a portal request cannot slip past the per-company profile the way a bolt-on UI check could. The design accounts for Community vs Enterprise differences (Enterprise-only apps such as full Accounting or Studio-generated models are wired in only when your edition includes them) and is delivered for Odoo 17.0, 18.0, or 19.0.

Because this is build-to-order, nothing ships until we have mapped your actual company tree and role matrix. Delivery starts with a short scoping call, followed by a written scope and fixed quote, development on a branch, UAT on a staging database with your real company structure, and a supervised go-live with a rollback plan. Typical delivery is one working week from confirmed scope, depending on the number of companies and the depth of role differences. Pricing starts from $999 (indicative, single-company base scope); the number of companies, the number of distinct per-company role profiles, cross-company sharing exceptions, and any Enterprise-app coverage increase the quoted scope. You receive the installable source, the git repository, and a documented rule map so your team — or ours — can maintain it.