Scaling Odoo from 6 to 22 Companies: Architecture Lessons from Sasmar

Overview

Multi-company ERP complexity does not grow in a straight line. Adding a seventh company to a six-company environment affects more than the company list. It introduces another legal boundary, accounting structure, currency context, warehouse network, user group, reporting requirement and set of intercompany relationships. By the time an organization reaches 22 companies across several global regions, every early architecture decision has been tested repeatedly.

Sasmar Pharmaceuticals offers a practical example of this growth. According to the official Odoo Experience session, Choosing Odoo Over SAP: The 10-Year Transformation Journey of a Global Pharmaceutical Group, its Odoo journey began with Odoo 7 and six companies. Over the following decade, the group expanded to 22 companies across Europe, Asia-Pacific, North America and Latin America while moving toward Odoo 19 Enterprise. Its operating environment grew to connect manufacturing, distribution, finance and a digital commerce network that includes more than 25 Shopify stores, Amazon and other channels.

This article does not repeat general advice about enabling multiple companies in Odoo. It examines the architecture questions created by Sasmar’s expansion from 6 to 22 companies and explains how an Odoo multi-company architecture must support the next entity before that entity is created.

The broader strategic story is covered in Sasmar’s 10-year transformation. Here, the focus is the structure beneath that transformation: company boundaries, shared data, access rules, accounting, warehouses, intercompany flows, localization, reporting and the repeatable onboarding of new entities.

Why Multi-Company Growth Creates ERP Complexity

A single-company ERP has one primary legal and accounting context. Users usually work with the same base currency, chart of accounts, tax structure and company-owned transactions. Warehouses may be numerous but they still belong to one legal entity. Internal stock movements do not automatically create commercial transactions between separate companies.

In a multi-company environment, each legal entity must preserve its own books and operational responsibility. A customer invoice belongs to one company. A vendor bill belongs to one company. A sales order cannot be allowed to draw stock from another legal entity without a defined transaction. Taxes, journals, bank accounts and fiscal positions must follow the active company. Users who can switch companies must understand which company owns the document they are creating.

Complexity increases further when entities trade with one another. A manufacturing company may supply a regional distributor. A central procurement entity may purchase for several subsidiaries. One company may provide shared services to others. A regional warehouse may hold stock that another entity sells. These arrangements affect sales, purchasing, inventory, tax and accounting at the same time.

The core architecture challenge is therefore balancing two needs:

• Centralize the data and processes that should be common across the group

• Preserve legal, financial and operational separation where company ownership matters

If everything is separated, the organization recreates data silos inside one database. If everything is shared, users may expose confidential information or create transactions in the wrong company. A scalable implementation needs explicit rules between these two extremes.

Sasmar’s Expansion from 6 to 22 Companies

Sasmar’s journey is important because the company count did not increase in isolation. New entities were added while the group expanded across four regions and connected more operational functions and sales channels. The system therefore had to scale along several dimensions at once.

Six companies already require controlled multi-company configuration. Twenty-two companies require a repeatable operating model. At that scale, setting up each entity as a unique project creates inconsistency and makes group reporting difficult. The architecture needs reusable company templates, defined master-data ownership, standard security roles, mapped accounting structures and documented intercompany processes.

Sasmar’s pharmaceutical context also adds manufacturing and traceability requirements. External vendors may process semi-finished or finished goods. Products can move through production, inventory and distribution across different companies and countries. Commercial transactions may originate through distributors, Shopify stores, Amazon or other channels before entering Odoo.

A simplified group transaction can move through the following path:

Digital channel or customer demand → selling company → intercompany demand → supplying or manufacturing company → warehouse fulfilment → customer delivery → company-level accounting → group reporting

Each stage needs a clear company owner. If ownership is ambiguous, the group can face incorrect stock, duplicate documents, inconsistent taxes and unreconciled intercompany balances.

Design for Future Entities Instead of Current Requirements

An Odoo multi-company implementation should not be designed only around the companies that exist on the go-live date. The architecture should define how a future company will be added without requiring a redesign of shared products, user groups, integrations or reports.

This begins with a global template. The template should describe the standard sales flow, purchasing flow, warehouse structure, approval levels, account mapping, product model, partner model, access roles and reporting dimensions. It should also identify which settings must be localized for each company.

The template does not mean copying every configuration blindly. A company in Europe may need different tax rules and financial reports from an entity in North America or Asia-Pacific. The purpose of the template is to separate the global operating model from legal and commercial variation.

A useful classification is:

When these decisions are made early, adding a company becomes a controlled deployment exercise rather than a new architecture project.

Shared Versus Company-Specific Master Data

