Boa parte das rotinas de recebimento ainda depende do e-mail com o XML anexo do fornecedor. Existe um caminho oficial, e ele não passa pela caixa de entrada.

As notas já estão guardadas. Só não estão com você

As notas emitidas contra o seu CNPJ existem, estão organizadas em repositórios oficiais e ficam à sua disposição. Falta alguém indo buscá-las. E são dois endereços diferentes.

NF-e e CT-e ficam na SEFAZ. Notas fiscais de mercadoria e conhecimentos de transporte autorizados por qualquer estado são replicados para um ambiente nacional compartilhado entre as secretarias de fazenda. Com o certificado digital da empresa, dá para consultar e baixar os documentos em que o seu CNPJ aparece como destinatário ou tomador do frete, com os eventos posteriores. Um detalhe costuma surpreender: os documentos ficam disponíveis por cerca de 90 dias, e o que ninguém buscou nesse prazo não é mais recuperável por ali.

NFS-e fica no Ambiente de Dados Nacional. As notas fiscais de serviço seguem lógica semelhante, porém a competência é municipal. O Ambiente de Dados Nacional (ADN) concentra esses documentos e permite consultar aqueles em que a empresa é tomadora ou emissora. Onde a prefeitura mantém sistema próprio, nem sempre a nota aparece no dia da emissão, assunto que tratamos em por que sua nota pode demorar dias para aparecer no Portal Nacional.

O que a empresa perde quando a nota passa despercebida

O prejuízo raramente chega como um evento único. Ele se acumula em silêncio.

Crédito que evapora. Sem o documento não há escrituração no período, e sem escrituração o crédito de ICMS da compra e o do frete não entram na apuração. Imposto pago a mais, mês a mês, por falta de um arquivo.

Divergência com o fisco. A administração tributária já tem a nota. Quando a EFD não bate com o que o fisco recebeu do fornecedor, a diferença aparece nos cruzamentos automáticos. A pergunta que chega não é “por que você não recebeu?”, e sim “por que você não escriturou?”.

Confirmação por omissão. Sem manifestação da empresa no prazo legal, a operação descrita na NF-e é presumida como ocorrida, com os mesmos efeitos de uma confirmação expressa. E o prazo encurtou: desde 1º de junho de 2026, pelo Ajuste SINIEF nº 14/2026, a manifestação conclusiva caiu de 180 para 90 dias. O silêncio, nesse regime, não é neutro. Ele concorda.

Notas frias contra o seu CNPJ. Há fraude que consiste em emitir documentos contra empresas que não estão olhando, e a janela para recusar a operação é a mesma dos 90 dias. Quem só descobre a nota na conciliação do trimestre descobre junto que a lei já concordou, em nome da empresa, com uma compra que nunca existiu.

Operação desalinhada. Estoque que não confere com o recebimento físico, contas a pagar sem documento que as justifique, fechamento travado esperando XMLs e, no transporte, a divergência que aparece com o caminhão já retido na fiscalização.

Nada disso exige má-fé. Basta um fornecedor que digitou o e-mail errado.

Como o Motor Fiscal resolve isso

A consulta em si não é simples. Fazê-la todo dia, em todos os estabelecimentos, respeitando os limites que bloqueiam quem consulta demais (a rejeição 656) e ainda manifestando cada nota, sem o que a SEFAZ entrega só um resumo, e não o XML completo. É essa vigilância que o Motor Fiscal automatiza:

• Monitora os dois canais continuamente, buscando na SEFAZ as NF-e e os CT-e emitidos contra o seu CNPJ e no ADN as NFS-e (tomadas e emitidas) de todos os municípios, sem depender do e-mail do fornecedor.
• Cobre matriz e filiais, dentro dos limites de consulta dos ambientes oficiais, sem risco de bloqueio.
• Trata a manifestação como parte do fluxo, garantindo o XML completo dentro dos 90 dias e sinalizando o que exige decisão humana.
• Entrega o arquivo pronto para o ERP e a contabilidade, através de API, SFTP ou e-mail com o XML completo.

Se hoje a garantia de que nenhuma nota escapou é a confiança no e-mail dos fornecedores, vale uma conversa com a nossa equipe.

Fontes:
– NT 2014.002 – Distribuição de DF-e de Interesse dos Atores da NF-e
– Distribuição de DF-e de Interesse dos Atores do CT-e (Portal CT-e)
– Portal da NFS-e de padrão nacional (gov.br)

O post Como capturar as notas fiscais emitidas contra a sua empresa apareceu primeiro em Motor Fiscal | Escrituração e Automação Fiscal NFe CTe NFSe NFTS.

A confusão é compreensível. Ambas são eletrônicas, ambas documentam uma venda, ambas têm XML e chave de acesso. Mas a semelhança termina na aparência. Vale destrinchar o que separa os dois documentos — e onde eles se encontram, porque é nos casos de fronteira que mora o risco.

O ponto de partida: dois impostos, dois fiscos

A divisão não foi desenhada por conveniência documental; ela espelha a repartição de competências tributárias da Constituição.

A circulação de mercadorias é fato gerador do ICMS — Imposto sobre Circulação de Mercadorias e Serviços —, de competência estadual. O documento que a acoberta é a NF-e (Nota Fiscal Eletrônica, modelo 55), autorizada pela Secretaria da Fazenda (SEFAZ) do estado do emitente, dentro de um padrão nacional único definido pelo ENCAT e pela Receita Federal.

A prestação de serviços é fato gerador do ISS — Imposto Sobre Serviços —, de competência municipal, com a lista de serviços tributáveis definida pela Lei Complementar nº 116/2003. O documento correspondente é a NFS-e (Nota Fiscal de Serviço eletrônica), emitida contra a prefeitura do município competente.

Dessa origem distinta decorre quase tudo o mais.

As diferenças na prática

Duas dessas linhas merecem atenção especial.

