NFC-e no balcão: a nota que vira errada quando o cliente toma crédito de ICMS

Desde 5 de outubro de 2026, quem vende no balcão a um cliente que vai aproveitar crédito de ICMS não pode mais fechar a venda com NFC-e. A regra parece de documento. Na prática, é de processo no caixa. O Ajuste SINIEF 23/26, celebrado pelo CONFAZ e pela Receita Federal em 3 de julho de 2026, com efeitos a partir de 5 de outubro de 2026, torna a NF-e, modelo 55, obrigatória em substituição à Nota Fiscal de Consumidor Eletrônica nas operações em que o adquirente aproveita crédito de ICMS.

Em varejo alimentar de proximidade, esse tipo de venda não é exceção.

O que o Ajuste SINIEF 23/26 muda, e desde quando

O texto do ajuste é direto: nas operações em que o destinatário é contribuinte e vai se aproveitar do crédito do ICMS da operação, a nota certa deixa de ser a NFC-e e passa a ser a NF-e modelo 55. A data de corte também é objetiva. O ajuste entra em vigor na publicação, mas produz efeitos a partir de 5 de outubro de 2026, o que significa que qualquer venda de balcão feita depois dessa data, para um cliente que toma crédito, tem documento fiscal errado se sair como NFC-e.

Redes de varejo alimentar de pequeno formato e alto giro, voltadas à compra frequente de vizinhança, vivem exatamente nessa fronteira. O público é misto: consumidor final que não aproveita crédito nenhum, ao lado de pequeno comerciante, restaurante, padaria ou food service que compra para revenda ou para insumo e quer, sim, o crédito de ICMS da compra. O mesmo caixa, no mesmo turno, atende os dois perfis de cliente, e a lei trata cada um de um jeito diferente a partir de agora.

Isso não é ajuste de layout de nota. É mudança na regra de decisão que roda, silenciosamente, toda vez que um operador de caixa bate "finalizar venda". Até 4 de outubro, a decisão era simples: venda de balcão para consumidor final, emite NFC-e, ponto final.

A partir de 5 de outubro, não é mais assim.

A mesma tela de PDV precisa responder a uma pergunta nova antes de decidir o modelo do documento: esse CNPJ vai tomar crédito dessa compra? E essa pergunta não tem uma resposta genérica, válida para toda venda do mesmo cliente, o que é exatamente o que complica o desenho técnico da regra.

Quando o adquirente aproveita crédito

A obrigatoriedade da NF-e não depende do porte do cliente nem de ele ter CNPJ. Depende de uma coisa só: se aquela operação específica dá direito a crédito de ICMS para quem compra. Um CNPJ pode comprar hoje para revenda, com direito a crédito, e amanhã comprar material de uso e consumo próprio, sem direito a crédito algum.

A mesma pessoa jurídica, duas operações, dois tratamentos fiscais diferentes, na mesma loja, no mesmo dia.

Isso descarta de saída a solução mais simples que qualquer gerente de loja pensaria primeiro: "todo CNPJ vira NF-e, todo CPF continua NFC-e". Essa regra erra em dois sentidos. Erra para cima quando o CNPJ compra sem direito a crédito e recebe uma NF-e desnecessária, que aumenta trabalho administrativo sem motivo fiscal. E erra para baixo quando o mesmo CNPJ, numa compra diferente, teria direito ao crédito e o sistema, por preguiça de regra, emite NFC-e do mesmo jeito. A variável que decide o modelo do documento não é quem compra. É o que a compra representa fiscalmente para quem compra.

Legislações estaduais ainda podem impor limites próprios sobre esse aproveitamento, o que significa que o desenho correto de regra não é só nacional: depende também do estado onde a loja opera. Uma rede com lojas em mais de uma unidade da federação pode descobrir que a mesma regra de decisão de documento precisa de variação por estado, não só por tipo de cliente. Um cadastro de cliente nacional, único, sem esse recorte estadual, carrega esse risco sem que ninguém tenha percebido ainda.

Onde o desenho quebra: PDV, SAP e cadastro de cliente

Na prática operacional, essa regra só funciona se três camadas conversarem entre si sem depender do operador de caixa decidir de cabeça. A primeira camada é o cadastro de cliente: o sistema precisa saber, antes da venda começar, se aquele CNPJ está habilitado a tomar crédito de ICMS nas condições daquela operação, não apenas se ele tem inscrição estadual ativa.

A segunda camada é o PDV em si. O terminal de venda precisa receber essa informação do cadastro e usar isso como critério de determinação de documento no momento do fechamento, não depois. Se o PDV não tem essa integração, a decisão vira manual, e decisão manual em ambiente de alto volume de transação é decisão que falha sob pressão de fila.

A terceira camada é o SAP, que recebe o resultado dessa decisão e precisa ter a determinação de tipo de documento parametrizada de forma coerente com a mesma regra usada no PDV. Se SAP e PDV usam critérios diferentes para a mesma pergunta, a divergência não aparece na hora da venda. Aparece no fechamento fiscal do mês, quando alguém tenta reconciliar o volume de NF-e emitido com o volume que deveria ter sido emitido segundo a regra do cadastro.

O mercado costuma chamar isso de "ajuste de parametrização fiscal", como se bastasse um campo a mais numa tela de configuração, mas o que está em jogo é desenho de fluxo de decisão distribuído em três sistemas diferentes, cada um com dono técnico diferente, operando em tempo real, sem tolerância a erro, porque o erro vira prejuízo imediato para o cliente, não para a empresa.

