Multi-empresa multi-CNPJ no Odoo+OCA: padrões A, B e C explicados

Toda empresa brasileira de porte médio ou maior cedo ou tarde tem mais de um CNPJ. Pode ser holding com subsidiárias, filial em outro estado por benefício fiscal, separação de operações industrial e comercial, marca distinta para um nicho, ou simplesmente reestruturação societária herdada. A pergunta é como o Odoo lida com isso — e a resposta tem três padrões arquiteturais bem diferentes, com trade-offs reais.

Este post explica os padrões A, B e C, quando usar cada um, e o que costuma decidir a escolha em projetos reais.

Padrão A: multi-empresa em uma única base

A configuração padrão do Odoo. Você tem uma base de dados, um banco PostgreSQL, uma instância, e dentro dela cria várias res.company — cada uma com seu CNPJ, inscrição estadual, plano de contas (compartilhado ou específico), série de NF-e, conta bancária.

Como funciona na prática

• Usuários têm acesso a uma ou mais empresas via campo allowed_company_ids.
• A interface tem um seletor de empresa no topo direito; você opera “como” uma empresa por vez.
• Documentos (NF-e, faturas, ordens) são vinculados a uma company_id. As regras de segurança do Odoo filtram automaticamente.
• Plano de contas pode ser único (todas empresas usando os mesmos códigos) ou separado por empresa.
• Consolidação de relatórios é nativa — o Odoo tem relatórios “todas empresas” para gerência.

Quando usar

• Empresas do mesmo grupo, mesma operação geral, com fluxo de operações entre elas (transferências, vendas intercompany).
• Mesmo time de TI, mesmas customizações, mesma versão do Odoo desejada.
• Faturamento agregado até R$ 1-2 bilhões — acima disso a base começa a pesar e o padrão B ou C entra em cena.

Trade-offs

• Vantagem: consolidação fácil, intercompany transparente, time único de operação.
• Risco: se uma empresa precisa de customização incompatível com as outras (ex.: regime fiscal radicalmente diferente), você cria condicionais por company_id que vão crescendo.

Padrão B: uma base de dados por empresa

Cada empresa tem sua própria base PostgreSQL, sua própria instância Odoo, frequentemente seu próprio domínio. As bases são independentes — usuário, customizações, módulos instalados, versão do Odoo, tudo separado.

Como funciona na prática

• N bases independentes, cada uma com seu CNPJ.
• Consolidação é externa — você exporta dados de cada base e consolida em ferramenta de BI ou em uma quarta base “consolidador”.
• Operações entre empresas viram integração — uma venda intercompany de A para B é uma NF-e na A e uma compra na B, com webhook ou job de sincronização ligando os dois.
• Cada empresa pode evoluir tecnicamente no seu ritmo — uma pode estar em Odoo 18, outra em 16, outra em 14.

Quando usar

• Empresas que operam de forma muito autônoma (negócios distintos, times distintos, sistemas distintos).
• Quando há requisito legal/contratual de isolamento de dados (ex.: empresa do grupo opera contrato de governo com cláusula de segregação).
• Quando uma das empresas é muito maior que as outras e não quer arrastar customizações alheias.
• Em aquisições recentes onde a empresa adquirida ainda não foi integrada culturalmente.

Trade-offs

• Vantagem: isolamento total, evolução independente, falha em uma não derruba as outras.
• Custo: N vezes a infraestrutura, N vezes a manutenção, consolidação manual ou via integração custom.

Padrão C: hub central com satélites

Um modelo híbrido: existe uma base “hub” que concentra dados mestres (clientes, produtos, plano de contas referencial, fornecedores estratégicos) e bases “satélite” por empresa que consomem o hub via API ou replicação.

Como funciona na prática

• O hub é a fonte da verdade para cadastros mestres compartilhados.
• Cada satélite tem seu Odoo operacional — vendas, compras, estoque, fiscal, financeiro.
• Sincronização do hub para satélites via webhooks ou jobs agendados.
• Consolidação contábil/financeira é feita em uma camada separada (BI ou Odoo “consolidador” puxando das satélites).
• Evolução técnica das satélites é independente, mas o hub puxa o ritmo dos cadastros.

Quando usar

• Grupos com muitas empresas (5+) operando em mercados parecidos mas com autonomia operacional.
• Quando os cadastros mestres são estratégicos e compartilhados — clientes corporativos atendidos por múltiplas empresas do grupo, fornecedores com contratos guarda-chuva.
• Em estruturas com filial vs matriz onde a matriz dita catálogo de produtos e tabela de preços.
• Quando o padrão B ficou caro de manter em consolidação.

Trade-offs

• Vantagem: combina autonomia operacional com governança de dados mestres.
• Complexidade: você precisa de um time técnico que entenda a integração e mantenha. Não é configuração, é arquitetura.

Como decidir

Em projetos reais, três variáveis costumam decidir:

1. Volume de transações intercompany: muito → padrão A. Pouco → padrão B ou C.
2. Autonomia operacional das empresas: alta → B ou C. Baixa → A.
3. Maturidade do time de TI: limitada → A. Robusta → qualquer um.

Empresas no Simples e Lucro Presumido com 2-4 CNPJs raramente saem do padrão A — não justifica. Empresas no Lucro Real com 5+ CNPJs e operações distintas costumam acabar no C, depois de tentar o A e descobrir que o seletor de empresa começa a virar fonte de erro humano.

Para complexidade fiscal específica de cada CNPJ — múltiplos regimes, benefícios estaduais, ICMS-ST de diferentes estados — vale ler EFD ICMS/IPI layout 20 e Reforma Tributária 2026.

A KMEE implementa os três padrões em Odoo+OCA há mais de 14 anos. Se sua empresa quer revisar a arquitetura atual ou desenhar uma migração de ERP com multi-CNPJ, fale com nosso time pela página de contato.