O que significa uma release expirada
A pergunta chega quase sempre no mesmo formato. Alguém do time fiscal avisa que um pacote não pôde ser aplicado, ou o time de TI descobre que uma correção pedida à TOTVS depende de uma versão que a empresa não tem. Só então a palavra expiração entra na conversa, e o que parecia um chamado técnico vira uma decisão de contrato, prazo e risco operacional.
A confusão é compreensível. Release expirada não trava o sistema. O Protheus continua abrindo, o faturamento continua rodando e ninguém recebe tela de bloqueio. O que muda é invisível no dia a dia e aparece exatamente quando a empresa mais precisa de resposta: quando surge uma alteração legal.
O Protheus tem ciclo de vida definido por versão. O comunicado oficial da TOTVS sobre a 12.1.2410, publicado em 16 de abril de 2026, informa a expiração em 30 de junho de 2026 e registra que, a partir dessa data, a TOTVS fica desobrigada a manter disponíveis os serviços de modificações, adaptação às mudanças de legislação, manutenções e adequações técnicas no release expirado.
Duas coisas costumam ser confundidas, e separá-las resolve metade da conversa.
| O que muda | Antes da expiração | Depois da expiração |
|---|---|---|
| Atendimento a dúvidas | Disponível com contrato ativo | Continua disponível com contrato ativo |
| Pacotes de manutenção | Entregues para a versão | Somente com garantia estendida contratada |
| Adaptação a mudança de legislação | Produzida para a versão | TOTVS fica desobrigada a manter |
| Funcionamento do sistema | Normal | Normal, sem bloqueio de tela |
Na maior parte do ano, a diferença passa despercebida. Em ano de mudança fiscal, ela determina se o ambiente consegue ou não acompanhar a legislação. É a mesma distinção que separa suporte oficial de consultoria especializada: canal aberto não é o mesmo que problema resolvido.
Garantia estendida: o que ela cobre e o que ela não resolve
A garantia estendida é o mecanismo que a TOTVS oferece a clientes que precisam de mais tempo em uma versão já expirada. O comunicado descreve a vigência a partir de 1º de julho de 2026 e o que ela assegura: solicitar e receber pacotes de manutenção, que são as correções de não conformidade e as alterações legais referentes à legislação que fazia parte da versão expirada.
Dois pontos merecem atenção, e os dois aparecem com frequência em diagnóstico de ambiente.
Ela precisa ser contratada. A TOTVS orienta que a solicitação seja feita com o Executivo ou a Executiva de Solução de Negócios da conta. Não é benefício que se ativa sozinho quando a versão expira. Existem empresas que passaram pela data acreditando que estavam cobertas e descobriram o contrário ao precisar de um pacote.
Ela compra tempo, não permanência. É uma extensão com prazo, pensada para dar espaço a um projeto de atualização, não para substituir esse projeto. Tratar a garantia estendida como estado definitivo do ambiente adia a decisão até o ponto em que ela deixa de ser planejada e passa a ser emergencial.
Por que a versão instalada virou uma questão fiscal
Até pouco tempo atrás, a conversa sobre release era conduzida por TI, com argumentos de estabilidade, performance e acesso a novas funcionalidades. Em 2026 ela ganhou componente fiscal direto.
A documentação da TOTVS sobre a Nota Técnica 2025.002 relaciona as versões atendidas pela adequação e as condições de cada uma. O quadro é objetivo:
| Componente | Versão | Condição na adequação da NT 2025.002 |
|---|---|---|
| Protheus | 12.1.2610 | Atendida |
| Protheus | 12.1.2510 | Atendida |
| Protheus | 12.1.2410 | Somente com garantia estendida |
| Protheus | 12.1.2310 | Somente com garantia estendida |
| TSS | 12.1.2510 | Atendido |
| TSS | 12.1.2410 | Somente com garantia estendida. Sem ela, a TOTVS orienta migrar para a 12.1.2510 |
A mesma documentação descreve o que a adequação exige em termos de trabalho: aplicação de pacote, patch e nfesefaz, patch fiscal de expedição contínua, atualização dos arquivos de schema e do RPO do TSS, criação de parâmetros específicos no Sigacfg, entre eles MV_CSTGXML, MV_RTC55 e MV_2500240, e configuração de IBS e CBS no Configurador de Tributos.
A leitura é direta. A versão instalada deixou de ser escolha de infraestrutura e passou a ser pré-requisito de qualquer trabalho de adequação fiscal. Não existe parametrização possível sobre uma base que não recebe o pacote.
Um esclarecimento para evitar leitura apressada: a TOTVS não publica exigência de atualização. O que existe é a relação de versões atendidas e o calendário de ciclo de vida. A conclusão sobre o que fazer é da empresa, e depende de qual versão ela usa, se contratou garantia estendida e qual horizonte de adequação precisa cumprir.
A parte que quase ninguém verifica: o TSS
O TSS é o componente responsável pela comunicação com os ambientes autorizadores. É por ele que os documentos fiscais eletrônicos trafegam, e ele tem ciclo de vida próprio.
Na mesma documentação, a orientação da TOTVS para o TSS é explícita: quem está na release 12.1.2410 sem garantia estendida precisa migrar para a 12.1.2510. E a atualização tem ordem definida, primeiro os arquivos de schema, depois o RPO, depois o pacote da versão.
Isso cria uma situação que aparece com frequência. A empresa organiza o projeto de adequação, revisa cadastros, ajusta classificação tributária, configura regras no Configurador de Tributos e conclui o trabalho no Protheus. Mas o TSS ficou fora do escopo. O resultado é um ambiente parametrizado que não consegue transmitir.
Há um segundo item de mesma natureza. Em 2026 o eSocial migrou a cadeia de certificados usada na comunicação, com produção plena a partir de 24 de junho de 2026. Em ambientes Protheus instalados na infraestrutura do cliente, o componente afetado é justamente o TSS, que precisa reconhecer as novas autoridades certificadoras. Ambientes hospedados em nuvem da TOTVS não demandam essa ação do cliente.
Os dois casos apontam para o mesmo hábito de gestão: o TSS entra na lista de verificação junto com o Protheus, e não depois dele.
As seis perguntas que classificam o seu cenário
Antes de discutir projeto, orçamento ou prazo, vale responder a seis perguntas. Elas costumam ser suficientes para classificar a situação.
- Qual é a release exata do Protheus em produção? Não a versão que consta no contrato ou a que o time acredita ter, e sim a que está instalada. Divergência entre as duas é mais comum do que parece em ambientes com mais de um servidor.
- Qual é a versão do TSS? Precisa ser verificada separadamente, porque o ciclo de vida é outro.
- A garantia estendida foi contratada? E, se foi, até quando vale.
- Quando foi a última aplicação de pacote? Ambiente na versão correta com pacotes de meses atrás não está adequado, está apenas elegível.
- Existe ambiente de homologação equivalente ao de produção? Sem ele, qualquer atualização vira teste em produção.
- As customizações estão mapeadas? Em ambientes maduros, o custo real de uma atualização está nas customizações e integrações, não no pacote.
Um ambiente que responde às seis com clareza tem um problema de execução. Um ambiente que não responde a três ou mais tem, antes disso, um problema de governança.
O que fazer quando a release já expirou
Não existe caminho único. A escolha depende de prazo, criticidade fiscal e capacidade de parada. Três cenários se repetem:
| Cenário | Passo imediato | O que ele não resolve |
|---|---|---|
| Prazo curto, operação não pode parar | Contratar garantia estendida e usar a janela para planejar | A necessidade do projeto de atualização continua |
| Versão distante da atual | Atualização em etapas, com homologação e plano de retorno | Não cabe em uma parada única de fim de semana |
| Versão próxima da suportada | Definir cadência de aplicação de pacotes | Sem cadência, o acúmulo se repete em dois anos |
Quando a empresa está em uma versão distante da atual, a atualização tende a ser conduzida em etapas, com mapeamento de customizações, homologação por processo crítico e plano de retorno definido antes da execução. Tratar esse caso como evento único de fim de semana é a origem da maior parte dos incidentes que aparecem depois.
Nos três cenários, o passo inicial é o mesmo: levantar a situação real do ambiente, com dados verificáveis, antes de decidir. É a diferença entre planejar uma atualização e reagir a uma.
O que a suspensão da rejeição de notas mudou nessa conta
Em 31 de julho de 2026, a Receita Federal e o Comitê Gestor do IBS aprovaram ato técnico conjunto que suspendeu a obrigatoriedade de preenchimento das informações de IBS e CBS nos documentos fiscais eletrônicos. O texto oficial afirma que os documentos não serão rejeitados na ausência desses campos.
Isso reduziu a pressão imediata sobre a emissão. Não reduziu o trabalho. A distinção está detalhada em caiu a rejeição técnica, não a obrigação legal.
O cronograma oficial de implementação dos documentos fiscais eletrônicos, publicado dias antes, mantém as etapas seguintes com datas próprias ao longo de 2026 e 2027, a começar por NFS-e e NFCom em 1º de outubro. E a dependência técnica descrita aqui continua igual: a adequação exige pacotes, e os pacotes exigem versão atendida.
Para quem está com release expirada, a leitura mais útil é que a suspensão comprou tempo de calendário, e tempo de calendário é exatamente o insumo que um projeto de atualização precisa. Usar essa janela para planejar é diferente de usá-la para adiar.
Fontes oficiais
- Central de Atendimento TOTVS: Garantia Estendida TOTVS Backoffice Linha Protheus 12.1.2410, comunicado de 16 de abril de 2026, com a data de expiração e a vigência da garantia estendida.
- Central de Atendimento TOTVS: Reforma Tributária, Nota Técnica 2025.002, IBS e CBS, com as versões atendidas, os pacotes, os parâmetros e a orientação para o TSS.
- Receita Federal: flexibilização da obrigatoriedade de informações em documentos fiscais, publicada em 01/08/2026.
- Receita Federal: cronograma de implementação dos documentos fiscais eletrônicos.
Conteúdo verificado em 06/08/2026 diretamente nas fontes citadas. A documentação da TOTVS e o cronograma da Reforma já foram revisados mais de uma vez em 2026. Confirme a publicação vigente antes de decisões de projeto.
Em resumo
- A 12.1.2410 expirou em 30/06/2026, com garantia estendida a partir de 01/07/2026. O sistema continua funcionando: o que muda é o acesso a pacotes e a adaptações à legislação.
- Atendimento a dúvidas e entrega de pacotes são coisas diferentes. O primeiro continua com contrato ativo. O segundo depende de a versão estar no ciclo de manutenção.
- A garantia estendida precisa ser contratada com o Executivo ou a Executiva de Solução de Negócios, e compra tempo, não permanência.
- Na adequação da NT 2025.002, 12.1.2510 e 12.1.2610 são atendidas. 12.1.2310 e 12.1.2410 são atendidas somente com garantia estendida.
- O TSS tem ciclo de vida próprio. Sem garantia estendida na 12.1.2410, a orientação da TOTVS é migrar para a 12.1.2510. Ambiente parametrizado com TSS fora da condição não transmite.
O próximo passo é objetivo: levantar release do Protheus, versão do TSS, situação da garantia estendida, data do último pacote, existência de homologação e mapa de customizações. Seis informações que dizem se o ambiente está preparado, elegível ou exposto.
Perguntas frequentes
O Protheus para de funcionar quando a release expira?
Não. O sistema continua operando normalmente, sem bloqueio de tela. O que muda é o acesso a pacotes de manutenção e às adaptações às mudanças de legislação para aquela versão. O comunicado da TOTVS registra que, após a expiração, a empresa fica desobrigada a manter esses serviços para o release expirado.
A garantia estendida é automática?
Não. A TOTVS orienta que a contratação seja tratada com o Executivo ou a Executiva de Solução de Negócios da conta. Ela não é ativada apenas pelo fato de a versão ter expirado, e é comum uma empresa descobrir que não estava coberta no momento em que precisa de um pacote.
Quais versões do Protheus são atendidas na adequação da Nota Técnica 2025.002?
Conforme a documentação da TOTVS consultada em 06/08/2026, as versões 12.1.2510 e 12.1.2610 recebem os pacotes normalmente, e as versões 12.1.2310 e 12.1.2410 recebem somente para clientes com garantia estendida contratada.
O TSS precisa entrar nesse levantamento?
Sim. O TSS tem ciclo de vida próprio. Para a release 12.1.2410 sem garantia estendida, a orientação da TOTVS é migrar para a 12.1.2510. Um ambiente parametrizado com TSS fora da condição atendida não consegue transmitir os documentos fiscais.
Atualizar a release resolve a adequação fiscal?
Não sozinha. A atualização é o pré-requisito. A adequação envolve aplicação de patches fiscais, atualização de schemas do TSS, criação de parâmetros, revisão de cadastros, classificação tributária e configuração de regras, com homologação antes da produção.
Quanto tempo leva uma atualização de release?
Depende do volume de customizações, do número de integrações e da existência de ambiente de homologação equivalente ao de produção. O levantamento desses três itens é o que permite estimar prazo com alguma confiabilidade, e costuma ser rápido de fazer.
Faz sentido pular versões para chegar direto na mais recente?
Depende do ponto de partida e da distância entre as versões. É uma decisão que se toma depois do mapeamento de customizações e integrações, não antes dele.
Nota técnica: este conteúdo tem finalidade informativa e operacional. Não substitui análise jurídica, tributária ou contábil específica. Regras, leiautes e cronogramas podem ser atualizados pelos órgãos competentes; valide sempre a versão vigente e o contexto da sua empresa.