Você paga Enterprise e o fiscal ainda depende de terceiros.
A profundidade está na OCA.
A localização brasileira oficial do Odoo Enterprise, mantida pela Odoo SA, cobre o básico de NF-e e contabilidade, mas se apoia em motor de cálculo de imposto e parceiros externos para o que é difícil de verdade: SPED completo, eSocial, Reinf, CT-e, MDF-e e ICMS-ST. Isso vira custo recorrente, caixa-preta e dependência. A OCA l10n-brazil entrega o fiscal nacional inteiro em código aberto, com rota pronta para a Reforma Tributária 2026. A KMEE migra com método, mantendo a licença Enterprise ou eliminando ela.
O que é a localização brasileira do Odoo Enterprise
A localização brasileira do Odoo Enterprise é o l10n_br oficial, mantido pela Odoo SA dentro do código comercial do produto. Ela nasceu para entregar o essencial da operação fiscal: emissão de NF-e, plano de contas brasileiro e os impostos mais comuns. Para o cálculo tributário mais profundo, a arquitetura oficial se apoia em motor de cálculo de imposto e parceiros externos de credenciamento fiscal, que entram como serviço acoplado ao Enterprise. Na prática, o fiscal brasileiro que aparece "incluso" depende de uma camada de terceiros para funcionar de ponta a ponta.
Isso tem três consequências diretas. A primeira é custo recorrente: além da licença Enterprise por usuário, a operação fiscal pesada costuma carregar mensalidade de motor de cálculo, integrador de NF-e e, conforme o caso, custo por documento emitido. A segunda é dependência e caixa-preta: a regra tributária roda em um serviço que você não audita nem versiona, então quando o cálculo diverge, o cliente não consegue abrir o código e entender o porquê. A terceira é profundidade fiscal limitada: SPED EFD ICMS/IPI, EFD Contribuições, ECD, ECF, eSocial, Reinf, NFS-e de muitas prefeituras, CT-e e MDF-e nunca foram o forte da localização oficial.
A OCA l10n-brazil seguiu outro caminho desde a Odoo 8, em 2014: motor fiscal próprio (l10n_br_fiscal), em código aberto sob licença AGPL/LGPL, com regra tributária dentro do seu próprio Odoo, auditável e versionada. A KMEE está entre as mantenedoras principais desse projeto. A pergunta que separa liberdade de dependência é simples: o cálculo do seu imposto roda em código que você pode abrir e levar para outro fornecedor, ou em um serviço fechado que para de funcionar no dia em que você cancela a assinatura?
Um ponto que costuma gerar confusão, e que precisa ficar claro: migrar a localização para a OCA não significa parar de usar os módulos do Odoo Enterprise. Se você quiser, continua com tudo do Enterprise (Studio, Documents, Sign, Marketing Automation, os módulos de negócio e o suporte da Odoo SA). O que sai são apenas os módulos de localização limitada da Odoo SA, que dão lugar à localização da OCA, com muito mais funcionalidade (SPED, eSocial, Reinf, CT-e, MDF-e, NFS-e de múltiplas prefeituras, ICMS-ST e o motor fiscal auditável). A OCA roda em cima do Enterprise sem conflito. Trocar de localização e trocar de edição são duas decisões separadas: você pode fazer só a primeira.
E os seus dados não ficam para trás: os dados antigos (cadastros de parceiros e produtos, plano de contas, histórico fiscal) são migrados para a estrutura de dados da OCA. Como o motor fiscal da OCA tem um modelo de dados diferente do oficial, essa passagem é um re-mapping feito com método, não uma simples troca de módulo. É por isso que a KMEE trabalha com paralelo controlado e validação contra a SEFAZ antes da virada.
O que isso significa em produção hoje
Você paga licença e ainda paga fiscal por fora
Licença Enterprise por usuário somada a motor de cálculo de imposto, integrador de NF-e e, em muitos casos, custo por documento. O fiscal "incluso" cobra duas vezes.
Cálculo de imposto em caixa-preta
Quando ICMS-ST, DIFAL com FCP ou uma retenção sai errada, a regra está em serviço de terceiro que você não abre nem versiona. Diverge e ninguém audita.
SPED parcial ou terceirizado
EFD ICMS/IPI, EFD Contribuições, ECD e ECF nunca foram fortes na localização oficial. A maioria opera com ferramenta externa ou fica exposta em fiscalização.
eSocial e Reinf fora do escopo
Folha com eSocial e Reinf não são cobertos pela localização Enterprise. Quem precisa montou stack paralela. A OCA tem módulo autoral KMEE de eSocial em produção.
Cobertura fiscal rasa em casos reais
NFS-e de múltiplas prefeituras, CT-e e MDF-e, ICMS-ST por estado, DIFAL e FCP. A operação brasileira de verdade encosta no limite da localização oficial rápido.
Reforma Tributária 2026 dependendo de terceiros
IBS, CBS e IS exigem mudança estrutural no motor fiscal. A OCA já tem PRs ativos e você controla o timeline. No Enterprise, você espera o fornecedor e o motor de cálculo decidirem.
Onde a localização oficial e a OCA divergem
| Critério | Enterprise (l10n_br oficial) | OCA l10n-brazil |
|---|---|---|
| Onde roda o cálculo de imposto | Motor de cálculo e parceiros externos acoplados | Motor fiscal próprio (l10n_br_fiscal), no seu Odoo |
| Código auditável | Fechado, regra tributária em caixa-preta | Aberto, AGPL/LGPL, no GitHub da OCA |
| Modelo de custo | Licença por usuário + motor de cálculo + por documento | Sem licença por usuário nem por documento no core |
| SPED (EFD ICMS/IPI, Contribuições, ECD, ECF) | Parcial ou terceirizado | EFD em PR ativo (KMEE), ECD nativo (v16), ECF em desenvolvimento |
| eSocial + Reinf | Fora do escopo | Módulo autoral KMEE em produção |
| NFS-e, CT-e, MDF-e | Cobertura básica ou via parceiro | NFS-e de múltiplas prefeituras, CT-e e MDF-e nativos |
| ICMS-ST, DIFAL, FCP, retenções | Depende do motor externo | Nativo, no código que você abre |
| Rota Reforma Tributária 2026 (IBS/CBS/IS) | No timeline da Odoo SA e do parceiro | PRs ativos, timeline sob seu controle |
| Portabilidade de fornecedor | Presa ao serviço fiscal contratado | Qualquer integradora OCA assume o código |
5 etapas para migrar com segurança
Diagnóstico fiscal, contábil e de licença
Levantamento da versão Odoo atual, dos serviços fiscais contratados por fora (motor de cálculo, integrador de NF-e, custo por documento), volume de documentos por mês, estado de SPED e necessidade de eSocial e Reinf. Aqui também decidimos a rota: manter a licença Enterprise ou sair para Community. Entrega: plano de migração com escopo, rota e estimativa.
Plano de re-mapping fiscal e contábil
Como a OCA usa o motor l10n_br_fiscal, os modelos de dados fiscais não são os mesmos da localização oficial. Mapeamos o que migra um para um (parceiros, produtos com NCM e CEST), o que precisa de re-mapping (CFOP, CST e CSOSN, regimes, operações fiscais), saldos contábeis como abertura e os XMLs preservados para fiscalização.
Setup OCA na versão alvo
Recomendação atual: Odoo 16 com OCA l10n-brazil 16.0, production-ready em 2026. Instalação do l10n_br_fiscal, configuração do certificado A1, providers de NF-e e NFS-e por estado e prefeitura, plano de contas brasileiro e desligamento da dependência de motor de cálculo externo.
Paralelo controlado
De 1 a 3 meses operando os dois ambientes em paralelo, com conferência de NF-e gerados nos dois lados, validação de SPED contra validador da SEFAZ, conferência do cálculo de imposto agora aberto e auditável, e treinamento do time fiscal antes da virada.
Suporte pós-virada com SLA
Primeiros 90 dias com SLA dedicado e canal direto para os times fiscal e contábil. Depois, ciclo normal de squad ou suporte mensal. Se um dia você trocar de integradora, o código é OCA e qualquer empresa do ecossistema assume.
Pagar Enterprise não compra liberdade fiscal. Estar na OCA, sim.
A KMEE migra para a OCA clientes em situações parecidas, e em duas rotas claras:
- Quem fica no Enterprise pela funcionalidade de produto, mas quer o fiscal completo da OCA por baixo: troca só a localização e mantém a licença.
- Quem percebeu que pagava licença Enterprise por usuário só para emitir nota, sem usar Studio nem os módulos exclusivos: sai para Community com OCA e elimina a licença.
- Quem opera com motor de cálculo de imposto e integrador de NF-e cobrando por fora e quer trazer a regra tributária para dentro do próprio Odoo, auditável.
- Quem precisa de SPED completo, eSocial, Reinf, CT-e ou MDF-e que a localização oficial não cobre bem, e hoje vive de workaround externo.
São duas rotas, e a escolha é sua. Rota A: você mantém a licença Enterprise pelas funcionalidades de produto e troca apenas a localização fiscal para a OCA, ganhando profundidade fiscal sem abrir mão do Studio, Documents ou Sign. Rota B: se a licença Enterprise existe na sua operação basicamente para o fiscal, você migra para Community com OCA e elimina a mensalidade por usuário. O diagnóstico decide qual faz sentido, com números reais antes de qualquer recomendação.
O critério que o cliente brasileiro deveria aplicar antes de aceitar qualquer localização fiscal Odoo é direto: o cálculo do meu imposto roda em código que eu posso abrir, auditar e levar para outro fornecedor? Na localização Enterprise, a parte difícil roda em serviço fechado de terceiro. Na OCA, roda no seu Odoo, em código público. Quando o fiscal é seu, trocar de fornecedor é decisão comercial, não drama técnico.
Perguntas frequentes
Se eu já pago Odoo Enterprise, vale a pena migrar a localização para a OCA?
Depende de para que serve a sua licença. Se o Enterprise existe pelo Studio, Documents, Sign, Marketing Automation ou suporte Odoo SA, vale manter a licença e trocar só a localização fiscal para a OCA, porque você ganha profundidade fiscal (SPED, eSocial, Reinf, CT-e, MDF-e, ICMS-ST) e tira a dependência do motor de cálculo externo, sem perder as funcionalidades de produto. Se o Enterprise existe basicamente para emitir nota, o cálculo é diferente: você pode sair para Community com OCA e eliminar a licença por usuário. O diagnóstico mostra os dois cenários com números.
Qual a diferença arquitetural entre a localização Enterprise e a OCA?
A localização oficial mantida pela Odoo SA cobre o básico e se apoia em motor de cálculo de imposto e parceiros externos para a regra tributária mais profunda, em serviço fechado. A OCA reescreveu o motor fiscal (l10n_br_fiscal) para manter a regra tributária dentro do próprio Odoo, em código aberto e auditável. Os modelos de dados são diferentes na prática. Por isso migrar não é trocar de módulo: é refazer o mapping fiscal e contábil, com método.
Migrar do Enterprise para a OCA é só instalar outro módulo?
Não. Esse é o ponto mais importante de honestidade técnica. A localização oficial e a OCA usam modelos de dados fiscais diferentes, então a migração é um re-mapping fiscal e contábil: CFOP, CST e CSOSN, operações fiscais, regimes, plano de contas e saldos de abertura. É por isso que a KMEE trabalha com paralelo controlado e validação contra a SEFAZ, em vez de uma troca direta.
Quanto custa?
Não cravamos valor sem diagnóstico, mas o modelo de custo muda na sua direção. No Enterprise, você paga licença por usuário e, na operação fiscal pesada, costuma somar mensalidade de motor de cálculo, integrador de NF-e e às vezes custo por documento. Na OCA não há licença por usuário nem por documento no core: você paga implantação (escopo após diagnóstico), suporte mensal e infraestrutura. Se a rota for sair para Community, a licença Enterprise por usuário deixa de existir.
Dá para manter o Odoo Enterprise e trocar só a localização?
Sim, e é importante deixar claro: você não deixa de usar os módulos do Enterprise. A OCA l10n-brazil roda em Community e em Enterprise (100 por cento dos módulos OCA funcionam nas duas edições). Você mantém Studio, Documents, Sign, Marketing Automation, os módulos de negócio e o suporte da Odoo SA. O que sai são apenas os módulos da localização limitada da Odoo SA, que dão lugar à localização da OCA, com muito mais funcionalidade. Seus dados antigos (parceiros, produtos, plano de contas, histórico fiscal) são migrados para a estrutura de dados da OCA. É a Rota A da nossa metodologia.
Vou ficar refém da KMEE depois de migrar?
Não, e esse é o argumento central. O código da OCA fica no upstream público (github.com/OCA/l10n-brazil), com licença AGPL/LGPL e múltiplos mantenedores. Se um dia você trocar de integradora, qualquer outra empresa do ecossistema OCA assume o suporte, porque o código é o mesmo. É exatamente o oposto da localização fechada, onde o cálculo do imposto roda em serviço de terceiro que você não pode levar embora.
Quanto tempo demora a migração?
Depende do volume e da complexidade fiscal. Pequeno porte (até 200 NF-e por mês) leva de 2 a 3 meses; médio (200 a 2.000 NF-e) leva de 4 a 6 meses; grande (2.000 ou mais, multi-CNPJ) leva de 6 a 12 meses. Como os modelos de dados são diferentes, tratamos como migração estrutural com paralelo controlado, não como upgrade simples.
Mantenho meus XMLs de NF-e e o SPED de períodos anteriores?
Sim. Os XMLs de NF-e já emitidas ficam preservados (a SEFAZ não exige re-emissão, mas exige consulta) e o SPED de períodos anteriores continua disponível para fiscalização posterior. A migração trata os documentos novos no ambiente OCA; o histórico fica acessível.
E a Reforma Tributária 2026? A OCA está pronta?
A Reforma (IBS, CBS e IS) exige mudança estrutural no motor fiscal. A OCA já tem PRs ativos em desenvolvimento, e como o código é aberto você controla o timeline de adoção. Na localização Enterprise, a transição depende do calendário da Odoo SA e do motor de cálculo externo que você contratou. Estar na OCA durante essa transição é justamente onde a portabilidade vale mais.
Qual versão da OCA vocês recomendam hoje?
Em 2026, a versão estável e production-ready da OCA l10n-brazil é a 16.0. As versões 17 e 18 ainda têm gaps em módulos account, sale e purchase brasileiros. Migrar para a 16 hoje, com 17 e 18 vindo no roadmap, é o caminho de menor risco para uma operação fiscal em produção.
Paga Enterprise e o fiscal ainda depende de terceiros?
1 hora de diagnóstico. Mostramos as duas rotas, manter a licença Enterprise e trocar só a localização, ou sair para Community e eliminar a licença, com escopo, prazo e custo transparentes. Sem compromisso.