Rejeição 917: confira a identificação do cliente nas NFC-e relacionadas

Se o cancelamento por substituição retornou 917, verifique a identificação do destinatário nas duas notas autorizadas. O problema pode estar na seleção da substituta ou em uma diferença de identificação registrada na emissão. Alterar o cadastro atual do cliente, sem conferir os XML, não esclarece o que foi comparado.

A mensagem documentada é “Rejeição: Identificação do destinatário da NF-e Substituta difere da identificação do destinatário da NF-e a ser cancelada.”. A regra 5P31-32 da NT 2018.004 v1.00 começa com uma condição: o destinatário foi identificado na nota original por CNPJ, CPF ou identificador estrangeiro. A partir dela, confronta a identificação nas duas notas, incluindo a inscrição estadual indicada na regra.

Qual evento e qual documento estão envolvidos

Este artigo trata do Registro de Evento, com tpEvento=110112, cancelamento por substituição. Esse serviço não é a autorização de uma nova nota nem o cancelamento comum, evento 110111. Uma rejeição do pedido não comprova que o documento já autorizado foi cancelado.

A página 3 da NT delimita inicialmente o evento à NFC-e, modelo 65. A legislação consultada mantém esse contexto; a expressão NF-e na mensagem não autoriza ampliar a substituição ao modelo 55. Confirme UF, autorizador e ambiente do caso.

O cenário histórico é uma duplicidade da mesma operação. A primeira emissão fica sem resposta para o estabelecimento; outra NFC-e é emitida em contingência. Mais tarde, constata-se que ambas foram autorizadas. A substituição pretende regularizar essa duplicidade, mantendo o documento que acobertou a operação.

No pedido, chNFe aponta a nota a cancelar e chNFeRef, a substituta. O nProt da entrada é o protocolo de autorização da nota a cancelar. Compare essas informações com os arquivos preservados antes de discutir qualquer alteração cadastral.

O que conferir na identificação

Na página 11, a 5P31-32 menciona CNPJ, CPF ou identificador estrangeiro na condição inicial e inclui a IE no confronto da identificação. Não reduza a análise ao nome impresso do cliente. Pessoas diferentes podem ter nomes semelhantes, e uma integração pode apresentar o mesmo nome enquanto transmite identificadores distintos.

Confira qual tipo de identificação consta em cada XML e o valor efetivamente registrado. Um CPF e um CNPJ não se tornam equivalentes apenas porque o comprador afirma representar uma empresa. Da mesma forma, um identificador estrangeiro não deve ser substituído por CPF inventado. A informação precisa corresponder ao destinatário real e ao documento emitido.

A IE mencionada é a identificação estadual do destinatário no confronto entre as notas. Não a confunda com o CNPJ do estabelecimento emitente ou com os dados do autor do evento. Se a diferença envolver presença, ausência ou conteúdo da IE, peça análise dos arquivos e da situação fiscal real; não preencha qualquer número para obter coincidência.

O MOC 7.0 — Visão Geral, página 109, reproduz a comparação da 5P31-32 sem repetir a condição inicial de identificação da original que consta da NT. Preserve essa diferença documental. Ela não permite concluir, por simples ausência de identificação, que um pedido será aceito. Se esse for o caso, apresente os arquivos e a divergência ao autorizador, sem alterar documentos.

Presença e ausência não são um atalho

Quando a original contém identificação e a substituta não reproduz esses dados, investigue o que foi enviado. Pode haver documento selecionado errado, informação perdida na geração ou divergência já existente na emissão. A regra lida não justifica retirar a identificação da nota original para evitar a comparação.

Se a original não tiver CNPJ, CPF ou identificador estrangeiro, registre essa constatação separadamente. A condição inicial da 5P31-32 precisa ser respeitada na análise. Isso não dispensa outras validações nem define, sozinho, se aquela operação poderia ser documentada sem identificar o cliente. Não transforme a ausência de dados em orientação geral de emissão.

Como diagnosticar e tratar cada cenário

A substituta pertence a outro cliente

Confira as chaves do evento e o histórico das vendas. Notas emitidas próximas no tempo, com produtos ou valores iguais, podem ter sido associadas incorretamente. Localize o documento que realmente acobertou a operação duplicada e comprove o vínculo.

Depois dessa conferência, o suporte pode ajustar a seleção no emissor e gerar o pedido apropriado. Não escolha outra nota apenas porque ela contém o mesmo CPF ou CNPJ: identidade do destinatário também não prova, sozinha, identidade da operação.

A operação é a mesma, mas os identificadores autorizados diferem