Master-data design is one of the most consequential parts of global Odoo ERP architecture. Products, contacts, units of measure and some categories may benefit from group-wide consistency. Taxes, journals, bank accounts, warehouses and accounting properties normally belong to a specific company context.

A shared product catalogue can prevent different entities from creating separate codes for the same item. This helps eCommerce integration, purchasing, manufacturing, inventory analysis and consolidated reporting. However, not every product should automatically be visible or usable in every company. The group needs rules for product ownership, activation, pricing, taxes and routes.

Customer and vendor records require similar governance. A global partner identity can reduce duplication and give the group a consistent view of a distributor or supplier. Company-dependent properties must still point to the correct receivable account, payable account, payment terms and fiscal treatment.

The safest approach is to define a master-data ownership model:

• A central team controls global product codes and shared attributes

• Local teams maintain approved company-specific commercial and fiscal values

• Duplicate detection prevents multiple records for the same business partner

• Integration identifiers connect Shopify, Amazon and other channels to the correct Odoo record

• Changes to critical fields follow approval and audit rules

Without this ownership model, the eighteenth or twenty-second company can expose inconsistencies created when the first six companies were configured.

Multi-Company Access and Security

Odoo allows authorized users to work in one or several companies. This capability is useful for group finance, shared services, central purchasing and regional management but it also creates risk. A user may see data that should remain confidential or create a document under the wrong active company.

Security design should begin with business roles rather than individual users. A global CFO may need access to all entities. A regional finance manager may need several companies within one region. A local accountant should normally access only the assigned company. A warehouse user should operate within approved warehouses and companies. An auditor may need read-only visibility without transaction rights.

The design should combine:

1. Allowed-company assignments

2. Role-based access groups

3. Record rules that respect company ownership

4. Approval limits and separation of duties

5. Company-specific journals, warehouses and operational permissions

6. Tests using realistic multi-company user profiles

Custom modules need particular attention. Every custom model that stores company-owned information should have a clear company relationship and appropriate record rules. Searches, automated actions and scheduled jobs must run in the intended company context. A customization that behaves correctly in one company may expose or alter records incorrectly when several companies are active.

Security testing should include cross-company negative tests. The team should verify not only what a user can do but also what the user must be unable to view, create, change, approve or post.

Multi-Currency Accounting Across Global Companies

Sasmar’s presence across four regions requires an architecture that distinguishes company currency, transaction currency and group reporting currency. Each legal entity may maintain its books in a local base currency while selling, purchasing or banking in other currencies.

The transaction flow should preserve the exchange-rate context from the original document through settlement. A foreign-currency sales order can lead to a customer invoice, payment and exchange difference. A purchase in another currency follows a similar path through the vendor bill and payment. Intercompany trading can create currency exposure in both participating entities.

Key configuration decisions include:

• Base currency for each company

• Approved exchange-rate source and update frequency

• Foreign-currency bank and cash journals

• Realized and unrealized gain or loss accounts

• Intercompany pricing currency

• Consolidation currency and translation method

• Period-end rate controls and review responsibility

Multi-currency reporting is not solved merely by enabling currencies. Finance teams need documented rate policies and reconciliation controls. The same group transaction should not use inconsistent rates across entities without a defined reason.

Multiple Warehouses and International Supply Chains

At 22 companies, warehouse architecture must show both physical location and legal ownership. A warehouse belongs to a company but the group may operate regional distribution, central manufacturing, outsourced production or shared logistics arrangements.

The system should answer four questions for every stock movement:

1. Which company owns the goods before the movement?

2. Which physical location holds the goods?

3. Does ownership change during the movement?

4. Which commercial and accounting documents must be created?

An internal transfer between two warehouses owned by the same company is different from a transfer between separate legal entities. The second scenario may require an intercompany sale and purchase, delivery, receipt, invoice, vendor bill and applicable tax treatment.

For pharmaceutical operations, lot and batch continuity may also need to remain visible across manufacturing, external job work and distribution. Routes, locations and document relationships should preserve traceability as materials become semi-finished goods and then finished products.

Replenishment rules must also respect company ownership. Demand from a selling company may need to create a purchase from another group company rather than a stock move from a warehouse it does not own. This is where inventory design and intercompany automation meet.

Intercompany Sales and Purchasing

Intercompany automation reduces duplicate entry but only when the commercial relationship is clearly defined. Assume Company B distributes a product manufactured by Company A. When Company B needs stock, it raises a purchase order to Company A. Odoo can create the corresponding sales order for Company A based on the configured intercompany rules.

The complete flow may be:

Company B purchase order → Company A sales order → Company A delivery → Company B receipt → Company A customer invoice → Company B vendor bill → payment and reconciliation → consolidation elimination

Each document remains in its legal company while the linked flow reduces manual duplication. Pricing, taxes, incoterms, currency and payment terms must be defined between the companies. Product mapping and units of measure must be consistent. Returns, cancellations and partial deliveries need tested reverse flows.