O padrão técnico. A NF-e é um dos casos mais bem-sucedidos de padronização fiscal do mundo: um layout único, válido nos 26 estados e no Distrito Federal. A NFS-e percorreu o caminho oposto — cada um dos mais de 5.500 municípios pôde criar seu próprio layout, seu próprio webservice e suas próprias regras. É por isso que integrar emissão de NFS-e sempre foi um problema de engenharia maior do que integrar NF-e, apesar de o documento ser conceitualmente mais simples. O padrão nacional da NFS-e, mantido no portal do governo federal, existe justamente para encerrar essa fragmentação — a adesão dos municípios está em andamento e é monitorada publicamente.

O momento da emissão. NF-e acompanha mercadoria: sem autorização prévia da SEFAZ, o produto não deveria sair do estabelecimento. NFS-e documenta algo que já aconteceu: primeiro se presta o serviço, depois se emite. Essa inversão muda o desenho de qualquer processo — da logística ao faturamento.

Exemplos práticos: quando cada uma entra em cena

• Indústria vende equipamento para um distribuidor. Circulação de mercadoria: NF-e, com ICMS e, por ser industrialização, IPI.
• Consultoria presta serviço de implantação de software. Serviço da lista da LC 116/2003: NFS-e, com ISS devido, em regra, ao município do prestador — com exceções em que o imposto vai para o município da prestação.
• Assistência técnica troca a peça e cobra a mão de obra. O caso clássico de operação mista: a peça é mercadoria (NF-e, ICMS), o conserto é serviço (NFS-e, ISS). A LC 116/2003 define, item a item, quando o serviço com fornecimento de material fica todo no ISS e quando o material se separa para o ICMS. Errar essa separação é recolher o imposto errado para o ente errado — duas autuações potenciais em uma só nota.
• Restaurante. Parece serviço, mas o fornecimento de alimentação é juridicamente circulação de mercadoria: ICMS, documento de venda ao consumidor (NFC-e), não NFS-e. O exemplo vale como lembrete de que a intuição não substitui a lista da lei.

O que a reforma tributária faz com essa divisão

A distinção ICMS/ISS — e, portanto, boa parte da razão de ser da separação entre os dois documentos — tem prazo de validade. A Lei Complementar nº 214/2025 institui o IBS e a CBS, que ao longo da transição substituirão os tributos atuais sobre consumo, unificando a tributação de bens e serviços. Os documentos fiscais já começaram a se adaptar: os layouts da NF-e e da NFS-e vêm ganhando os campos do novo sistema.

Isso não significa que a diferença deixou de importar. Durante a transição — que se estende por anos —, as empresas conviverão com os dois mundos simultaneamente: o antigo (ICMS/ISS, com suas regras distintas) e o novo (IBS/CBS, com campos novos nos mesmos documentos). O período em que a distinção exige mais atenção não é o passado; é exatamente agora.

Onde a tecnologia entra

A diferença entre NF-e e NFS-e não é um problema de conhecimento — qualquer analista fiscal sabe recitá-la. É um problema de operação: sistemas que precisam falar com uma SEFAZ estadual e com dezenas de padrões municipais ao mesmo tempo, regras de validação que mudam por ente, documentos recebidos de fornecedores nos dois formatos, cada um com seu ciclo de vida e seus eventos.

É nessa camada que o Motor Fiscal trabalha: tecnologia para recepção e monitoramento de documentos fiscais eletrônicos que trata cada tipo de documento com as regras que lhe são próprias — para que a diferença entre produto e serviço seja uma decisão tributária consciente, e não um acidente de integração. Se a sua operação convive com os dois mundos, vale uma conversa.

Fechamento

NF-e e NFS-e compartilham o adjetivo “eletrônica” e pouco mais. Uma nasce do ICMS estadual e circula com a mercadoria; a outra nasce do ISS municipal e registra o serviço prestado. Entre elas ficam os casos mistos, onde os dois fiscos se encontram — e onde as autuações também. A reforma tributária vai, com o tempo, dissolver a fronteira. Até lá, tratá-la com precisão é o que separa uma operação fiscal madura de uma coleção de notas parecidas.

Fontes:
– Portal Nacional da NF-e (Ministério da Fazenda)
– Portal da NFS-e de padrão nacional (gov.br)
– Lei Complementar nº 116, de 31 de julho de 2003 (Planalto)
– Lei Complementar nº 214, de 16 de janeiro de 2025 (Planalto)

O post Nota fiscal de produto e nota fiscal de serviço: a diferença que define imposto, sistema e risco apareceu primeiro em Motor Fiscal | Escrituração e Automação Fiscal NFe CTe NFSe NFTS.

O Código de Benefício Fiscal (cBenef) existe para dar rastreabilidade a um dado que, por muito tempo, ficou implícito na apuração: qual benefício fiscal, exatamente, ampara cada operação. Com a atualização mais recente da tabela paulista, a identificação deixou de ser opcional na prática. Vale entender o que mudou, quem é atingido e o que fazer a respeito.

O que é o cBenef

O cBenef é um código obrigatório previsto no §15 do artigo 212-O do Regulamento do ICMS de São Paulo (RICMS-SP). Ele deve ser preenchido no campo “cBenef” da NF-e e da NFC-e sempre que a operação ou prestação for amparada por um tratamento tributário diferenciado — a saber:

• isenção;
• não incidência;
• redução de base de cálculo;
• regime especial de tributação com aplicação de percentual sobre a receita bruta;
• suspensão;
• diferimento.

Na prática, o código conecta a nota fiscal ao dispositivo legal que justifica o benefício. É o que permite ao fisco cruzar, de forma automatizada, o tratamento tributário declarado com a norma que o autoriza. Um detalhe técnico importante: o campo não se aplica a saídas tributadas com CST 00 acompanhadas de crédito outorgado.

O que mudou: o fim do “SEM CBENEF”