Preserve os dois XML, seus protocolos e o pedido rejeitado. Verifique com o responsável fiscal qual informação corresponde ao comprador real e qual procedimento de regularização é cabível. Uma digitação equivocada ou um cadastro trocado são hipóteses a comprovar, não conclusões automáticas do 917.

Não edite XML autorizado, não mude o cliente ficticiamente e não emita outra nota somente para criar identificação coincidente. Atualizar o cadastro pode prevenir novos erros, mas não modifica o conteúdo já autorizado das notas existentes.

A tela está certa, mas o arquivo mostra outro destinatário

Compare o cadastro atual com o XML efetivamente autorizado, não apenas com uma prévia recalculada. Uma importação ou sincronização pode ter associado o registro errado. O suporte deve identificar a origem da informação e conferir se a resposta analisada pertence às mesmas chaves e ao mesmo evento.

Se os arquivos preservados coincidirem e o retorno continuar sem explicação, interrompa tentativas repetidas e encaminhe o conjunto de evidências. Não atribua a diferença à SEFAZ antes de conferir associação, ambiente e dados transmitidos.

Exemplo hipotético

Uma loja de presentes possui duas vendas de R$ 120,00 no mesmo dia. Ao regularizar uma duplicidade de uma delas, o sistema referencia por engano uma NFC-e da outra venda. A original identifica a cliente fictícia Ana por CPF; a substituta selecionada identifica a cliente fictícia Beatriz por outro CPF.

O pedido retorna 917. A equipe compara as chaves e percebe a seleção incorreta. Localiza a nota que realmente acobertou a venda de Ana e confere as demais condições antes de gerar outro pedido. Não troca o CPF de Beatriz nem usa a igualdade dos valores como prova de correspondência.

Verificação do resultado e limites documentais

Na especificação, tpAmb=1 identifica produção e 2, homologação; cOrgao e cOrgaoAutor correspondem à UF pertinente. A original é normal, tpEmis=1, e a substituta, contingência 9, conforme P12-48. A 5P31-20 verifica emissão da substituta mais de duas horas posterior à original. Isso é diferente do prazo histórico de até 168 horas desde a autorização para pedir cancelamento, sujeito a ressalvas estaduais.

A cláusula décima quinta-A do Ajuste SINIEF 19/16, consultada em 16/10/2026, mantém o fluxo para NFC-e em contingência que acobertou a mesma operação. O prazo do pedido é de até 168 horas desde a autorização, podendo a UF reduzi-lo; tratamento excepcional depende da administração estadual. A FAQ mineira confirma a duplicidade e o prazo, e orienta atendimento administrativo na perda de prazo. Isso não garante aceitação individual nem se estende automaticamente às outras UFs.

Após tratamento fundamentado, confira a resposta individual do evento, chave e protocolo. O código 128 indica processamento do lote; sozinho, não confirma cancelamento. A fonte relaciona 135 ao registro e vínculo do evento. Confirme também a situação fiscal do documento. Acione o suporte para associação ou arquivos inconsistentes e o responsável fiscal para divergência real de destinatário ou regularização.

Fontes

• NT 2018.004 v1.00: PDF recapturado em 16/10/2026, reutilizado por hash; páginas 3–6, 8 e 11 lidas nesta sequência. Imagem documental preexistente da página 11 realmente inspecionada na preparação 912–914 e reutilizada, sem novo render.

• MOC 7 — Visão Geral, páginas 108–109: regras do evento; captura de 15/10/2026 identificada e reutilizada. A diferença de redação da 917 não foi normalizada silenciosamente.

• MOC 7 — Anexo I, páginas 17–19: det, atributo nItem, qCom e qTrib. Declarações selecionadas do schema 010f e seus ancestrais foram conferidos; não houve compilação ou teste de XML.

• Ajuste SINIEF 19/16, cláusula décima quinta-A, e FAQ de Minas Gerais, perguntas 1–4: capturas de 16/10/2026 e leituras reais reutilizadas da sequência 912–914. Não certificam aceitação individual.

• Apoio invoisys917: corpo específico efetivamente lido em 16/10/2026; sugestões de reemissão, devolução ou reutilização de número não foram adotadas como soluções automáticas.

• Apoio berga917: corpo específico efetivamente lido em 16/10/2026; sugestões de reemissão, devolução ou reutilização de número não foram adotadas como soluções automáticas.

• Apoio buscador917: corpo específico efetivamente lido em 16/10/2026; sugestões de reemissão, devolução ou reutilização de número não foram adotadas como soluções automáticas.

• fontes.v2.json preserva proveniência e limites. Sem imagem nova, emissão de teste ou publicação. Três corpos lidos não equivalem a três receitas integralmente válidas; menus e garantias dos editores não foram atribuídos ao ALRA.