O que muda em 1º de novembro
A partir de 1º de novembro de 2026, microempresas e empresas de pequeno porte optantes pelo Simples Nacional passam a emitir NFS-e exclusivamente pelo Emissor Nacional, pela versão web ou pela API. A regra está na Resolução CGSN nº 191/2026, que adiou a data original de 1º de setembro. O MEI não muda nada: ele já emite pelo padrão nacional desde 2023.
Para quem emite pelo portal, muda a tela. Para quem emite pelo sistema de gestão, muda a integração: a prefeitura deixa de autorizar as notas dessas empresas, e a conexão que o ERP mantinha com o município passa a conversar com a API nacional.
Nas migrações para o padrão nacional que acompanhamos, vi notas rejeitadas, faturamento parado e tabela de-para criada às pressas na véspera. Quase sempre por causa de coisas que a antiga integração resolvia em silêncio e que agora passaram a ser decisão da empresa. Separei os três pontos que mais aparecem, para quem ainda tem alguns dias para revisar.
Três pontos onde vejo a integração falhar
- A classificação do serviço chega vazia. No padrão nacional, quem escolhe o código NBS e o código de tributação nacional é quem emite a nota. Antes, boa parte disso ficava com o sistema da prefeitura. A maioria dos ERPs que encontro foi parametrizada para o modelo municipal e não tem esses campos preenchidos.
A saída mais comum é uma tabela de-para montada fora do sistema, na correria. Ela resolve a virada e cria um problema para os meses seguintes, porque guarda uma decisão fiscal num arquivo técnico, muitas vezes sem dono. Minha recomendação é definir dois responsáveis: o contador ou o fiscal do cliente pelo conteúdo, e o fornecedor do sistema (ou a TI, quando existe) pela publicação, com registro de cada alteração.
- A rejeição fica parada no log. Uma nota recusada pelo ambiente nacional só é corrigida se a mensagem chega a quem entende o motivo. Se o retorno fica num log técnico, o escritório descobre o problema pelo cliente, dias depois.
Um exemplo que apareceu em migrações que acompanhamos: notas recusadas porque o indicador de operação não combinava com o NBS escolhido. Até 31 de dezembro, o ambiente nacional tolera a ausência dos dados de IBS e CBS, mas valida o que é enviado. Se o sistema manda um indicador de operação, ele precisa existir na tabela oficial e corresponder ao serviço. Essas notas só passaram depois da troca do indicador. Por isso defendo que a rejeição volte para o sistema em linguagem que o fiscal entenda.
- Ninguém testou o cancelamento. Muita integração é testada só na emissão. Cancelar, substituir e consultar uma nota pelo ambiente nacional são fluxos diferentes, e costumam aparecer pela primeira vez quando o cliente precisa deles com pressa. Vale também não deixar a emissão toda para o último dia útil: a virada do mês concentra volume, e qualquer instabilidade pesa mais justamente aí.
O segundo prazo que corre junto: IBS e CBS
A troca de emissor não mexe no calendário de IBS e CBS, mas os dois prazos caem no mesmo período, e é esse encontro que eu recomendo olhar com cuidado. Para a maioria dos serviços sujeitos ao ISS, os grupos de IBS e CBS na NFS-e são exigidos desde 1º de outubro de 2026. Plataformas digitais, condomínios, locação e alguns outros casos entram em 1º de dezembro. Optantes do Simples que fizeram a opção por apurar IBS e CBS pelo regime regular entram em 1º de janeiro de 2027.
Até 31 de dezembro de 2026, a ausência desses grupos não impede, sozinha, a autorização da nota. Depois do início de cada obrigação, porém, a falta das informações caracteriza desconformidade, sujeita às sanções do Ato Conjunto RFB/CGIBS nº 4/2026. Na prática, uma nota que hoje passa pode estar gerando passivo.
O código NBS e o indicador de operação também orientam o IBS e a CBS. Um de-para mal resolvido agora gera rejeição hoje e desconformidade depois.
Checklist para revisar com o cliente
- Confirmar com o fornecedor do sistema que as notas já vão para a API do Emissor Nacional, e não mais para o sistema da prefeitura.
- Conferir se cada serviço vendido tem código NBS e código de tributação nacional definidos, e quem responde por essa classificação.
- Se existir uma tabela de-para fora do sistema, registrar quem a mantém e qual versão da tabela oficial ela usa.
- Emitir em ambiente de testes uma nota de cada família de serviço, e não só a mais comum.
- Provocar uma rejeição de propósito e ver se a mensagem chega legível a quem precisa corrigir.
- Testar cancelamento e consulta, além da emissão.
- Combinar com o cliente e com o fornecedor do sistema o que acontece se a integração parar na virada do mês: quem é avisado e qual é a alternativa de emissão.
E, até 31 de dezembro, revisar se as notas já levam os grupos de IBS e CBS nas datas que valem para cada serviço.
Cinco dias para não parar o faturamento
Há cerca de dois anos, a Pearson nos procurou num momento difícil. A empresa precisava integrar o próprio sistema aos sistemas da SEFAZ por uma exigência legal de nota fiscal, e as datas legais já tinham ficado para trás. Estava em jogo pelo menos metade do faturamento da companhia no Brasil.
Era outro documento fiscal e outra escala de empresa, mas a semana foi a mesma que ninguém quer viver: descobrir a falha de integração perto do prazo, com o faturamento em risco. Deu certo, graças a um time que topou correr junto. Mas a corrida pode ser evitada com teste antes da virada. Por isso insisto no item 5 da lista: provoque uma rejeição de propósito. O caminho feliz é o teste que menos ensina.
Daniel Ladvanszky é cofundador e CEO da Fluid (fluidapi.io), plataforma de orquestração de integrações entre sistemas de gestão, bancos e o ambiente fiscal.
Fonte: Portal Contábeis.