Até a versão anterior, a tabela oferecia o item “SEM CBENEF” — uma opção genérica que funcionava como válvula de escape para quem não identificava, ou não queria identificar, o código específico. A versão 20260626, publicada em 26 de junho de 2026, desativou essa opção a partir de 1º de julho de 2026.

O efeito é direto: para os CSTs em que São Paulo exige o preenchimento do código de benefício, o contribuinte precisa informar o cBenef correspondente ao tratamento tributário efetivamente aplicado. Não há mais o meio-termo. A ausência ou o uso incorreto do código pode gerar inconsistência no documento fiscal e apontamentos por parte da fiscalização.

Quem precisa se preocupar

A mudança atinge, sobretudo, quem emite documentos fiscais com CSTs vinculados a benefícios. Um exemplo concreto: uma empresa que vende produto com redução de base de cálculo (CST 20) e que, até junho, transmitia a nota apontando “SEM CBENEF” precisa agora localizar, na tabela oficial, o código específico daquela redução e vinculá-lo ao item — sob pena de a nota ser rejeitada ou marcada como inconsistente.

O alcance vai além do emissor isolado. Três públicos deveriam revisar seus cadastros antes que o problema apareça na apuração:

• Analistas e gestores fiscais, que precisam mapear quais produtos e operações usam benefícios e qual código os ampara.
• Escritórios contábeis, que respondem por múltiplos clientes com parametrizações distintas.
• Equipes de TI e fornecedores de ERP, que precisam garantir que o sistema não ofereça mais o código desativado e valide o preenchimento na origem.

Não foi só a desativação: a tabela ganhou códigos novos

A versão 20260626 também refletiu mudanças recentes na legislação paulista, com a criação e a atualização de códigos específicos. Entre eles:

• SP019090 — exclusão da gorjeta da base de cálculo do ICMS, relevante para o setor de alimentação;
• SP099009 — operações no âmbito da Nota Fiscal Fácil (NFF);
• SP011850 — isenção em Áreas de Livre Comércio, conforme o artigo 185.

Essas inclusões acompanham normas como a Portaria SRE nº 29, de 9 de junho de 2026, e o Decreto nº 70.667, de 3 de junho de 2026 — parte da manutenção contínua que a tabela recebe ao longo do ano. A lição operacional é que a tabela cBenef não é um cadastro que se configura uma vez: ela muda, e cada versão pode alterar o código correto para uma operação que já era rotina.

O que fazer agora

Como a regra já está em vigor, a ação é de correção, não de preparação. Em ordem de prioridade:

1. Baixar a versão 20260626 da tabela no portal oficial da SEFAZ-SP, disponível em PDF, XLSX e ODS.
2. Revisar o cadastro de produtos e operações, identificando todos os itens que usavam “SEM CBENEF” ou que dependem de um CST com benefício.
3. Vincular o código específico a cada operação, validando a correspondência entre o cBenef e o CST informado.
4. Bloquear o código desativado no ERP, para impedir que ele volte a ser emitido por hábito ou parametrização antiga.

Conclusão

A desativação do “SEM CBENEF” encerra uma conveniência que sempre foi frágil: declarar que existe um benefício sem dizer qual. Para o contribuinte organizado, é ajuste pontual de cadastro. Para quem tratava o campo como formalidade, é o momento em que a formalidade cobra a conta — a cada nota emitida com CST de benefício. Em um sistema que cruza declaração com norma de forma automatizada, o código genérico era uma lacuna esperando ser fechada. Foi fechada.

Fontes:
– Códigos de Benefícios Fiscais — cBenef (Portal da SEFAZ-SP)
– Tabela cBenef-SP, versão 20260626 (SEFAZ-SP, PDF)

O post SEFAZ-SP atualiza a tabela de cBenef e desativa o código genérico: o que muda na emissão em São Paulo apareceu primeiro em Motor Fiscal | Escrituração e Automação Fiscal NFe CTe NFSe NFTS.

Em 26 de junho de 2026, a Receita Federal comunicou a prorrogação da obrigatoriedade de pessoas físicas se inscreverem no Cadastro Nacional da Pessoa Jurídica (CNPJ) para emitir documentos fiscais nos casos em que a legislação do Imposto sobre Bens e Serviços (IBS) e da Contribuição sobre Bens e Serviços (CBS) passa a exigir. A data-limite foi transferida para 1º de janeiro de 2027.

O que a regra estabelece

A Lei Complementar nº 214/2025, que regulamenta o IBS e a CBS, adota um identificador cadastral padronizado — o CNPJ — para os emissores de documentos fiscais, inclusive determinadas pessoas físicas que hoje operam sem inscrição empresarial. Não se trata de converter todo cidadão em pessoa jurídica, mas de dar registro legível a quem realiza operações que a nova legislação considera tributáveis e, portanto, sujeitas a documento fiscal.

O escopo detalhado — quais atividades e situações serão abrangidas — depende de regulamentação operacional que a Receita Federal informa estar em elaboração. Até sua publicação, a lista definitiva de obrigados não está fechada.

Por que a prorrogação

A Receita Federal apresentou três motivos para adiar a exigência. Vale detalhar cada um, porque juntos eles explicam a decisão melhor do que a data isolada.

Dar tempo de adaptação aos contribuintes. A obrigação atinge, em boa parte, pessoas que nunca emitiram um documento fiscal e não têm contador nem departamento fiscal por trás. Exigir uma inscrição no CNPJ da noite para o dia, sem margem para aprender o processo, geraria mais erro e informalidade do que arrecadação. O prazo maior serve para que esse público entenda o que precisa fazer antes de ser cobrado.

Desenvolver um novo sistema de cadastro simplificado. A obrigação foi criada antes de existir uma ferramenta adequada para cumpri-la. Não faz sentido exigir que alguém se inscreva se o caminho para isso ainda está sendo construído. O adiamento dá tempo para esse sistema ficar pronto — e a Receita indicou como ele será: inspirado no modelo do Microempreendedor Individual (MEI), o cadastro mais simples e popular do país, feito pela internet, em poucos minutos e sem papelada. A ideia é que a inscrição da pessoa física seja igualmente rápida, digital e automática, já integrada aos programas usados para emitir a nota.

