Localização fiscal fechada ou fork prende o cliente

Existe uma decisão na escolha de um ERP brasileiro que quase ninguém avalia na hora certa, e que define se a empresa vai ter liberdade ou dependência pelos próximos dez anos: quem é dono do código da sua localização fiscal.

A tese é direta:

Localização fiscal fechada ou em fork privado prende o cliente. Localização upstream da OCA, não.

Não é discurso ideológico de “software livre”. É uma análise de risco de fornecedor — o tipo de coisa que um bom gestor faz antes de assinar um contrato de ERP que vai durar anos.

O fiscal brasileiro é onde mora a dependência

Implementar o núcleo de um ERP — vendas, compras, estoque, financeiro — é relativamente comoditizado. O que diferencia, no Brasil, é a localização fiscal: NF-e, NFS-e, CT-e, SPED, eSocial, e agora a transição da Reforma Tributária. É a parte mais complexa, a que muda toda hora (cada nota técnica da SEFAZ, cada layout novo), e a que, se parar de ser mantida, trava o seu faturamento.

Por isso a pergunta “de quem é o código fiscal” é a pergunta que importa. Há três modelos no mercado:

1. Produto fechado / “OCA-compatível” — um fornecedor vende a localização como caixa-preta. Você não vê o código, não pode auditar, não pode levar para outro lugar.
2. Fork privado — alguém pegou uma base aberta, fechou num repositório próprio e seguiu desenvolvendo em paralelo, sem devolver para a comunidade.
3. Upstream da OCA — o código fiscal vive em repositório público (github.com/OCA/l10n-brazil), licença AGPL/LGPL, com múltiplos mantenedores ativos.

Os dois primeiros têm um ponto cego em comum: um único fornecedor controla a sua conformidade fiscal. Se ele encerrar as atividades, for vendido, ou simplesmente decidir não investir mais naquele produto, você fica desamparado — com um ERP em produção e ninguém para manter a parte que não pode parar.

Trust-Code: o risco previsível que virou caso público

Isso não é hipótese. É história recente.

No início da era Odoo 8.0, a Trust-Code forkou a localização brasileira da OCA e seguiu um caminho próprio, em repositório separado, com seu próprio conjunto autoral — sem contribuir de volta para o upstream. Os dois mundos nunca foram reconciliados. Foi uma decisão que fragmentou o esforço da localização brasileira e, principalmente, prendeu os clientes a uma única empresa.

Quando a Trust-Code encerrou, o resultado foi o previsível: dezenas de empresas com Odoo em produção ficaram sem mantenedor, sem roadmap e sem rota para os saltos de versão e para a Reforma Tributária. O código no GitHub continua público, mas público e estagnado não paga contracheque nem emite nota — cada nota técnica nova da SEFAZ virou problema individual de cada cliente.

O ponto não é “a Trust-Code foi má empresa”. O ponto é que o modelo de fork privado embute esse risco por construção. O desfecho não foi azar — foi a consequência esperada de concentrar a conformidade fiscal de muitas empresas em um único fornecedor.

Upstream da OCA é portabilidade de fornecedor

Agora compare com o modelo upstream. Quando a localização fiscal da sua empresa está no repositório público da OCA:

• Você pode auditar — o código é aberto.
• Múltiplos mantenedores ativos — não depende de uma empresa só. A KMEE está entre as mantenedoras principais, mas não é a única; é uma comunidade.
• Trocar de integradora é decisão comercial, não drama técnico — qualquer outra empresa que trabalhe com OCA pega de onde a anterior parou, porque o código é o mesmo. Nada de migração só para mudar de fornecedor.

Essa última é a parte que as pessoas não enxergam até precisarem: a portabilidade de fornecedor. Num produto fechado ou fork, sair custa o mesmo que migrar — porque é migrar. No upstream da OCA, sair é só contratar outra empresa.

E aqui vai a frase que resume o nosso lado: quando recomendamos OCA, estamos recomendando um modelo em que você não fica refém nem da própria KMEE. Se um dia você quiser trocar, pode. É exatamente por isso que confiamos nele.

O que isso significa na prática

Se você está escolhendo um ERP brasileiro agora, ou reavaliando o atual, três perguntas separam liberdade de dependência:

1. O código da minha localização fiscal é público e auditável?
2. Existe mais de uma empresa capaz de manter e dar suporte a ele?
3. Se o meu fornecedor sumir amanhã, eu continuo emitindo nota?

Se a resposta a qualquer uma for “não”, você não comprou um ERP — comprou uma dependência. E, no Brasil, com a Reforma Tributária reescrevendo o motor fiscal ao longo dos próximos anos, depender de um único fornecedor para acompanhar essa transição é um risco que dá para evitar na largada.

Leituras relacionadas

• Migração do fork Trust-Code para a OCA l10n-brazil — o caminho prático de saída do fork.
• Localização Fiscal Brasileira no Odoo — o que a localização OCA cobre e por que é o padrão de mercado.
• Comparativos de ERP — Odoo frente a alternativas proprietárias e SaaS.
• Reforma Tributária 2026: IBS, CBS, IS — por que a transição torna a portabilidade ainda mais valiosa.