Intercompany automation should not create documents that users cannot explain or reconcile. Every generated record needs a visible link to its source. Errors should enter a monitored exception process rather than disappearing inside a scheduled action.

Local Tax and Regulatory Requirements

A global template cannot override local law. Each company may require country-specific tax configuration, fiscal positions, invoice layouts, sequences, electronic invoicing, statutory reports and retention rules.

Localization should be designed as a controlled layer over the common operating model. The sales approval process may be standardized while the tax calculation and invoice format vary. The purchasing stages may remain common while withholding tax or vendor-document requirements differ. The global reporting model may use common account groups even when local statutory accounts are not identical.

Before adding a new country, the team should complete a localization assessment covering:

• Available Odoo localization and its version compatibility

• Tax codes, rates and fiscal positions

• Statutory chart-of-account requirements

• Invoice numbering and document rules

• Electronic invoicing or government integration

• Bank formats and payment methods

• Payroll and employee compliance where included

• Data retention, privacy and audit requirements

Any gap should be classified as configuration, supported localization, integration or justified customization. This prevents regulatory requirements from being mixed with local user preferences.

Standardized Chart of Accounts Versus Local Variations

Financial consolidation becomes easier when companies use a consistent chart of accounts but full standardization is not always legally or operationally possible. Some jurisdictions require local account structures while different business models may need additional detail.

The scalable solution is a group reporting map. Each local account should map to an approved group account or reporting category. Common naming, coding and account-type conventions should be used wherever local rules allow. New local accounts should not be created without considering their group reporting treatment.

This creates two connected layers:

• The statutory layer supports each company’s local books and compliance

• The group layer supports comparable reporting and consolidation

If mapping is postponed until month-end, finance teams will rely on spreadsheets and manual adjustments. If mapping is part of the account-creation process, consolidation remains maintainable as entities are added.

Consolidated Reporting Requirements

Company-level reports answer whether an entity is financially correct. Group-level reports answer how the enterprise is performing as a whole. Both views are required.

Consolidation must account for reporting currency, account mapping, ownership structure, period alignment and intercompany elimination. It also needs consistent analytic dimensions so leadership can compare regions, channels, product groups and functions across companies.

A reliable reporting flow is:

Company transactions → validated company ledgers → account mapping → currency translation → intercompany matching → eliminations → consolidated statements and management dashboards

Reporting architecture should be designed before transactions accumulate. Finance leaders need to define the consolidated balance sheet, profit and loss statement, cash-flow view and management KPIs during implementation. Each source field and mapping rule should have an owner.

Browseinfo’s article on multi-entity financial consolidation explains the reporting principles in more detail.

Adding a New Company Without Redesigning the System

The strongest test of Odoo multi-company architecture is how the twenty-third company would be added. A scalable design should follow a controlled onboarding process.

Stage 1: Entity discovery

Document the legal structure, country, currency, business model, warehouses, users, accounting requirements, taxes, bank processes, products, partners, integrations and reporting needs.

Stage 2: Fit to the global template

Map each requirement to the existing group process. Identify which items use the standard model and which require localization or an approved exception.

Stage 3: Company configuration

Create the company and configure currency, localization, chart of accounts, journals, taxes, fiscal positions, warehouses, routes, sequences and company-specific properties.

Stage 4: Master data and integrations

Activate shared products and partners where appropriate. Load approved local data. Create integration mappings for eCommerce, banking, logistics or other external platforms.

Stage 5: Users and security

Assign users through standard role profiles. Validate company visibility, approval authority and separation of duties.

Stage 6: End-to-end testing

Test sale-to-cash, procure-to-pay, inventory, manufacturing where applicable, intercompany flows, taxation, payments, period close and reporting. Include returns, cancellations and integration failures.

Stage 7: Migration and cutover

Load opening balances, open transactions and required master data through reconciled migration steps. Confirm ownership and financial totals before production launch.

Stage 8: Stabilization

Monitor transaction exceptions, integrations, access issues, accounting reconciliation and user adoption. Feed approved improvements back into the global template for the next rollout.

This repeatable process turns international expansion into a managed rollout instead of a series of independent implementations. Organizations planning a similar structure can explore Browseinfo’s multi-company ERP setup services.

Performance and Database Considerations

A move from six to 22 companies increases transaction volume, record counts, scheduled operations and reporting demand. The number of companies alone does not determine performance but it multiplies the activities running inside the shared environment.

Performance planning should consider sales orders from all channels, stock moves, manufacturing transactions, accounting entries, integration queues, email jobs, automated actions and consolidated reporting. More than 25 Shopify stores and additional channels can create traffic peaks that differ from normal back-office usage.