Implementar tudo de forma gradual. Além do cadastro, é preciso publicar as regras operacionais, treinar sistemas e orientar quem vai usar. A Receita optou por fazer essa transição por etapas, e não em uma única virada de chave, reduzindo o risco de o sistema não dar conta no primeiro dia.

Para o cidadão que será obrigado, a mensagem prática é simples: haverá uma forma fácil de se cadastrar, parecida com abrir um MEI, e ainda há tempo para isso. Para quem já trabalha com emissão de notas — empresas, contadores e desenvolvedores de sistemas —, o recado é diferente: o desafio não é o cadastro em si, mas garantir que seus programas saibam reconhecer e processar um CNPJ de pessoa física quando ele começar a aparecer nas operações.

Os prazos que já estão em curso

Fixar a atenção apenas em 1º de janeiro de 2027 ignora duas datas anteriores mais relevantes para quem desenvolve e opera sistemas fiscais.

A primeira: o sistema simplificado de inscrição deve estar disponível em novembro de 2026, cerca de dois meses antes de a obrigação tornar-se exigível.

A segunda: já está aberto o ambiente de testes (sandbox) para que emissores adaptem seus sistemas à emissão de documentos do IBS e da CBS, com integração aos ambientes de fiscalização e arrecadação. O prazo que importa para uma equipe de tecnologia não é a data da obrigatoriedade do contribuinte, mas a data em que o próprio software precisa estar validado. Essa etapa já pode — e deve — começar.

O que fazer no intervalo

O período até a virada de exercício é a janela adequada para preparação. Três frentes se destacam:

• Mapear a exposição. Identificar quantos parceiros, fornecedores ou prestadores pessoa física da operação tendem a entrar na obrigatoriedade define a dimensão do projeto.
• Tratar o CNPJ de pessoa física como caso de teste. O sistema emissor deve reconhecer e processar esse perfil sem adaptações improvisadas, incluindo validações e as alíquotas de IBS e CBS.
• Validar no sandbox com antecedência. O ambiente de testes permite corrigir falhas antes da produção, quando o erro custa prazo.

Conclusão

A prorrogação para 2027 não flexibilizou a reforma; recolocou a exigência no ritmo da infraestrutura que deve sustentá-la. A obrigação permanece, com o benefício de um cadastro mais bem estruturado. Para o contribuinte, é tempo de adaptação. Para quem constrói e opera os sistemas que receberão esses documentos, é um cronograma técnico que já está em andamento — desde novembro de 2026, não a partir de janeiro de 2027.

Fontes:
– Obrigatoriedade de inscrição de pessoas físicas no CNPJ para emissão de documentos fiscais é prorrogada para 2027 (Receita Federal, 26/06/2026)
– Lei Complementar nº 214, de 16 de janeiro de 2025 (Planalto)

O post Inscrição de pessoas físicas no CNPJ para emissão de documentos fiscais é prorrogada para 2027 apareceu primeiro em Motor Fiscal | Escrituração e Automação Fiscal NFe CTe NFSe NFTS.

A Receita Federal começa a emitir CNPJs com letras a partir de julho de 2026, conforme a Instrução Normativa RFB nº 2.229/2024. A mecânica da nova inscrição — formato, posições alfanuméricas, cálculo do novo dígito verificador, cronograma da emissão — já está detalhada em um post anterior aqui no blog.

O foco aqui é mais estreito: o que acontece com a chave de acesso da nota fiscal quando o CNPJ que ela embute deixa de ser puramente numérico. A resposta, curiosamente, não é exatamente a mesma para NF-e e para NFS-e — e o descompasso entre os dois ecossistemas vale conhecer.

A chave da NF-e ganha letras

A chave de acesso da NF-e — o código de 44 caracteres que identifica a nota — é construída a partir de campos da própria nota, e o CNPJ do emitente ocupa 14 dessas posições, no meio do código.

Hoje, a chave inteira é numérica. A regra de validação clássica em qualquer sistema é simples: 44 dígitos, todos números. Isso muda.

A Nota Técnica Conjunta DF-e 2025.001, publicada em 2025 pelo ENCAT — a coordenação técnica que reúne as Sefaz —, formaliza a decisão: a chave passa a aceitar letras maiúsculas (A-Z) em 12 posições centrais, exatamente as 12 primeiras posições do CNPJ do emitente — a parte que pode ter letras. Os 6 caracteres iniciais (UF e mês/ano) e os 26 finais — que incluem os dois dígitos verificadores do CNPJ, que seguem numéricos, mais modelo, série, número da nota e demais campos — permanecem como dígitos.

Em regex, a chave passa de algo como \d{44} para [0-9]{6}[A-Z0-9]{12}[0-9]{26}. Não há conversão por baixo dos panos: o CNPJ alfanumérico entra na chave como ele é, com as letras que tiver.

A mudança não atinge só a NF-e. A mesma nota técnica vale para o conjunto de documentos fiscais eletrônicos que usam estrutura semelhante de chave: NF-e, NFC-e, CT-e, CT-e OS, GTV-e, MDF-e, BP-e, BP-e TM, NF3-e e NFCom. Em abril de 2026, a NT 2026.004 complementou o trabalho com a atualização dos schemas XML (XSD), redefinindo os tipos dos campos CNPJ, chNFe e correlatos para o padrão alfanumérico.

E a NFS-e Nacional?

Aqui a história é menos resolvida.

A NFS-e Padrão Nacional, gerida pelo Comitê Gestor da NFS-e (SE/CGNFS-e), tem chave de acesso própria, com 50 caracteres. Dentro dela há um campo de “Inscrição Federal” de 14 posições que carrega o CNPJ do emitente — ou o CPF, com zeros à esquerda.

