Voltar para o blog

Rejeições fiscais

Rejeição 910: confira a chave da NFC-e substituta antes de reenviar o cancelamento

Se o cancelamento por substituição voltou com 910, confira a chave do documento indicado como substituto. A resposta informa uma identificação inválida dentro dessa chave. Nesse fluxo, foi rejeitado o pedido de cancelamento; isso não significa que a venda ficou sem documento fiscal. Consulte as duas notas antes de…

Blog ALRA
Capa ilustrada da ALRA: Rejeição 910: confira a chave da NFC-e substituta antes de reenviar o cancelamento.

Se o cancelamento por substituição voltou com 910, confira a chave do documento indicado como substituto. A resposta informa uma identificação inválida dentro dessa chave. Nesse fluxo, foi rejeitado o pedido de cancelamento; isso não significa que a venda ficou sem documento fiscal. Consulte as duas notas antes de decidir por outra emissão.

A mensagem é Rejeição: Chave de Acesso NF-e Substituta inválida (<nome do campo>). O complemento pode indicar Dígito, Código UF, Ano, Mês, CNPJ/CPF, Modelo ou Número. Guarde o texto completo: registrar apenas “erro 910” elimina a informação que direciona a conferência.

Identifique o evento e os dois documentos

Este artigo trata do evento 110112, enviado ao serviço NFeRecepcaoEvento, no cancelamento por substituição de NFC-e, modelo 65. A nota a cancelar é identificada em infEvento/chNFe; a substituta aparece em infEvento/detEvento/chNFeRef. São campos com funções diferentes.

O cenário documentado envolve uma NFC-e normal sem resposta imediata, seguida de outra em contingência para a mesma operação. Depois, descobre-se que a primeira também foi autorizada. O procedimento busca cancelar o documento duplicado que não acobertou a operação, referenciando aquele que efetivamente a documentou. Não serve como autorização geral para corrigir qualquer cupom mediante nova emissão.

Embora uma validação estrutural aceite os modelos 55 e 65 na chave, isso não estabelece permissão para usar esse procedimento com NF-e 55. O MOC, seção 5.9, caracteriza o cancelamento por substituição como específico de NFC-e. Também é necessário distinguir homologação e produção: um resultado de teste não altera a situação fiscal real.

O que a rejeição verifica

As regras P31-10 a P31-34 verificam a chave substituta quando tpEvento=110112. O conjunto contempla dígito verificador inválido, código de UF inválido, ano inferior a 2006 ou posterior ao corrente, mês fora de 1 a 12, CNPJ/CPF zerado ou com dígito inválido, modelo diferente de 55/65 e número fiscal igual a zero.

O complemento CNPJ/CPF diz respeito à identificação contida na chave. Não indica automaticamente erro no cadastro do consumidor, no CNPJ do contador ou no certificado de transmissão. Localize primeiro o dado realmente analisado. Alterar outros cadastros por tentativa pode deixar a causa intacta.

A comparação entre as duas notas pertence à família 911. Existência, situação e conteúdo da substituta têm outras verificações. Uma chave estruturalmente válida, portanto, ainda pode ser inadequada para a operação.

Preserve os 44 caracteres e a interpretação atual

Recupere a chave integral do XML da substituta. São 44 caracteres, preservados exatamente como no documento fiscal. A NT 2026.004 v1.01 alterou os campos de CNPJ e chave para admitir conteúdo alfanumérico; a página 13 inclui expressamente chNFeRef. Não remova letras válidas, complete posições por conta própria ou converta a chave para um número em planilha ou integração.

A mesma NT apresenta homologação até 15/06/2026 e produção em 01/07/2026. São datas documentais de adequação do leiaute, sem comprovação de funcionamento do emissor ou autorizador de um cliente. Se uma rotina ainda exige somente dígitos, o suporte deve confrontar sua versão com o leiaute aplicável.

Na P31-26, a NT 2026.001 PAA v1.02b identifica CNPJ nas séries 0–909 e 980–989; nas demais, CPF. Para NFF, tpEmis=3, existe critério próprio: quinto dígito de nNF igual a 1 para CNPJ ou 2 para CPF. Isso orienta a interpretação da chave existente, sem permitir alterar série, número ou identidade do emitente.

O cronograma PAA distingue homologação em 03/08/2026 e produção em 05/10/2026. Essas regras não autorizam PAA em NFC-e nem ampliam, sozinhas, o cabimento legal do evento para NF-e 55. O fluxo PAA documentado é modelo 55, procEmi=4, na SVRS.

