Reforma Tributária e sistema legado: modernize suas rotinas fiscais sem reescrever tudo

Tem uma rotina de apuração que toda virada de mês dá problema?

Um lote de NF-e que falha quando a SEFAZ cai?

Um módulo fiscal que ninguém quer tocar porque ninguém entende mais como funciona — e que agora, por causa da Reforma Tributária, precisa mudar? Se isso soa familiar, este conteúdo é pra você.

Com a chegada do IBS e da CBS, a padronização da NFS-e Nacional e uma sequência de Notas Técnicas (como a NT 004 e a NT 008) reorganizando layouts, campos e cálculos, quem mantém ERP, marketplace ou plataforma fiscal está sendo empurrado para o mesmo dilema: refatorar o sistema antigo ou reescrever tudo do zero?

O problema é que reescrever um sistema que roda há anos é um projeto caro, longo e arriscado — justamente o tipo de aposta que você não quer fazer no meio de uma transição tributária que muda as regras a cada nova nota técnica.

A boa notícia é que existe um caminho do meio. E ele é mais simples do que parece.

No vídeo abaixo, o time de produto da skail (nossa parceira) pega uma rotina clássica de qualquer ERP — uma régua de cobrança baseada em cron jobs — e mostra, na prática, como modernizar apenas a parte problemática da aplicação: sem reescrever o resto, sem microsserviços, sem Kubernetes, sem fila e sem arquitetura complexa.

O exemplo é uma régua de cobrança, mas a técnica é exatamente a mesma que você usaria para modernizar uma rotina de apuração mensal, um envio de lote de notas ou uma integração crítica com a SEFAZ. Vamos conectar os pontos.

O dilema de quem mantém software fiscal em 2026

O sistema tributário brasileiro já era um dos mais complexos do mundo.

Com a Reforma Tributária em curso, a complexidade ganhou um prazo. Sistemas emissores e ERPs precisam adequar layouts, acomodar os novos grupos de informação (como o IBSCBS na NFS-e), migrar de RPS/TXT/XML para o modelo DPS e revisar cálculos de alíquota.

Na prática, isso significa colocar a mão em código fiscal antigo — frequentemente aquele núcleo que processa obrigações, gera arquivos e fala com webservices instáveis. E é aí que mora o medo: esse código costuma ser cheio de cron jobs encadeados, rotinas frágeis e zero observabilidade.

Por que cron jobs encadeados são uma bomba-relógio fiscal

Pense numa sequência típica de fechamento: um job às 5h calcula, outro às 6h envia, outro às 7h concilia. Se o job das 5h falha, o das 6h roda sem dados. Se o das 6h atrasa, o das 7h perde a janela. E aí?

• O reprocessamento muitas vezes só acontece no dia seguinte — inaceitável quando há prazo legal envolvido.
• Quando algo quebra, começa a caça ao log: procurar trace, tentar reproduzir na máquina local, pedir dump de produção para homologação.
• Não há rastreabilidade clara do que aconteceu, quando e por quê — o que é péssimo num contexto onde auditoria fiscal não é opcional.

A alternativa: modernizar só a parte que dói (padrão Strangler Fig)

Em vez de reescrever o sistema inteiro, você isola uma única funcionalidade crítica, reconstrói essa parte de forma moderna e resiliente, e mantém todo o resto do ERP funcionando exatamente como sempre funcionou.

Esse é o padrão Strangler Fig: o sistema antigo segue de pé enquanto a peça nova assume o pedaço que importa.

No vídeo, é exatamente isso que acontece com a régua de cobrança.

O ERP legado (Node + MongoDB + cron) continua rodando, e só a rotina de cobrança é migrada — passando a ser uma execução durável, resiliente e observável, acionada via uma simples chamada REST a partir do código JavaScript que já existia.

Troque “régua de cobrança” por “rotina de emissão de NF-e em lote” ou “apuração de IBS/CBS” e você tem o roteiro de modernização fiscal mais seguro que existe: risco baixo, escopo pequeno, benefício alto.

Como cada recurso do vídeo se traduz no mundo fiscal