Até o fechamento desta análise, o SE/CGNFS-e não havia publicado nota técnica específica tratando do CNPJ alfanumérico. As oito notas técnicas já editadas para o Padrão Nacional cobrem outros temas — adequações para IBS/CBS, DANFSe v2.0, contingência —, mas o ajuste explícito para o novo formato de CNPJ ainda não saiu.

Operacionalmente, a expectativa é razoável: como o campo de Inscrição Federal na chave da NFS-e já é tratado como string — precisa acomodar CPFs com zeros à esquerda —, a transição tende a se resolver por mudança de tipo no schema, em uma NT futura. Enquanto isso não vier por escrito, prudência é tratar a NFS-e Nacional como ponto de atenção, não como ponto resolvido. E, no ecossistema municipal — emissores próprios de prefeituras que ainda não migraram para o Padrão Nacional —, fica caso a caso.

Onde isso quebra no software

A chave deixar de ser puramente numérica parece uma mudança pequena. Não é. Algumas frentes silenciosas:

Validações de formato. Qualquer expressão regular do tipo \d{14} para CNPJ ou \d{44} para chave precisa ser reescrita. Em formulários, APIs, jobs de ETL, planilhas com validação — todos.

Tipagem em banco de dados. Colunas declaradas como BIGINT, NUMERIC ou NUMBER(14) deixam de comportar o conteúdo. Migrar para VARCHAR(14) no CNPJ e CHAR(44) na chave é o caminho — com revisão de índices, chaves estrangeiras e relacionamentos.

Schemas XML. Os XSDs da NF-e foram redefinidos pela NT 2026.004 para tratar CNPJ e chNFe como strings alfanuméricas. Toda integração que valide payload contra schema antigo passa a rejeitar a nota.

Conciliação fiscal — o risco mais traiçoeiro. Rotinas que comparam chaves ou CNPJs como string seguem funcionando. Rotinas que fazem cast implícito para numérico (parseInt, CAST AS BIGINT, “tirar máscara e converter para número”) quebram silenciosamente quando a chave contém uma letra. Em batch noturno, sem alerta de erro, isso vira diferença de fechamento difícil de rastrear.

Cálculo do dígito verificador. O DV do CNPJ alfanumérico usa um algoritmo novo — módulo 11 com valor de cada caractere igual a “ASCII menos 48”. É retrocompatível: CNPJs puramente numéricos continuam batendo pelo método antigo. CNPJs com letras só batem pelo novo. Validadores feitos em casa precisam ser atualizados.

Código de barras do DANFE. O CODE-128C, padrão atual e exclusivamente numérico, deixa de funcionar para chaves com letras. A migração passa por adotar um modo híbrido CODE-128A/C. Detalhe técnico, mas relevante para quem imprime DANFE em volume.

O calendário

A NT 2026.004 estabelece:

• Ambiente de homologação: aceita CNPJ alfanumérico em chaves e payloads de NF-e/NFC-e a partir de 1º de junho de 2026.
• Ambiente de produção: a partir de 1º de julho de 2026 — mesma data em que a Receita Federal começa a emitir os primeiros CNPJs com letras.

Não há prorrogação anunciada. Como os primeiros CNPJs alfanuméricos saem em julho, qualquer empresa que receba uma nota desses primeiros emissores precisa estar pronta para processá-la a partir do dia 1º.

Fechamento

CNPJs já emitidos no formato numérico continuam válidos e seguem produzindo chaves numéricas — a convivência entre os dois mundos é permanente, não uma transição passageira. O que muda é que, a partir de julho, qualquer sistema precisa estar preparado para o outro formato também, sem assumir que “todo CNPJ é número” como verdade óbvia.

A NF-e tem a regra clara e o cronograma definido. A NFS-e Nacional ainda precisa de palavra oficial sobre o tema — e, no ecossistema municipal, é caso a caso.

Quem opera com o Motor Fiscal pode ficar tranquilo pois todas as alterações necessárias já estão implantadas em produção.

Fontes:
– Nota Técnica Conjunta DF-e 2025.001 — Portal NF-e (ENCAT)
– Nota Técnica 2026.004 v1.00 — Portal NF-e
– CNPJ Alfanumérico — Receita Federal
– Manual do Contribuinte NFS-e Nacional v1.2 (gov.br/nfse)
– Instrução Normativa RFB nº 2.229/2024

O post CNPJ alfanumérico e a chave da nota fiscal: o que muda em NF-e e NFS-e apareceu primeiro em Motor Fiscal | Escrituração e Automação Fiscal NFe CTe NFSe NFTS.

A NFS-e — Nota Fiscal de Serviço Eletrônica — é, na essência, um arquivo XML. Mas quase ninguém lê XML. O que se imprime, arquiva e confere é a sua versão legível: o DANFSe. E é essa versão que acaba de mudar.

Em 5 de maio de 2026, a Secretaria-Executiva do Comitê Gestor da NFS-e publicou a Nota Técnica nº 008, que especifica o DANFSe v2.0 — uma nova versão do documento. Não se trata de ajuste cosmético: o layout foi reconstruído para acomodar a reforma tributária do consumo. E traz, embutido, um prazo que vale anotar.

Atualização (30/07/2026): em 14 de julho a SE/CGNFS-e publicou a versão 1.02 da NT 008, com novos ajustes de leiaute, e prorrogou o prazo de adequação de 1º de julho para 3 de agosto de 2026. As datas deste artigo já refletem o novo prazo.

O que é o DANFSe

DANFSe é a sigla de Documento Auxiliar da Nota Fiscal de Serviço Eletrônica. Ele está para a NFS-e como o DANFE está para a NF-e: não é a nota em si — é a representação impressa dela, em papel, voltada à consulta rápida e aos processos administrativos de quem recebe o serviço.

