NF-e e NFC-e
Rejeição 977 e a atualização do identificador CSRT revogado
A rejeição 977 indica que o identificador do CSRT enviado na NF-e está revogado. A correção exige verificar qual credencial ativa deve ser utilizada e atualizar o emissor com o identificador correspondente. Recalcular o hash com a mesma credencial revogada não resolve esse retorno.
A rejeição 977 indica que o identificador do CSRT enviado na NF-e está revogado. A correção exige verificar qual credencial ativa deve ser utilizada e atualizar o emissor com o identificador correspondente. Recalcular o hash com a mesma credencial revogada não resolve esse retorno.
Mensagem: “Rejeição: Identificador do CSRT revogado”.
O campo verificado é idCSRT, dentro de infNFe/infRespTec. Ele identifica o Código de Segurança do Responsável Técnico usado na geração do hash; não contém o segredo em si. O diagnóstico deve envolver o fornecedor ou a equipe responsável pelo sistema de emissão. NT 2018.005 v1.52, páginas 8, 20 e 24.
Onde a regra está documentada
A regra 7ZD08-20 tem aplicação documentada no Paraná para a NF-e, modelo 55. A NT informa 16 de setembro de 2024 em homologação e 1º de outubro de 2024 em produção para a validação dos campos informados. O modelo 65 permanece como implementação futura. Também estão excepcionadas a NFF, com tpEmis igual a 3, e a SVC, com tpEmis igual a 7 ou 8.
A observação antiga sobre implantação genérica por UF e futura na SVC está riscada na v1.52. Ler somente o texto extraído do PDF pode ocultar essa supressão. O alcance atual deve ser estabelecido pelas observações específicas que permaneceram na regra.
Esse enquadramento não deve ser ampliado automaticamente para todo o Brasil. Minas Gerais registra 977 como não validada em sua tabela versão 2.00; São Paulo informa situação inativa nas tabelas de NF-e e NFC-e. Essas situações locais também não desativam a regra paranaense. Tabela MG, página 6, SP NF-e e SP NFC-e.
Por que existem datas diferentes para o CSRT
A validação de um identificador enviado é diferente da obrigação de preencher os campos. O Boletim paranaense 005/2026 fixou a obrigatoriedade do CSRT na NF-e em produção desde 1º de abril de 2026. Essa determinação posterior atualiza o prazo de presença obrigatória; não significa que a verificação de identificadores revogados tenha começado somente nessa data. Boletim PR 005/2026.
Por isso, um XML que já informava idCSRT podia ser rejeitado antes da obrigação geral de preenchimento no cenário paranaense. Depois da exigência, retirar idCSRT e hashCSRT para contornar a 977 pode gerar a rejeição 975. Desativar uma validação no programa tampouco muda a conferência feita pela SEFAZ.
O que revogado significa neste diagnóstico
O retorno direciona a investigação ao estado do identificador transmitido. Ele não informa, sozinho, quem solicitou a revogação ou por qual motivo ela ocorreu. Não conclua que houve vazamento, fraude, vencimento do certificado digital ou bloqueio do contribuinte apenas pela mensagem 977.
A orientação do SAC da Receita Estadual do Paraná, pergunta 2565, é utilizar um identificador em situação ativa. A página também indica a consulta de tokens ativos na área restrita Receita/PR, no serviço UPD, Sistema, CSRT. Essa consulta deve ser feita por quem possui acesso autorizado, sem compartilhar senha ou segredo em chamados.
Antes de solicitar outra credencial, o fornecedor precisa verificar se já existe uma ativa adequada. A existência de uma nova credencial não comprova que todas as instalações receberam a atualização. Uma estação, serviço de integração ou processo de transmissão pode continuar preenchendo o identificador anterior.
Como corrigir com rastreabilidade
Preserve o retorno individual com cStat, xMotivo, horário, ambiente, modelo e UF. Confirme que o código veio da autorização da NF-e.
Localize idCSRT no XML efetivamente enviado. Compare-o com a configuração usada pelo componente que gerou o documento, não apenas com a tela atualmente aberta.
Peça ao fornecedor que confira o estado desse identificador no cadastro correspondente. Registre a conclusão da consulta, sem anexar a credencial secreta.
Identifique a configuração correta para o ambiente de emissão. Um teste em homologação não comprova que a produção utiliza os mesmos parâmetros.
Atualize o identificador e a referência ao segredo correspondente pelo procedimento suportado pelo sistema. Não troque apenas um deles deixando o outro associado à credencial anterior.
Gere novamente o hash para a chave da NF-e que será transmitida, conclua a assinatura e reenvie pelo fluxo normal do emissor.
Verifique o novo retorno individual e registre o resultado. Uma mudança para outro código exige diagnóstico próprio; não comprova autorização.
A SuperSoft orienta envolver o desenvolvedor e conferir a atualização do sistema. A InvoiSys destaca a identificação do CSRT válido. Já a Berga chama atenção para instalações com identificador desatualizado. São referências práticas; o escopo e as datas devem seguir as fontes oficiais atuais.
Exemplo de investigação sem expor credenciais
Considere duas instalações do mesmo emissor: uma transmite normalmente e outra recebe 977 após uma atualização. Isso sugere comparar versões e parâmetros, mas ainda não prova a causa. Primeiro, verifique se os documentos pertencem ao mesmo ambiente e contexto cadastral. Depois, compare os identificadores efetivamente enviados e a configuração carregada por cada processo.
Se o processo que falha continua usando o identificador revogado, corrija sua configuração e gere novamente o XML da NF-e rejeitada pelo emissor. Não copie o hash da nota que funcionou: o cálculo depende também da chave de acesso de cada nota. Nenhum operador precisa receber o segredo para realizar essa comparação inicial.
Como separar os retornos relacionados
A 976 aponta identificador não cadastrado; a 977 aponta identificador revogado; a 978 aponta divergência do hash. A 975 trata da ausência das informações exigidas. Portanto, renovar certificado, alterar destinatário ou mudar tributação sem outra evidência não é uma correção dirigida à 977.
Na prevenção, mantenha responsáveis pela atualização, inventário das instalações e registro de quando cada configuração entrou em uso. Evite tentativas automáticas contínuas com o mesmo XML rejeitado. O atendimento termina com a causa esclarecida e o resultado da transmissão verificado, preservando o sigilo do CSRT durante todo o processo.