Os recursos demonstrados resolvem dores que qualquer dev de sistema fiscal conhece bem. O mapeamento é quase direto:

No vídeo (régua de cobrança)	No seu sistema fiscal
Hibernar e retomar após falhas (execução durável com checkpoints)	A SEFAZ ou a prefeitura caiu no meio do envio? A execução hiberna, libera recursos e retoma de onde parou — sem perder o lote nem travar o servidor segurando requisição síncrona.
Esperar eventos sem polling (wait for event)	Autorização assíncrona do documento, retorno de protocolo, webhook de pagamento. O processo simplesmente aguarda o evento chegar, em vez de ficar consultando status num loop.
WhenAny: pagamento ou vencimento (o que vier primeiro)	Autorização ou rejeição, retorno da SEFAZ ou timeout, confirmação ou prazo limite. Você modela a corrida entre dois desfechos com uma linha de código.
Operação determinística que evita duplicações	Reprocessou a rotina? A operação não duplica registro nem reemite a nota. É o mesmo princípio do idExterno / idempotência que evita nota fiscal duplicada — só que nativo no fluxo.
Retries e exponential backoff nativos	Diante da instabilidade crônica dos servidores públicos, as tentativas acontecem sozinhas, com espaçamento crescente, sem você escrever a lógica de retry na mão.
Observabilidade e auditoria sem caçar log	Rastreabilidade ponta a ponta de cada execução: o que rodou, quando, quantas tentativas, qual regra disparou. Exatamente o que uma auditoria fiscal exige — e sem contratar uma stack de observabilidade à parte.
Time Travel Debug	Reproduzir localmente uma execução real de produção sem acesso ao banco de produção nem às chaves de envio. Achou um bug numa apuração específica de um cliente? Você depura aquela instância exata, passo a passo.
Chamada de qualquer linguagem via REST	O legado em PHP, Node, Java ou C# continua intacto e aciona a rotina modernizada com um simples POST. Integração sem reescrita.

O ponto que importa: você passa a se preocupar apenas com a regra de negócio fiscal — escrita de forma linear, fácil de ler e de auditar.

Resiliência, tolerância a falhas, retomada, observabilidade e integração entre linguagens ficam por conta da plataforma. O código continua parecendo um monólito simples, mas se comporta como um sistema distribuído.

O que você vai ver no vídeo

São pouco mais de 37 minutos de demonstração prática, com código rodando. Alguns pontos que valem o play:

• 0:56 — O cenário: uma régua de cobrança configurável
• 4:27 — Por que cron jobs falham (e por que o encadeamento é perigoso)
• 5:39 — Strangler Fig: modernizar aos poucos, sem reescrever tudo
• 8:33 — Hibernar e retomar a execução após falhas
• 11:41 — WhenAny: esperar o pagamento ou o vencimento
• 13:18 — Observabilidade completa sem escrever um log sequer
• 22:42 — O legado em JavaScript chamando a função modernizada
• 26:09 — Time Travel Debug: reproduzir produção na sua máquina
• 34:26 — Auditoria ponta a ponta da execução

Modernizar o legado e abstrair o fiscal: as duas frentes

Existem dois tipos de complexidade drenando o tempo do seu time.

A primeira é a complexidade da sua própria aplicação — as rotinas frágeis, os cron jobs, o módulo que ninguém quer tocar.

Para essa, a abordagem do vídeo é o melhor atalho: modernize a parte crítica, sem o risco de um projeto de anos.

A segunda é a complexidade do fiscal em si — os milhares de municípios com regras diferentes de NFS-e, as constantes notas técnicas, as instabilidades de SEFAZ e prefeituras, os novos campos de IBS/CBS.

Essa é a complexidade que não traz vantagem competitiva nenhuma para você manter dentro de casa.

É exatamente aí que o Nota Gateway entra: nós absorvemos boa parte das instabilidades e das mudanças regulatórias para que você emita NF-e, NFC-e, NFS-e e CT-e com uma única API REST, com idExterno para evitar duplicidade e cobertura nacional — inclusive já preparados para a Reforma Tributária. Enquanto você moderniza o que é seu, deixa o caos das prefeituras e da SEFAZ com a gente.