O DANFSe resume os dados da NFS-e em uma única página A4, no formato retrato, e traz um QR Code que leva ao registro real da nota no portal nacional. Serve a quem precisa de um documento físico; a nota com validade jurídica continua sendo o XML.

É esse documento auxiliar que a NT 008 redesenhou.

O que muda no layout v2.0

A mudança mais visível está no cabeçalho, que agora identifica o documento como “DANFSe v2.0”. As que importam, porém, são estruturais — o documento foi reorganizado para falar a língua do IBS e da CBS sem abandonar a do ISS.

Uma quarta parte na operação: o Destinatário. O DANFSe v2.0 identifica as partes em blocos próprios — prestador/fornecedor, tomador/adquirente e intermediário — e formaliza uma quarta: o Destinatário da Operação, em bloco separado do tomador. A distinção faz sentido na lógica do IBS e da CBS, em que quem adquire a operação e quem efetivamente a recebe nem sempre são a mesma pessoa. Quando coincidem, o bloco se reduz a uma linha: “o destinatário é o próprio tomador/adquirente da operação”.

A terminologia ganhou um par. Os blocos de partes passam a se chamar “Prestador/Fornecedor” e “Tomador/Adquirente”. Prestador e tomador são o vocabulário do ISS; fornecedor e adquirente, o do IBS e da CBS. O documento usa os dois ao mesmo tempo — retrato fiel do momento: transição, não substituição imediata.

Um bloco inteiro de tributação IBS/CBS. Esta é a alteração de maior peso. O v2.0 traz uma seção dedicada aos novos tributos, com código de situação tributária (CST) e classificação tributária, base de cálculo após exclusões e reduções, alíquotas de IBS estadual e municipal, alíquota da CBS e os valores apurados. Ela não substitui nada: convive, na mesma página, com os blocos de Tributação Municipal (ISSQN) e Tributação Federal. A mesma nota passa a exibir, lado a lado, o imposto que está de saída e os que estão chegando.

Um documento com prazo de validade interno. Há um detalhe revelador. O bloco de Tributação Federal ainda traz PIS e COFINS de apuração própria — mas a NT 008 é explícita: essas linhas só serão impressas para NFS-e com data de competência até o fim de 2026. Depois disso, a CBS assume o lugar. Parte do conteúdo do documento já nasce com data para sair de cena.

Novos totais e um canhoto. O bloco de valores foi desdobrado: “Valor Líquido da NFS-e”, “Total do IBS/CBS” e “Valor Líquido da NFS-e + IBS/CBS” passam a aparecer separadamente. E o layout prevê um bloco de “Canhoto” opcional — com data de cientificação, identificação e assinatura —, para registrar o recebimento.

Resumo das alterações — o documento, antes e depois:

A mudança que não está no layout – O fim da impressão do DANFSe via API

A NT 008 não é apenas um manual de desenho. Ela carrega uma decisão operacional, e é a parte que mais exige atenção.

Hoje, o ambiente nacional da NFS-e oferece uma API que gera o DANFSe: o sistema do emissor chama o serviço e recebe o documento pronto. A nota técnica determina que essa API será suspensa em 3 de agosto de 2026. A partir dessa data, gerar o DANFSe v2.0 passa a ser responsabilidade de cada emissor — ERPs, sistemas fiscais e softwares de emissão. A NT 008 existe justamente para que cada um produza o documento conforme o padrão: tamanho de página, fontes, espessura de linha, sombreamento, QR Code e até as marcas d’água de nota cancelada ou substituída.

Para o gestor fiscal ou de TI, a leitura é direta. Se o processo da empresa depende da API nacional para imprimir ou entregar o DANFSe, essa dependência tem data para acabar: 3 de agosto.
Mas calma! O Motor Fiscal já está pronto para o v2.0 e oferece uma API própria para a geração do DANFSe.

O Motor Fiscal já está pronto para o DANFSe v2.0

A suspensão da API nacional transfere para cada emissor a tarefa de produzir o documento no novo padrão. O Motor Fiscal já está preparado para o DANFSe v2.0 e oferece API própria para a entrega do PDF do documento — exatamente a função que deixa de ser provida nacionalmente em 3 de agosto.

Além da API, há soluções customizadas para cenários específicos, incluindo a geração do PDF do DANFSe a partir apenas da chave de acesso da nota.*

Para empresas com volume relevante de NFS-e, trocar uma dependência que será desligada por uma solução já adaptada ao v2.0 é menos um projeto e mais a substituição de uma peça.

Teste o Motor Fiscal grátis por 7 dias Prefere conversar antes? Fale com um especialista.

* Consulte condições.

Um novo layout costuma ser um detalhe. Este não é: o DANFSe v2.0 é a reforma tributária deixando de ser texto de lei e virando documento impresso. E, a partir de 3 de agosto, imprimi-lo deixa de ser tarefa do ambiente nacional para ser de quem emite.

Fontes:
– Nota Técnica nº 008 — Especificações Técnicas do DANFSe (SE/CGNFS-e)
– Documentação técnica — Portal da NFS-e Nacional (gov.br)

O post DANFSe v2.0: o novo layout da NFS-e e o prazo de 3 de agosto apareceu primeiro em Motor Fiscal | Escrituração e Automação Fiscal NFe CTe NFSe NFTS.

O post O intermediário na NFS-e: a terceira parte que também responde pelo ISS apareceu primeiro em Motor Fiscal | Escrituração e Automação Fiscal NFe CTe NFSe NFTS.

Enquanto boa parte do mercado discute APIs, Open Finance e Pix Automático, um pedaço silencioso da rotina financeira brasileira continua rodando em arquivos .REM e .RET — o bom e velho CNAB 240/400. E foi exatamente aí que um malware chamado #CNABHunter resolveu morar.

A peça foi identificada por pesquisadores e chamou atenção por um detalhe pouco usual: antes de roubar qualquer coisa, ela precisou entender o que é um layout posicional bancário. É raro ver um trojan estudando manual da Febraban — mas aqui estamos.

