Rejeição 976: como verificar o identificador do CSRT na SEFAZ

A rejeição 976 informa que o identificador do CSRT enviado no XML não está cadastrado na SEFAZ. Para corrigir, o fornecedor do sistema precisa conferir o identificador utilizado, seu cadastro e os vínculos pertinentes ao emitente. Recalcular o hash, sozinho, não resolve a ausência de cadastro do identificador.

Mensagem: “Rejeição: Identificador do CSRT não cadastrado na SEFAZ”.

O campo investigado é infRespTec/idCSRT. Ele identifica a credencial usada pelo responsável técnico; o segredo CSRT não é transmitido nesse campo. O XML contém o identificador e o hash calculado, enquanto a credencial deve permanecer protegida. NT 2018.005 v1.52, seções 2 e 3.7.

Alcance da regra e datas documentadas

A regra 7ZD08-10 tem aplicação documentada no Paraná para a NF-e, modelo 55. A NT informa homologação em 16 de setembro de 2024 e produção em 1º de outubro de 2024 para a validação dos campos informados. O modelo 65 permanece como implementação futura, e NFF, tpEmis igual a 3, e SVC, tpEmis igual a 7 ou 8, estão excepcionadas. NT, páginas 8 e 24.

A observação antiga de implementação genérica a critério das UFs está riscada na v1.52. Por isso, não se deve apresentar a 976 como ativa em qualquer estado apenas porque ele possui cadastro de software. Minas Gerais marca a regra como não validada na tabela versão 2.00; São Paulo registra situação inativa nos modelos 55/65. Tabela MG, SP NF-e, SP NFC-e.

Essas fontes delimitam a orientação documental, sem comprovar por teste a configuração de todos os autorizadores. Um retorno fora desse cenário exige conferir o serviço utilizado e a evidência estadual correspondente.

Obrigação de informar e validação são diferentes

O Paraná tornou obrigatório o CSRT na NF-e em produção desde 1º de abril de 2026, por meio do Boletim 005/2026. Esse prazo posterior não apagou as validações previstas desde 2024 para os campos que já eram enviados. Boletim PR 005/2026.

Isso explica por que um sistema podia receber a 976 mesmo antes do início da obrigação de preenchimento. Quando optava por enviar o identificador, ele precisava ser reconhecido pelo autorizador. Hoje, no escopo paranaense sujeito à obrigação, retirar idCSRT e hashCSRT não é uma solução adequada: a ausência pode levar à rejeição 975.

Guarde essa distinção ao consultar um tutorial antigo. Uma orientação para deixar os campos vazios durante um período de transição não pode ser aplicada indefinidamente depois da entrada em vigor da exigência.

O que deve ser conferido primeiro

Comece pelo XML realmente transmitido. Compare o idCSRT presente no arquivo com a configuração mantida pelo fornecedor. Verifique também o CNPJ do responsável em infRespTec e a identificação do estabelecimento emitente.

O identificador possui campo de duas posições numéricas no leiaute. Ele não é a longa sequência secreta do CSRT, o CNPJ do desenvolvedor ou o CSC da NFC-e. Preencher um número arbitrário apenas para atender ao tamanho do campo pode superar uma checagem estrutural e continuar falhando no cadastro. NT, página 20.

Uma configuração pode estar correta em uma instância e desatualizada em outra. Investigue diferenças entre filiais, serviços de transmissão, versões e ambientes. Não presuma que um resultado de homologação comprova o cadastro ou o comportamento da produção.

Cadastro do fornecedor e vínculo do emitente

Além de verificar o identificador, confirme se o processo de autorização de uso do sistema foi concluído para aquele emitente. A existência de um pedido ou de um protocolo de solicitação não demonstra, por si só, que todas as etapas foram finalizadas.

A documentação da Sankhya relaciona ocorrências da 976 a pedidos de autorização ainda pendentes no Paraná. A TOTVS, para a linha RM, orienta verificar o vínculo com o produto correto e utilizar seu processo de atualização do responsável técnico. A Maxiprod direciona o gerenciamento do CSRT ao fornecedor do emissor.

Esses relatos sustentam verificações práticas, mas não tornam a pendência de autorização a única causa possível. É preciso comparar o cadastro e a configuração que produziram o retorno específico. Também não se deve copiar o CNPJ ou o código de produto de outro fabricante para regularizar seu sistema.

Sequência segura de correção

1. Registre cStat, xMotivo completo, modelo, UF, ambiente e horário da tentativa.

2. Identifique qual componente preenche idCSRT e hashCSRT e confira o valor transmitido do identificador.

3. Peça ao fornecedor que verifique o cadastro correspondente e a situação do vínculo com o emitente.

4. Se houver pedido pendente, apure a etapa necessária para sua conclusão, sem supor aprovação automática.

5. Atualize os dados pelo procedimento suportado pelo emissor. Evite intervenções diretas na base sem orientação técnica.

6. Gere novamente o XML com o identificador confirmado e o hash correspondente à chave da nota, assine e transmita pelo fluxo normal.

7. Examine o novo retorno individual. Só então registre o resultado da correção.

A credencial secreta não precisa circular entre operador, contador e suporte para que a investigação comece. Compartilhe dados mínimos, documentos de cadastro e retornos por canais apropriados; mantenha senhas e CSRT fora de capturas, logs abertos e exemplos de atendimento.

Como separar a 976 de outras rejeições

A 974 aponta divergência do CNPJ do responsável com o cadastro. A 975 trata da falta de identificador e hash quando exigidos. A 976 verifica identificador não cadastrado; a 977 trata de identificador revogado; e a 978 indica divergência no hash calculado. Não há garantia de uma ordem única de apresentação desses problemas.

Na manutenção dos cadastros, preserve também o CNPJ alfanumérico de ZD02, previsto na NT 2026.004. Corrigir o tratamento desse CNPJ não cria um novo identificador CSRT. NT 2026.004, página 9.

O atendimento fica concluído quando o cadastro, a configuração e o resultado da nova transmissão estão esclarecidos. Repetir o mesmo arquivo sem mudança ou remover campos obrigatórios apenas desloca o problema e dificulta a identificação da causa.