Um projeto que trata isso como parametrização pontual, sem revisar a integração entre as três camadas, entrega uma regra que funciona na homologação e falha na fila de caixa, exatamente onde o erro custa mais caro para a reputação da loja.

Ajuste SINIEF 13/26, CONFAZ: "Na hipótese em que o contribuinte opte pela emissão de uma NF-e nas operações previstas para emissão de uma NFC-e, o DANFE poderá ser impresso conforme o disposto no § 2º da cláusula décima do Ajuste SINIEF n° 19, de 9 de dezembro de 2016, caso em que será denominado" DANFE Simplificado Tipo 2.

O DANFE Simplificado Tipo 2 como saída operacional

Essa é a parte que resolve o problema prático de emitir NF-e num balcão de loja física, onde a operação está desenhada para a velocidade de uma NFC-e. O Ajuste SINIEF 13/26 permite que, quando o contribuinte opta por emitir NF-e numa operação que antes previa NFC-e, o documento auxiliar impresso no caixa seja o DANFE Simplificado Tipo 2, em vez do DANFE completo da NF-e tradicional.

Isso importa porque resolve uma objeção operacional óbvia: ninguém quer imprimir um documento auxiliar extenso no meio de uma fila de caixa de supermercado. O DANFE Simplificado existe justamente para manter a experiência de balcão rápida mesmo quando o documento de fundo mudou de NFC-e para NF-e. Mas essa saída só funciona se o PDV souber gerar esse layout específico, e isso é configuração que precisa ser testada antes, não descoberta na primeira reclamação de fila.

O ponto central aqui não é que existe solução. É que a solução, para funcionar, depende de três decisões técnicas encadeadas: identificar corretamente a operação com direito a crédito, emitir NF-e em vez de NFC-e, e imprimir o DANFE no formato certo para não travar a operação do caixa. Qualquer uma dessas três falhando quebra a cadeia inteira, e o cliente final é quem sente primeiro. Testar essa cadeia inteira, de ponta a ponta, antes de o primeiro cliente real passar pelo caixa, é o que separa um projeto fiscal bem desenhado de um projeto que descobre o próprio desenho em produção.

O que medir nas primeiras semanas

Existem indicadores objetivos que qualquer time fiscal ou de TI deveria acompanhar logo depois de 5 de outubro de 2026. O primeiro é o volume de NFC-e emitidas para CNPJ que, pelo cadastro, teriam direito a crédito de ICMS na operação. Esse número, se não for zero, mede exatamente o tamanho do vazamento de crédito que está indo parar no colo do cliente, não no relatório fiscal da loja.

O segundo indicador é o volume de NF-e emitidas desnecessariamente para operações sem direito a crédito, o custo invertido do mesmo problema: overhead administrativo sem ganho fiscal correspondente. O terceiro é o tempo médio de atendimento no caixa nas operações que migraram para NF-e com DANFE Simplificado, comparado ao tempo de uma NFC-e comum, porque esse é o indicador que primeiro aparece na reclamação do gerente de loja.

Um quarto ponto, menos visível, é a reconciliação entre o que o cadastro de cliente diz sobre direito a crédito e o que de fato foi emitido no PDV. Divergência recorrente aqui não é erro pontual de operador. É sinal de que a integração entre cadastro, PDV e SAP não está fechando como deveria, e cada venda discordante é um cliente que pode perder crédito sem saber, até o próprio contador dele reclamar. Um quinto indicador, útil para antecipar o problema antes da reclamação chegar, é o percentual de vendas de balcão com CNPJ identificado que ainda saem como NFC-e: esse número tende a cair rápido quando a regra está bem desenhada, e a permanecer estável, mês após mês, quando o problema é estrutural.

Quem decide o modelo, na hora da venda

A pergunta que normalmente fica sem dono formal é simples: na hora da venda, quem decide entre NFC-e e NF-e no PDV? O operador de caixa, uma regra automática vinda do cadastro do cliente, ou o SAP processando no fechamento do dia? Se a resposta for "o operador decide", a empresa está apostando que uma pessoa sob pressão de fila vai lembrar, caso a caso, de uma regra tributária nova, o que é expectativa, não controle.

Se a resposta for "o SAP corrige depois", o problema já aconteceu: o cliente saiu da loja com o documento errado e vai descobrir, só quando for lançar o crédito, que a nota não serve para isso. Nesse momento a reclamação não chega ao time fiscal da rede. Chega ao gerente da loja, que não tem ferramenta nenhuma para resolver um problema que nasceu de parametrização de sistema, não de atendimento.

A resposta certa não depende de pessoa.

Depende de regra automática, decidida no momento da venda, alimentada por um cadastro de cliente que sabe diferenciar operação com e sem direito a crédito, e testada antes de qualquer cliente real sentir o efeito. Quem não desenhou essa regra antes de 5 de outubro está descobrindo o desenho agora, reclamação por reclamação, no pior lugar possível para aprender: o balcão.

Na DFSpro, desenhamos a regra de emissão no fluxo que vai do PDV ao SAP, parametrizamos o leiaute de NF-e e NFC-e, incluindo o DANFE Simplificado Tipo 2, e provamos o comportamento do sistema em cenários de venda com e sem crédito antes de o cliente real passar pelo caixa. O Diagnóstico Fiscal SAP mapeia em que ponto exato do fluxo a escolha entre os dois modelos está sendo feita hoje, e se ela está certa, sem prometer resultado tributário que depende de decisão do próprio cliente.