O que é o CNABHunter

Diferente dos banking trojans clássicos, que dependem de overlay de tela ou captura de credenciais em internet banking, o CNABHunter vai direto à fonte do pagamento: o arquivo de remessa.

Em vez de tentar enganar o usuário no momento da transação, ele monitora diretórios onde arquivos CNAB 240 e CNAB 400 são gerados, salvos ou movidos. Ao encontrar um arquivo válido, faz o que qualquer fraudador faria com tempo livre e conhecimento de layout: substitui dados bancários do favorecido (banco, agência, conta, dígito) por contas controladas pelo atacante, mantendo a integridade estrutural do arquivo para não levantar suspeita no envio.

Em termos práticos, o arquivo continua “válido” para o banco. O total bate, os registros somam, o trailer fecha. Só que o dinheiro vai para outro lugar.

Por que isso é, antes de tudo, um problema fiscal e financeiro

A área de Segurança da Informação tende a tratar isso como incidente de endpoint. Faz sentido — mas subestima o estrago. O impacto real chega primeiro no Financeiro, no Fiscal e no Controller, justamente porque o ataque acontece depois de toda a aprovação interna ter sido concluída.

Pense no fluxo típico de uma remessa de pagamentos:

1. Fornecedor emite documento fiscal.
2. Contas a Pagar registra, concilia, agenda.
3. Gerente aprova o lote.
4. Sistema ERP gera o arquivo CNAB.
5. Arquivo é enviado ao banco.
6. Banco processa, debita, transfere.

O CNABHunter ataca entre o passo 4 e o passo 5 — exatamente o intervalo em que ninguém mais está olhando, porque presume-se que tudo o que precisava ser revisado já foi. É o ponto cego perfeito: depois da governança, antes da execução.

As consequências que aparecem no fechamento

Conciliação bancária quebrada. O razão registra pagamento a um fornecedor; o extrato mostra débito para uma conta desconhecida. A diferença pode levar dias para ser notada, especialmente em empresas com volume alto de pagamentos diários.

Duplicidade de pagamento. O fornecedor real cobra novamente — afinal, ele não recebeu. A empresa paga duas vezes: uma para o fraudador, outra para regularizar a relação comercial. Isso também distorce DRE, fluxo de caixa e indicadores de DSO/DPO.

Risco de compliance. Pagamentos a contas não cadastradas violam controles internos previstos em SOX, na LGPD (quando há vazamento associado) e em políticas antifraude. Auditoria externa costuma transformar isso em ponto de relatório.

Recuperação parcial, na melhor das hipóteses. Como o débito sai de forma autorizada — afinal, a empresa enviou o arquivo — a discussão com o banco vira longa. Bloqueio de valores via MED (Mecanismo Especial de Devolução do Pix) não se aplica a TED/DOC originadas em CNAB. Sobra ação cível, normalmente lenta.

Sinais de que algo está errado

Alguns indicadores que o time financeiro pode adotar sem depender só da TI:

• Divergência entre o relatório de remessa do ERP e o arquivo efetivamente enviado ao banco. Se você ainda não compara hash ou checksum desses arquivos, este é o momento.
• Aparição de favorecidos com CNPJ/CPF não cadastrados na base de fornecedores aprovados. Validação no retorno (.RET) é tão importante quanto na remessa.
• Pagamentos a contas em bancos digitais recém-abertos, especialmente quando o fornecedor histórico opera em outro banco há anos.
• Aumento de “ajustes manuais” de conciliação no fechamento. Esse é o ruído que costuma esconder o sinal.

O que dá para fazer hoje, sem reformar a infraestrutura

Não existe bala de prata, mas existem barreiras razoáveis:

Centralizar a geração do CNAB em servidor com acesso restrito, em vez de permitir que cada estação gere e mova arquivos localmente, reduz drasticamente a superfície de ataque. Assinar digitalmente o arquivo de remessa antes do envio ao banco, quando o canal permite, impede alteração silenciosa em trânsito. Reconciliar o arquivo enviado com o relatório do ERP usando hash (SHA-256, por exemplo) — e não só por totais — detecta substituições que mantêm a soma. Cruzar o .RET com a base de fornecedores aprovados, e não apenas com o .REM original, ajuda a flagrar trocas. E, talvez o mais subestimado: encerrar de vez a prática de circular arquivos CNAB por e-mail ou pasta compartilhada sem controle de versão.

O ponto que costuma escapar

CNAB é uma tecnologia da década de 80 que continua movimentando bilhões de reais por ano no Brasil. Atacantes profissionais sabem disso há muito tempo — a novidade aqui não é a vulnerabilidade, é o nível de especialização. O CNABHunter não é um malware genérico que tropeçou em um arquivo bancário; é uma peça desenhada para esse layout específico, nesse mercado específico.

A leitura para Fiscal, Financeiro e Controladoria é direta: a segurança do arquivo de remessa deixou de ser um detalhe operacional da TI. Passou a ser um controle interno, com impacto direto em conciliação, fechamento e auditoria. Ignorar isso é, na prática, terceirizar para a sorte uma parte relevante do caixa.

O fraudador estudou. Vale o time financeiro estudar também.

O post #CNABHunter: o malware que aprendeu CNAB antes de atacar apareceu primeiro em Motor Fiscal | Escrituração e Automação Fiscal NFe CTe NFSe NFTS.

O que é a Rejeição 656

A Rejeição 656 é um mecanismo de proteção dos servidores da SEFAZ. Quando um certificado digital ou endereço IP ultrapassa o limite de consultas permitidas em uma janela de tempo, a SEFAZ recusa as próximas requisições daquele emissor com o código 656 e a descrição “Rejeição: Consumo Indevido”.

O ponto importante: não é um erro da nota fiscal. É um rate limit. A nota provavelmente está correta — sua aplicação só está perguntando à SEFAZ com frequência demais.