Confira o prazo da UF

O Ajuste SINIEF 19/16, cláusula décima quinta-A, prevê até 168 horas contadas da autorização, permitindo redução estadual. A SEF/MG confirma esse prazo para a duplicidade descrita em sua orientação consultada em 16/10/2026. Essa confirmação é de Minas Gerais; não comprova a mesma condição para todas as UFs.

O Ajuste também admite tratamentos excepcionais a critério estadual. Não presuma que um pedido fora do prazo será aceito: confirme a regra aplicável com o responsável fiscal e a SEFAZ. A orientação mineira consultada não oferece cancelamento extemporâneo automático. Prazo e cabimento continuam necessários mesmo depois de corrigir a chave.

Faça a conferência antes de reenviar

Preserve o XML do evento, o retorno completo, os XMLs das duas NFC-e e seus protocolos, além do ambiente, autorizador e horários. Identifique qual documento deve ser cancelado e qual deve permanecer associado à venda. Verifique se existe uma fila repetindo o mesmo pedido.

Compare chNFeRef com a chave do XML correto, caractere por caractere. Confira também estabelecimento e operação. Se a tela mostra uma chave e o arquivo enviado contém outra, investigue seleção do documento, importação, armazenamento e montagem do evento. A correção deve ocorrer no emissor que gera e assina a solicitação; não altere diretamente um arquivo já assinado.

Se houve erro de cópia, selecione novamente o documento correto, quando o sistema permitir, e confira o novo XML. Se houve corte ou conversão indevida na integração, corrija a origem e preserve os arquivos anteriores para comparação. Se não existe substituta correspondente, suspenda o pedido e encaminhe o caso ao responsável fiscal; emitir outra nota apenas para preencher o campo pode aumentar a duplicidade.

Exemplo e confirmação do resultado

Uma loja vende R$ 148, transmite a NFC-e normal e não recebe resposta. Emite outra em contingência e posteriormente verifica que ambas foram autorizadas. Ao preparar o cancelamento da primeira, a integração troca um caractere da chave substituta, mantendo o tamanho; o retorno aponta 910 por Dígito.

O suporte compara o evento com o XML preservado e corrige o transporte da chave. Não muda a venda, não recalcula uma chave artificial e não cria uma terceira nota. O pedido regenerado ainda precisa atender às demais regras.

Para encerrar, leia o resultado individual do evento, preserve o protocolo e consulte a situação da nota que deveria ser cancelada. Confira o vínculo da substituta e a conciliação de caixa, estoque e escrituração. O simples desaparecimento do 910 não prova cancelamento. Persistindo divergência entre tela e XML, acione o suporte; havendo dúvida sobre prazo ou enquadramento, envolva o responsável fiscal e a SEFAZ.

Fontes

Pesquisa e redação por IA em 16/10/2026, com novas capturas oficiais e práticas e reuso identificado de documentos obtidos em 15/10. Não houve teste de emissão ou de cancelamento.

  • NT 2018.004 v1.00, páginas 2–5, 8–10 e 12; MOC 7.0, Visão Geral, seção 5.9, páginas 105–108.

  • NT 2026.001 PAA v1.02b, páginas 3, 12 e 17; NT 2026.004 v1.01, páginas 3, 4, 10 e 13. Riscos e tabelas foram conferidos nos PNGs documentais existentes pertinentes.

  • Ajuste SINIEF 19/16, cláusulas décima segunda e décima quinta-A; SEF/MG, perguntas sobre cancelamento.

  • Schemas oficiais: pacote específico de 2018 e pacote de eventos da adequação alfanumérica comparados. O pacote antigo mantém padrão numérico; o novo leiaute genérico não valida sozinho o detalhe específico. Nenhum XML real foi validado nesta pesquisa.

  • Corpos específicos confrontados: InvoiSys, Berga e Buscador NCM. Foram descartadas a correção artificial da chave, a substituição como correção geral de cupom e a confusão entre rejeição do evento e da autorização. O Buscador é ficha curta, não tutorial operacional. NDD retornou HTTP 404 e falha de abertura WEB; seu resultado de busca não foi contado como quarto corpo aberto.

Os arquivos, hashes, atos de leitura e limites estão em fontes.v3.json. Não foram verificadas telas ou rotinas específicas do ALRA, habilitação individual ou implantação em cada autorizador.

Pronto para dar o próximo passo?

Pronto para organizar sua empresa e ganhar mais tempo?

Teste grátis por 15 dias e descubra como a Alra pode transformar a gestão do seu negócio.