Architecture reviews should cover:

• Database size and record growth

• Query performance in standard and custom modules

• Indexing for high-volume searches

• Scheduled job timing and concurrency

• Integration queues, retries and idempotency

• Worker, memory and storage requirements

• Report generation and consolidation load

• Attachment and document storage

• Backup, restore and disaster-recovery testing

• Archiving or retention strategies where appropriate

Custom code should be tested with realistic group data. A report that performs well with one company and one year of transactions may become unusable when run across 22 companies. Record rules also affect query performance and should be included in testing with real user permissions.

Multi-Company Rollout Checklist

For broader configuration guidance, review these multi-company Odoo best practices. The value of the Sasmar case is seeing why those principles become essential when a group expands from six to 22 companies.

Architecture Lessons from the Sasmar Implementation

The first lesson is to build a global operating model before growth forces one. Shared processes, data ownership, security roles and reporting definitions become harder to standardize after each company develops its own methods.

The second lesson is that company boundaries must remain visible through the complete transaction flow. Sales, purchasing, inventory, manufacturing and accounting cannot be designed separately when goods or services move between entities.

The third lesson is to standardize what creates comparability while localizing what law and the business genuinely require. A global template should control core process stages and data definitions without pretending that all countries have identical tax and reporting rules.

The fourth lesson is that eCommerce and other integrations are part of the enterprise architecture. With more than 25 Shopify stores, Amazon and other channels, identifiers, order ownership, inventory availability and error recovery need group-wide standards.

The fifth lesson is that every customization must be assessed across all companies. A change developed for one local team can affect shared models, security, reporting and future upgrades throughout the database.

The sixth lesson is that onboarding must be repeatable. A new company should follow a documented path from discovery and localization through testing, migration and stabilization.

The final lesson is that governance continues after go-live. The global ERP governance framework in this cluster will explain how architecture decisions, change requests, custom development, integrations and upgrades can be controlled across a growing Odoo environment.

From Six Companies to a Repeatable Global Platform

Sasmar’s growth from 6 to 22 companies shows that Odoo multi-company architecture is not mainly about creating company records. It is about creating a repeatable operating structure that preserves legal separation while connecting global operations.

The architecture must define what is shared, what belongs to each company and how transactions move between entities. It must support local currency, tax and reporting requirements while producing group-level visibility. It must protect data through company-aware security and support international warehouses without confusing physical movement with legal ownership.

Most importantly, it must make the next company easier to add than the previous one. When the twenty-third entity can be introduced through a standard discovery, configuration, testing and rollout process, the ERP has become a scalable platform rather than a growing collection of exceptions.

That is the central architecture lesson from Sasmar’s 6-to-22-company journey.

Frequently Asked Questions

1. How did Sasmar scale Odoo from six to 22 companies?

Sasmar expanded its Odoo environment through a long-term transformation that supported additional companies, regions and operating functions. Scaling required more than creating new company records. The architecture needed multi-company controls, shared and company-specific data rules, local accounting, warehouse structures, security, intercompany processes and consolidated reporting.

2. Should every company use the same chart of accounts in Odoo?

Using a common chart can simplify reporting but local statutory requirements may require variations. A scalable model uses standard accounts where possible and maps local accounts to consistent group reporting categories.

3. Can products and contacts be shared across Odoo companies?

Yes. Products and contacts can be shared where this supports the group operating model. Company-dependent commercial, fiscal and accounting properties must still be configured correctly. Clear data ownership and duplicate-control rules are essential.

4. How does an intercompany transaction work in Odoo?

An intercompany purchase order in one company can generate a linked sales order in another company. Delivery, receipt, invoicing and billing remain attached to the correct legal entities. Pricing, taxes, currency, product mapping and reverse flows must be configured and tested.

5. Can Odoo support multiple currencies across global companies?

Yes. Each company can have its own base currency and can transact in foreign currencies. The group must define exchange-rate policies, foreign-currency accounts, gain or loss treatment and the translation method used for consolidated reporting.

6. How should access be controlled in a multi-company Odoo database?

Users should receive company access and functional permissions through defined business roles. Record rules, approval limits and separation of duties should prevent unauthorized cross-company access. Custom modules and automated jobs must also respect company context.

7. What should be tested before adding a new company?

Testing should cover sales, purchasing, inventory, accounting, tax, banking, intercompany transactions, integrations, reporting, security and migration reconciliation. Negative access tests, returns, cancellations and failure recovery should also be included.

8. Does adding more companies automatically cause Odoo performance problems?

No. Performance depends on transaction volume, data size, custom code, reporting, integrations, scheduled jobs and infrastructure. A 22-company environment requires realistic load testing and ongoing monitoring because these workloads operate together in one ERP environment.