Por que a SEFAZ aplica esse bloqueio

Os webservices da SEFAZ atendem milhões de empresas todos os dias. Um único emissor consultando o mesmo recibo em loop, ou disparando lote atrás de lote sem respeitar intervalos, consome capacidade que deveria ser distribuída entre todos os contribuintes. A Rejeição 656 garante que ninguém monopolize o serviço.

As regras estão formalizadas nas Notas Técnicas NT 2014.002 e NT 2018.002, e são aplicadas pela SEFAZ Virtual e pelas SEFAZ estaduais autorizadoras.

Quais são os limites técnicos

Os tetos publicados pela SEFAZ que disparam a rejeição 656 são, em resumo:

• 600 consultas a cada 5 minutos por certificado digital (limite global do emissor).
• 20 consultas por hora para o mesmo serviço de distribuição de DF-e.
• 10 consultas em 1 hora para a mesma chave de acesso.
• 40 consultas em 1 hora para o mesmo número de recibo (consulta de lote).
• O ultNSU (último número sequencial único) precisa ser informado em ordem crescente nas consultas de DF-e — repetir ou pular NSU também conta como consumo indevido.

Esses números podem variar levemente por UF, mas servem como referência segura para qualquer integração.

Causas mais comuns no dia a dia

Quase todos os casos de Rejeição 656 que vemos em produção caem em um destes padrões:

1. Loop de re-tentativa sem backoff. O sistema emissor recebe um timeout ou um retorno temporário e dispara nova consulta imediatamente, sem esperar. Em segundos, ultrapassa o limite.
2. Mais de um sistema usando o mesmo certificado. O ERP, um robô de captura de NF-e e um portal interno consultam a SEFAZ com o mesmo certificado ao mesmo tempo. Cada um respeita seu próprio limite, mas a SEFAZ enxerga a soma.
3. Processamento em lote sem janela. Mil notas autorizadas no mesmo minuto geram mil consultas de status na sequência — o pico estoura o limite de 5 minutos.
4. NSU repetido ou fora de ordem nas consultas de manifestação do destinatário (DF-e).
5. Consulta após o lote já ter retornado tudo. Continuar perguntando “tem mais?” depois que a SEFAZ já respondeu que não tem mais documentos.

Quanto tempo dura o bloqueio

O bloqueio é progressivo e funciona assim:

• Primeiro bloqueio: aproximadamente 60 minutos de espera, com desbloqueio automático.
• Tentativas durante o bloqueio: cada nova requisição feita enquanto o emissor está bloqueado reinicia o cronômetro. Tentar a cada 5 minutos durante o bloqueio é a maneira mais rápida de prolongá-lo.
• 50 bloqueios consecutivos: a SEFAZ pode aplicar bloqueio permanente do certificado/IP, exigindo contato direto com a UF autorizadora para liberação manual.

Em outras palavras: a pior coisa a fazer ao receber uma rejeição 656 é insistir.

Como resolver agora

Se você está vendo a Rejeição 656 neste momento:

1. Pare imediatamente as transmissões e consultas com o certificado afetado. Não retente.
2. Aguarde 60 minutos a partir da última tentativa. Use esse tempo para investigar a causa.
3. Verifique os logs da sua integração: existe alguma rotina em loop? Algum job agendado disparando a cada minuto?
4. Se houver mais de uma aplicação usando o mesmo certificado, desabilite as secundárias até identificar o ofensor.
5. Após o desbloqueio, volte a operar com cautela — comece com volume baixo e cresça gradualmente.

Se o bloqueio persistir mesmo após uma hora de inatividade, ou se houver suspeita de bloqueio permanente, abra contato com a SEFAZ da sua UF autorizadora.

Boas práticas para não cair de novo

Prevenir a Rejeição 656 é, antes de tudo, uma decisão de arquitetura. Os controles que mais funcionam:

• Centralize as requisições. Um único serviço deve falar com a SEFAZ. ERP, portal e captura devem consumir esse serviço internamente, não a SEFAZ diretamente.
• Implemente backoff exponencial. Em caso de falha, espere 30s, depois 1min, depois 2min, etc. Nunca retente em intervalo fixo curto.
• Respeite o tempo recomendado de consulta de recibo. A SEFAZ devolve no retorno do lote o tempo médio de resposta — use-o como base do setTimeout, não menos.
• Consulte o NSU em sequência e persista o último NSU consultado. Reiniciar a partir de zero a cada execução é uma armadilha clássica.
• Faça rodízio de certificados quando a operação for muito intensa, distribuindo a carga entre múltiplos certificados válidos.
• Monitore o consumo do certificado. Conte requisições por minuto e gere alerta quando passar de 80% do teto.
• Não compartilhe certificado entre setores sem coordenação. Quem usa, registra; quem não está usando, desconecta.

Como o Motor Fiscal trata o consumo indevido

No Motor Fiscal, todas as integrações com a SEFAZ passam por uma camada única de orquestração com rate limiting, backoff automático e rodízio de certificados quando aplicável. O resultado prático é que nossos clientes praticamente não enxergam a Rejeição 656 — quando ela chega, é tratada e absorvida pela camada de retry, sem virar erro de operação.

Se a sua empresa convive com bloqueios recorrentes da SEFAZ ou tem dificuldade em escalar a emissão de NF-e sem bater em limites, fale com nosso time — conseguimos diagnosticar a causa raiz em uma conversa rápida.

Fontes consultadas: documentação técnica da SEFAZ (NT 2014.002 e NT 2018.002).

O post Rejeição 656 – Consumo Indevido na NF-e: como identificar, resolver e prevenir apareceu primeiro em Motor Fiscal | Escrituração e Automação Fiscal NFe CTe NFSe NFTS.

O post NFS-e Nacional: por que sua nota pode demorar dias para aparecer no Portal Nacional apareceu primeiro em Motor Fiscal | Escrituração e Automação Fiscal NFe CTe NFSe NFTS.