Overview
Global pharmaceutical groups often add legal entities faster than governance. A new company may start with copied product data, local spreadsheets and its own approval habits. Over time it creates duplicate products, inconsistent stock status, delayed reconciliation and unreliable group reports.
Odoo can support multi-company operations but configuration alone does not produce control. Leaders must decide which data and processes are shared, which are company-specific and who has authority to approve a variation. The result should be a governed operating model that supports local execution without creating separate ERP worlds.
This guide provides an Odoo pharmaceutical multi-company operations governance checklist. It uses a realistic global pharma scenario then maps required data, controls, exceptions, KPIs and implementation choices. It does not claim client results. For a long-term transformation perspective, visit the Sasmar pharma case study.
The Before Scenario: Growth Without a Shared Operating Model
Imagine a pharmaceutical group with manufacturing in one country, distribution entities in several regions and direct digital sales in selected markets. Each company has been added as growth demanded. Finance maintains separate charts and local reports. Commercial teams create similar products under different codes. Inventory transfers between companies are coordinated through emails and spreadsheets. Customer credit decisions vary by region.
Month-end exposes the problem. Intercompany balances do not match. Supply teams cannot tell which entity owns stock in transit. Product reports need manual consolidation. A pricing change becomes several local changes. When a user moves between companies, access rights and approvals become uncertain.
The objective is not to remove every local variation. Tax, statutory reporting, banking, language, product labels and market-specific commercial rules may need to differ. The objective is to make every variation visible, justified and governable.
What Multi-Company Governance Means in Odoo
Multi-company governance is the discipline of deciding how companies share data, transactions, access and change decisions. It defines which rules are group standards and which are local responsibilities.
In an Odoo pharma ERP environment, a product may be recognized globally but be available only to certain companies or markets. A user may need access to two companies but should only approve transactions in one. An intercompany sale may create a corresponding purchase relationship while finance must still reconcile the accounting outcome.
The system needs configuration that reflects these rules. More importantly, the business needs owners who can explain the purpose of each rule and approve future changes.
| Governance area | Group decision required | Local decision allowed only when justified |
|---|---|---|
| Product data | Identity, units, specifications and ownership | Labels, language or permitted-market details |
| Finance | Accounting principles, intercompany policy and close controls | Tax, statutory reports and banking formats |
| Inventory | Traceability principles, stock-status rules and movement controls | Warehouse layout and local logistics process |
| Commercial rules | Customer hierarchy, pricing governance and credit policy | Market price lists and legally required documents |
| Security | Role model, access-review process and segregation rules | Local constraints required by law or operations |
| Reporting | Group KPI definitions and data-quality thresholds | Local views using governed definitions |
Map the End-to-End Intercompany Flow
The most useful test of multi-company governance is a real transaction. Consider a manufacturing company that supplies a distribution company. A customer order creates demand in the distributor. The distribution company needs product from the manufacturing entity. Supply, delivery, invoicing and finance must move through defined company contexts.
Example transaction flow
The distribution company receives a customer order under its own customer terms, pricing and credit rules.
The order creates demand for product in the distributor’s warehouse.
If stock is unavailable, the approved intercompany supply process identifies the manufacturing entity or another group company.
The supplying company creates its linked commercial and fulfilment transactions according to group policy.
Inventory is received or transferred with the required product, batch, quantity, status and ownership information.
The distribution company delivers to the customer then issues the appropriate commercial and financial documents.
Both entities record their financial effects using approved intercompany accounts, price rules and currencies.
Finance reviews matching documents and unresolved differences before close.
The exact documents and movements vary by company structure, tax rules and operating policy. The governance requirement is stable: each step needs a clear owner, correct company context, traceable link and reconciliation method.
Shared Data Must Have Clear Owners
Shared data does not mean every user can edit it. It means the group has one agreed definition and a controlled way to use it. Product master data is the clearest example. If each entity creates its own product identity, group stock, sales and purchasing analysis becomes unreliable.
Assign global owners for product identity, units of measure, core classifications, approved suppliers, company structures and group reporting definitions. Assign local owners for data that changes by entity such as tax positions, bank accounts, local customers and local warehouse locations.
Define how requests move. A new product may be proposed by a local commercial team, validated by a global product owner then made available to selected companies. The process should retain the requester, approver, effective date and relevant status. It should not rely on email history as the only evidence.
| Data set | Global owner | Company owner | Quality rule |
|---|---|---|---|
| Product identity and unit | Product master-data lead | Local product requester | One approved code and valid unit conversion |
| Product company availability | Product or commercial governance | Company commercial lead | Availability approved by market and company |
| Customer hierarchy | Commercial data lead | Local sales operations | No duplicate legal entity without review |
| Chart and intercompany mapping | Group finance | Local finance | Approved mapping and effective date |
| Warehouse locations | Supply governance | Local warehouse lead | Unique location and defined company context |
| Users and roles | Security owner | Local manager | Role assigned by approved business need |
Control Access by Company, Role and Action
Access rights should reflect both company context and job responsibility. A user who can see two companies may not need to create, approve or modify the same records in both. Do not use broad access simply because teams collaborate across borders.
Define role matrices for sales, supply, warehouse, finance, management and system administration. Identify the records each role may read, create, modify, approve and cancel. Add threshold rules for high-risk decisions such as credit releases, price overrides, stock adjustments and intercompany changes.
Segregation of duties matters. The person who creates a vendor or changes payment details should not necessarily approve payment. The user who creates a customer credit limit should not release a related blocked order without additional authority. Review access at a planned frequency and after role or company changes.
Treat Exceptions as a Designed Process
Normal intercompany flows are often straightforward. Exceptions create operational and financial risk when they are handled in email or by unauthorized changes.
Examples include a supplier company missing the delivery date, a partial transfer, a product status restriction, an incorrect intercompany price, a currency difference or a return. Each exception needs a defined status, owner, approval route and financial treatment.
Avoid making every exception fully automatic. A governed workflow should identify the issue, protect the control then give the correct owner enough information to decide. The system must retain evidence of the decision and show the item in an exception report until resolution.
| Exception | Governance response | Required evidence |
|---|---|---|
| Supplying company cannot meet demand | Re-plan, escalate or approve an alternate source | Owner, revised date and demand impact |
| Partial intercompany delivery | Confirm remaining commitment and financial effect | Linked documents and open quantity |
| Product status blocks movement | Hold transaction for authorized review | Status source, reviewer and decision |
| Intercompany price dispute | Prevent close until policy owner resolves difference | Price basis, approver and adjustment |
| Currency or tax difference | Reconcile under group finance policy | Calculation, accounts and resolution |
| Unauthorized company access request | Review business need and approve or reject | Requester, approver and access duration |
Reconcile Intercompany Activity Before It Becomes a Close Problem
Intercompany differences are easier to resolve close to the event. Establish reconciliation rules for linked sales and purchases, inventory transfers, receivables and payables, freight, price changes and foreign-currency effects.
Use stable document references across companies where possible. Finance should see the matching counterpart, amount, currency, status and age. A difference may be valid but it must be explained. Do not allow unresolved differences to disappear into a consolidated report.
Set escalation thresholds. For example, an item beyond a specified age or value should notify group finance and the operational owner. The values should be approved by policy, not invented in the system during implementation.
Build a Repeatable New-Company Onboarding Process
Adding a legal entity should be a governed rollout, not a copy of the existing database with names changed. Use a new-company checklist that starts with legal, finance and operational requirements.
Confirm the company profile, currencies, fiscal settings, tax and document rules, banks, journals, warehouses, product availability, customer and supplier data, access roles, intercompany mappings, integrations, reports and training. Test a representative transaction end to end before the company begins live processing.
The global template should shorten onboarding while still requiring sign-off. Reusing a setup without reviewing local conditions creates later remediation and weakens confidence in group reports.
KPIs That Show Whether Governance Is Working
Governance should be measured through operational and control outcomes, not merely the number of policies written. Start with a limited scorecard that has clear owners and definitions.
| KPI | Example definition | Governance signal |
|---|---|---|
| Intercompany reconciliation age | Days unresolved items remain open | Close discipline and ownership |
| Master-data completeness | Share of active records meeting required rules | Data readiness for execution |
| Unauthorized-access exceptions | Requests or violations by company and role | Strength of role governance |
| Intercompany fulfilment reliability | Transfers completed by committed date | Supply coordination across entities |
| Manual adjustment rate | Adjustments to stock or finance after posting | Process or data-control weakness |
| Local variation register | Approved versus unapproved process variations | Template discipline |
Measure the baseline before rollout. A lower exception count may mean better control or simply weaker detection. Pair counts with age, materiality, review completion and sampled evidence.
Implementation Choices: Standardize the Rules Before the Screens
Start with group decisions, not module installation. Identify which processes must be common, which data is shared, which localizations are needed and what specialist systems remain authoritative. Then configure Odoo company structures, master data, roles, intercompany rules and reporting to reflect that model.
Use phased rollout. A first phase may cover two companies and one intercompany flow. Include production-grade access, data, reconciliation and reporting rather than treating these as future enhancements. Expand only after the initial companies meet agreed exit criteria.
Customization should be exceptional. Where a local need is real, test standard Odoo, configuration, process adaptation and integration first. If custom work is approved, record the business owner, company impact, upgrade responsibility and retirement review.
Pharmaceutical Multi-Company Governance Checklist
Operating model
Group process owners define global rules.
Each local variation has a legal, operational or risk reason.
Intercompany policies define document, pricing and reconciliation requirements.
New-company rollout uses signed readiness and exit criteria.
Data and architecture
Shared and company-specific data are documented.
Global and local data owners are assigned.
Product availability by company and market is governed.
Integrations define source authority, identifiers and failure handling.
Group reporting definitions are controlled.
Controls and adoption
Role matrices separate access by company and action.
Credit, price, stock and intercompany overrides have authority limits.
Exception queues have owners, due dates and escalation rules.
Intercompany items are reconciled by documented policy.
Customizations have business cases and upgrade owners.
Users are trained with real multi-company scenarios.
Frequently Asked Questions
1. Can Odoo manage several pharmaceutical companies in one environment?
Odoo can support multi-company structures. Success depends on clear definitions for company context, shared data, access rights, transactions, reporting and local variations.
2. Should every company use the same chart of accounts?
Use shared accounting principles and controlled mapping for group reporting. Local statutory or tax requirements may require differences that should be documented and governed.
3. What data should be shared across companies?
Product identity, units, core classifications, reporting definitions and group policies are often shared. Stock, journals, taxes, credit exposure and local contracts usually require company context.
4. How should intercompany transactions be tested?
Test the full path: demand, linked supply, inventory movement, documents, invoicing, payment or settlement and reconciliation. Include partial delivery, returns, price changes and currency differences.
5. What is the main access-control risk in multi-company ERP?
Overly broad access. Users may need visibility across entities but should receive only the actions and records required by their approved role and company responsibility.
6. How can a group prevent local customizations from growing uncontrollably?
Use a change council, standard-first assessment and a variation register. Every extension needs an owner, reason, impact assessment, test plan and upgrade responsibility.
7. When is a new company ready to go live?
It is ready after company configuration, data, access, intercompany mapping, integrations, reports, training and end-to-end scenarios meet agreed acceptance criteria.
Conclusion
Odoo pharmaceutical multi-company operations become scalable when governance is designed before local configurations multiply. Define what must be shared, what may vary and who can approve change. Then test those decisions through end-to-end intercompany flows rather than isolated company setups.
The most important controls are clear data ownership, role-based company access, governed exceptions and timely reconciliation. A repeatable onboarding model and a small KPI scorecard help the group grow without turning each new entity into a separate ERP project.
Use this checklist to turn multi-company expansion into a controlled operating model. The goal is not identical processes everywhere. It is consistent decisions, trustworthy group data and visible accountability across every company.
