Imagine a seguinte cena.
A empresa concluiu a atualização do Protheus para a release 12.1.2510. O ambiente subiu, as rotinas abriram, os usuários voltaram a trabalhar e as primeiras notas fiscais foram autorizadas. Na reunião de acompanhamento, a sensação é de alívio: “Agora estamos preparados para a Reforma Tributária.”
É justamente aí que pode começar o problema.
A release 12.1.2510 é necessária, mas não é uma garantia de conformidade. Ela coloca o Protheus sobre uma base atualmente suportada e capaz de receber as evoluções da TOTVS. Mas a Reforma Tributária não chega pronta dentro da atualização. Entre instalar a nova versão e operar corretamente com CBS e IBS existe um caminho que envolve regras fiscais, cadastros, TSS, Configurador de Tributos, customizações, integrações e, principalmente, testes reais do negócio.
Essa diferença parece pequena quando explicada em uma reunião técnica. Na operação, porém, ela separa uma atualização bem-sucedida de um faturamento vulnerável.
Essa pergunta ganhou ainda mais importância em agosto de 2026.
A Receita Federal e o Comitê Gestor do IBS adiaram o início de determinadas validações automáticas relacionadas aos campos de CBS e IBS nos documentos fiscais eletrônicos. Na prática, isso significa que uma NF-e, NFC-e ou CT-e pode ser autorizada mesmo sem todas as informações que futuramente provocarão rejeição.
Muita gente interpretou a medida como um adiamento da própria obrigação. Não foi isso que aconteceu.
O esclarecimento oficial foi direto: o cronograma da Reforma Tributária continua válido. O que foi temporariamente flexibilizado foi a rejeição automática do documento, não a necessidade de adequação. A empresa ganhou uma margem operacional para não interromper o faturamento, mas não recebeu autorização para deixar o projeto de lado.
Esse é talvez o maior risco deste momento: confundir autorização técnica da nota com correção fiscal da operação.
Uma nota aceita pela Sefaz pode carregar informação incompleta, cálculo inadequado ou classificação inconsistente. O erro pode não aparecer na tela do faturista. Pode surgir depois, na escrituração, na apuração, na contabilização, no crédito do cliente ou em uma fiscalização.
Segundo o próprio comunicado da Receita Federal e do CGIBS, em 4 de agosto de 2026, 88% dos documentos dos contribuintes alcançados pela obrigação já eram transmitidos com as novas informações. Ou seja: a flexibilização não deve ser lida como motivo para esperar, mas como uma oportunidade curta para testar e corrigir com mais segurança.
Veja o esclarecimento oficial da Receita Federal e do CGIBS e as orientações da Receita Federal para 2026.
Porque ela é a fundação sobre a qual o restante do trabalho precisa acontecer.
A release 12.1.2410 encerrou seu ciclo regular. Conforme orientação publicada pela TOTVS, as empresas que permanecem nela dependem da contratação de Garantia Estendida para continuar recebendo atualizações, ou precisam migrar para a 12.1.2510, que é a versão atualmente suportada.
Em um cenário estável, operar em uma versão antiga já exigiria atenção. Durante a implantação da maior mudança tributária das últimas décadas, o risco é muito maior. As regras ainda estão sendo detalhadas, as notas técnicas recebem novas versões e os produtos precisam acompanhar alterações de leiaute, parâmetros, eventos e validações.
Estar na 2510 não significa que o trabalho terminou. Significa que a empresa finalmente tem uma base adequada para continuar o trabalho.
A própria TOTVS explica as alternativas de suporte em sua documentação sobre ciclo de vida e release 12.1.2510.
O erro mais comum é imaginar a Reforma Tributária como um pacote que será aplicado ao servidor. Mas ela atravessa o funcionamento da empresa.
O Protheus precisa estar atualizado, assim como RPO, dicionário e demais componentes. O TSS precisa reconhecer os novos campos e gerar corretamente os documentos eletrônicos. O Configurador de Tributos precisa refletir as operações reais da organização. Produtos, clientes, fornecedores, municípios e classificações precisam estar coerentes.
Depois vem uma camada ainda mais delicada: tudo aquilo que foi construído ao redor do padrão.
Uma customização ADVPL pode consultar diretamente campos antigos da TES. Um portal pode recalcular o pedido antes de enviá-lo ao Protheus. Uma integração com WMS, e-commerce ou sistema fiscal pode esperar um leiaute que mudou. Uma API pode ignorar campos novos porque eles simplesmente não existiam quando ela foi criada.
Nenhum desses problemas é resolvido apenas pela instalação da release.
Ao mesmo tempo, a TOTVS está conduzindo a transição dos cálculos fiscais baseados na TES para o Configurador de Tributos. O planejamento divulgado prevê a migração completa das operações fiscais para esse novo modelo até 2027. Isso não elimina imediatamente a TES, mas muda seu papel e exige que a empresa compreenda o que continuará nela e o que será governado pelo FISA170.
Esse movimento está descrito na orientação oficial da TOTVS sobre a transição da TES para o Configurador de Tributos.
Em termos simples, a cadeia é esta:
release suportada → componentes atualizados → TSS compatível → regras tributárias configuradas → cadastros consistentes → integrações ajustadas → operação homologada.
Se um elo estiver errado, o sistema pode continuar funcionando e, ainda assim, produzir um resultado incorreto.
Quando uma equipe técnica conclui um upgrade, é natural verificar se o serviço subiu, se os usuários conseguem entrar e se as principais rotinas abrem. Isso comprova que o ambiente está operacional. Não comprova que a empresa está preparada para a Reforma Tributária.
Para comprovar isso, é necessário escolher operações reais e acompanhá-las do começo ao fim.
Uma venda, por exemplo, começa no cadastro e na formação do pedido. Passa pelo cálculo dos tributos, pela geração da nota e do XML, pela autorização, pelo financeiro, pelo estoque e pelo custo. Depois chega à escrituração e à contabilização. Se houver cancelamento, devolução ou ajuste, o caminho precisa continuar coerente.
A Reforma também introduz situações que merecem tratamento específico, como as Notas de Crédito e de Débito previstas no contexto da Nota Técnica 2025.002. Elas existem para formalizar ajustes que reduzem ou aumentam o imposto devido e mostram como a mudança vai muito além da inclusão de CBS e IBS em uma nota convencional. A TOTVS detalha esses documentos em sua documentação sobre Notas de Crédito e Débito.
Por isso, o teste precisa envolver TI, Fiscal, Contabilidade e as áreas que executam as operações. Cada equipe enxerga uma parte diferente do mesmo fluxo. Só quando essas visões se encontram é possível dizer que o processo foi realmente homologado.
Não é necessário começar com um questionário de cem itens. Uma conversa objetiva costuma revelar bastante.
Peça à equipe que escolha uma operação relevante e mostre o caminho completo dentro do ambiente de homologação. Pergunte qual regra determinou o cálculo, onde CBS e IBS foram gravados, como chegaram ao XML, qual foi o reflexo no financeiro e na contabilidade e quais integrações participaram do processo.
Se a resposta ficar dividida entre várias pessoas, sem uma visão única; se ninguém souber dizer quais customizações tocam aquele fluxo; ou se o principal argumento for apenas “a nota foi autorizada”, ainda existe trabalho a fazer.
Outro sinal importante é a ausência de evidências. Um projeto seguro deixa rastros: cenários definidos, resultados esperados, XMLs conferidos, responsáveis pela aprovação e registro do que foi testado. Não para criar burocracia, mas para impedir que a segurança dependa da memória de quem acompanhou a atualização.
Se o projeto ficar restrito ao Fiscal, corre o risco de definir corretamente as regras sem compreender todas as dependências do sistema. Se ficar restrito à TI, pode produzir uma implantação tecnicamente impecável que não representa a realidade tributária da empresa.
A adequação acontece na interseção.
O Fiscal conhece a natureza das operações. A Contabilidade enxerga os reflexos e as reconciliações. A TI conhece ambientes, integrações e customizações. As áreas de negócio sabem onde existem exceções que nunca chegaram à documentação. E a direção precisa decidir prioridades, porque nem todos os riscos têm o mesmo impacto sobre faturamento e continuidade.
A dificuldade da Reforma Tributária no Protheus não está apenas na quantidade de configurações. Está na necessidade de fazer áreas diferentes enxergarem o mesmo processo.
Na OBIFY, o trabalho não começa pela promessa de uma atualização rápida. Começa pelo entendimento do ambiente e da operação.
Primeiro, analisamos a release, os componentes, o TSS, os módulos utilizados e a situação do Configurador de Tributos. Em seguida, mapeamos as operações mais sensíveis, o volume e a complexidade das TES, as customizações e as integrações que podem interferir no cálculo ou no documento fiscal.
Com essa visão, o projeto deixa de ser uma lista genérica de atualizações e passa a ter prioridades reais. Uma empresa industrial, uma distribuidora e uma prestadora de serviços podem utilizar o mesmo Protheus e enfrentar riscos completamente diferentes.
A atualização técnica é planejada junto com a configuração, a homologação e a validação das áreas. Cada cenário precisa mostrar não apenas que a nota foi aceita, mas que o processo permaneceu coerente até seus efeitos fiscais, financeiros, contábeis e operacionais.
O objetivo não é apenas migrar o Protheus para a 12.1.2510. É garantir que a empresa continue comprando, vendendo, faturando, recebendo, escriturando e contabilizando com segurança durante toda a transição.
“Já estamos na 2510?” é uma pergunta importante. Mas ela não é suficiente.
A pergunta que realmente protege a empresa é outra:
“Conseguimos demonstrar, em nossas operações reais, que o processo inteiro está preparado?”
Quando a resposta vem acompanhada de cenários homologados, documentos conferidos, integrações avaliadas e responsabilidades claras, a release deixa de ser apenas uma atualização tecnológica e passa a sustentar uma verdadeira adequação.
Quando a resposta ainda depende de suposições, existe tempo para agir — mas esse tempo não deve ser confundido com tranquilidade.
Se sua empresa está na 12.1.2410, começou a migração para a 12.1.2510 ou já atualizou o ambiente sem conseguir medir o grau real de prontidão, a OBIFY pode realizar um diagnóstico estruturado. Solicitar diagnóstico
A antiga DTM agora se chama OBIFY!