Voltar para o blog

Rejeições fiscais

Rejeição 953: tipo de emissão inválido na chave referenciada

A rejeição 953 pode ocorrer quando uma NF-e informa uma referência cujo tipo de emissão não atende à regra aplicável. O primeiro cuidado é ler a mensagem completa: o código também aparece em documentação antiga associado a ECF e CFOP 5.929. Essa descrição histórica não deve conduzir a correção de um retorno sobre…

Blog ALRA
Capa ilustrada da ALRA: Rejeição 953: tipo de emissão inválido na chave referenciada.

A rejeição 953 pode ocorrer quando uma NF-e informa uma referência cujo tipo de emissão não atende à regra aplicável. O primeiro cuidado é ler a mensagem completa: o código também aparece em documentação antiga associado a ECF e CFOP 5.929. Essa descrição histórica não deve conduzir a correção de um retorno sobre chave de acesso.

Para a mensagem “Chave de Acesso referenciada com tipo de emissão inválido [nOcor:nnn]”, confira o documento referenciado e a informação que efetivamente foi transmitida. Trocar o tipo de emissão da nota atual não corrige, por si, a chave do documento anterior. Tampouco é correto substituir um dígito da referência por um número aceito apenas para eliminar a rejeição.

Dois campos que exigem conferências distintas

A NT 2022.003 v1.11 descreve duas regras, ambas para a nota atual modelo 55, classificadas como facultativas. Na BA02-60, página 9, há uma referência em refNFe, o modelo contido na chave é 55 ou 65 e seu mês/ano é posterior a abril de 2011. Nessas condições, ocorre 953 se o tipo de emissão da chave for diferente de 1, 2, 3, 4, 5, 6, 7 ou 9.

Na BA02a-110, página 10, o campo examinado é refNFeSig: referência com código numérico zerado. A regra também considera mês/ano posterior a abril de 2011 e a mesma lista de tipos de emissão. Não acrescente a ela condições de outra linha nem ignore as demais validações desse campo.

O corte é estrito: abril de 2011 não significa “posterior a abril”. Isso delimita essas validações; não demonstra que uma referência mais antiga será aceita. Existência, modelo, finalidade, integridade e pertinência documental continuam sujeitos às regras correspondentes. O complemento nOcor identifica a ocorrência da referência, não o item do produto.

O que a lista de números não permite concluir

A lista é um teste sobre a chave referenciada. Ela não oferece livre escolha da modalidade de emissão, não autoriza uma contingência hoje indisponível e não dispensa condições próprias do documento original. Também não amplia essas duas regras para uma NFC-e atual só porque a referência pode conter o modelo 65.

Rótulos antigos como SCAN e DPEC aparecem em tutoriais, mas não são um catálogo atual para configurar o emissor. A NT 2026.002 v1.11 atualiza o domínio de emissão, inclusive com o regime NFF e a emissão offline da NF-e com DANFE Simplificado Tipo 2. Para resolver 953, preserve a modalidade verdadeira do documento anterior; não converta sua emissão em “normal” por conveniência.

refNFeSig também não é um recurso para esconder uma chave inválida. Seu código numérico zerado tem finalidade documental específica e condições próprias de uso. Código numérico e tipo de emissão são componentes diferentes. Não zere o tipo de emissão, não substitua refNFe por refNFeSig para contornar a mensagem e não aplique esse campo indiscriminadamente a devoluções ou complementações.

Conferência prática antes de reenviar

Guarde o retorno completo, ambiente, UF, autorizador, horário e XML transmitido. Localize a ocorrência indicada e identifique se a integração usou refNFe ou refNFeSig. Se houver diversas referências, confira cada associação com seu documento de origem; não exclua todas para simplificar o envio.

Recupere o XML autorizado ou outra fonte documental confiável do documento anterior. Compare a referência inteira com a origem, observando modelo, ano/mês e tipo de emissão. Um número salvo no cadastro, uma cópia digitada ou uma conversão de planilha pode ter sido alterado antes da montagem do XML. A configuração exibida hoje na tela não comprova qual valor foi enviado.

Se for identificada falha de importação ou digitação, corrija o vínculo e a rotina que o produz. Regenere a nota rejeitada a partir dos dados corretos e compare novamente o arquivo. Preserve o XML autorizado do documento anterior: não o edite, não recalcule sua chave para acomodar uma mudança e não solicite sua reemissão automaticamente.

Quando a referência íntegra aparentar atender às condições, encaminhe ao suporte os dois documentos, a ocorrência e o retorno. Peça confirmação do campo, versão e aplicação da regra pelo autorizador. Não conclua, apenas pelo código, que o fornecedor emitiu uma nota errada ou que a SEFAZ falhou.

Exemplo sem fabricação de chave

Uma empresa prepara uma NF-e modelo 55 e relaciona uma nota anterior de setembro de 2026. A integração importou incorretamente o componente do tipo de emissão como 8. O retorno identifica a referência correspondente com 953.

A equipe consulta o documento original e verifica que a chave registrada na integração não corresponde àquela efetivamente autorizada. Corrige a importação e recupera a referência íntegra. Não escolhe o número 1 por ser comum nem altera a modalidade da nota atual. O exemplo não fornece uma chave fiscal artificial e não pressupõe que qualquer outro tipo seja válido para aquela operação.

Antes do reenvio, a empresa confirma que o documento anterior é pertinente à operação e que o campo escolhido pode ser usado. Depois, lê a resposta nova. O desaparecimento de 953 não equivale a autorização; outras verificações podem produzir outro resultado.

Mensagem antiga, calendário e aplicação estadual

A NT 2022.003 v1.11 explica, na seção 2.3.6, a exclusão da I08-186 e o reaproveitamento do código. Na NT 2026.002 v1.11, a I08-186 novamente consta na lista de regras removidas e sua linha sobre ECF está riscada. Não trate esse texto como validação vigente nem altere CFOP para corrigir a 953 de chave referenciada.

O adiamento para 14/12/2026 nessa NT alcança I08-180, BA02-35 e VC02-40. Não é uma nova data para BA02-60 ou BA02a-110. O cronograma documental da NT 2022.003 registra homologação em 07/02/2023 e produção em 03/04/2023, sem substituir a confirmação de aplicação estadual.

Na página paulista consultada em 16/10/2026, BA02-60 e BA02A-110 aparecem como ativadas com a NT 2022.003. Essa publicação é evidência de orientação de São Paulo, não teste de processamento em homologação ou produção, nem prova de ativação em todas as UFs. Se a resposta mencionar o antigo cenário ECF, encaminhe a mensagem literal e a versão ao suporte para desambiguação.

Fontes

Conferência em 16/10/2026. NT 2022.003 v1.11, páginas 3–7 e 9–11: condições de BA02-60/BA02a-110, campos e exclusão de I08-186; PDF compartilhado capturado hoje às 03:46 em Brasília. NT 2026.002 v1.11, páginas 3, 7, 9, 12 e 18; texto e PNG preexistente da página 12 conferidos, sem novo render. SEFAZ-SP, regras facultativas, linhas das duas regras, captura nova.

Três apoios específicos com corpos HTTP200 efetivamente lidos: Oobj, Omie e Webmania. Omissões do corte temporal, rótulos antigos, extensão indevida ao modelo 65 atual, exemplos XML e recomendações de mudar ou reemitir a referência não prevalecem sobre a primária. Menus desses produtos não são instruções do ALRA. Sem execução fiscal ou teste de implantação individual.

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.