Rejeição 975: como informar o identificador e o hash do CSRT

A rejeição 975 sinaliza a falta das informações exigidas de identificação e hash do Código de Segurança do Responsável Técnico. No Paraná, a obrigatoriedade do CSRT na NF-e em produção vale desde 1º de abril de 2026, conforme o Boletim Informativo 005/2026. O ajuste deve ser feito pelo fornecedor do emissor e conferido no XML que efetivamente será transmitido.

Mensagem: “Rejeição: Obrigatória a informação do identificador do CSRT e do Hash do CSRT”.

A ZD07-10 verifica esses campos quando o grupo do responsável técnico é informado e a exigência aplicável está ativa. Os campos envolvidos são idCSRT e hashCSRT, dentro de infRespTec. O segredo CSRT permanece sob controle do fornecedor e do Fisco; ele não deve ser colocado no XML, nem usado como conteúdo de idCSRT. Boletim PR 005/2026, NT 2018.005 v1.52, seções 2 e 3.7.

Qual é o alcance atual da exigência

A regra ZD07-10 tem aplicação documentada no Paraná para a NF-e, modelo 55. A NT 2018.005 v1.52 mantém o modelo 65 como implementação futura e exclui NFF, com tpEmis igual a 3, e SVC, com tpEmis igual a 7 ou 8. A indicação geral 55/65 na tabela não elimina essas delimitações. NT, página 23.

A redação antiga que mencionava todas as UFs e a observação genérica sobre cadastro de fornecedores estão riscadas na versão atual. Não se deve deduzir a exigência do CSRT em outro estado apenas porque ele exige a identificação ou o credenciamento da empresa de software.

Minas Gerais registra a 975 como não validada na tabela versão 2.00, mesmo com exigências próprias para o responsável técnico de emissores usados no varejo de combustíveis. São Paulo também mantém a 975 inativa nas tabelas de NF-e e NFC-e. Tabela MG, SP NF-e, SP NFC-e.

Como interpretar os adiamentos

A NT v1.52 apresenta 19 de janeiro de 2026 para homologação e 23 de fevereiro de 2026 para produção. A página de CSRT do SPED-PR ainda reproduz esse cronograma. Entretanto, o Boletim 005/2026, publicado em 3 de março de 2026, determina a obrigação em produção a partir de 1º de abril de 2026. Para essa obrigação estadual, deve ser considerado o comunicado posterior. Página CSRT do PR.

A data de preenchimento obrigatório não deve ser confundida com a validação de dados já enviados. A própria NT estabelece validação de idCSRT e hashCSRT informados em produção desde 1º de outubro de 2024. Assim, adiar a obrigação de presença não significava aceitar identificadores inexistentes ou hashes incorretos.

Essas datas descrevem a documentação e seus cronogramas. Um teste em homologação não comprova que a configuração de produção está correta, nem substitui a leitura do retorno da emissão real.

O que cada informação representa

O CSRT é a credencial secreta utilizada pelo responsável técnico. O idCSRT identifica qual credencial foi usada e possui campo próprio de duas posições numéricas. O hashCSRT é o resultado calculado para aquela chave de acesso, representado em Base64, com 28 caracteres no leiaute.

O procedimento especificado concatena o segredo CSRT com a chave de acesso, aplica SHA-1 e converte o resultado para Base64. Cabe à implementação gerar esse valor com os dados finais da nota. Copiar o hash de outro documento ou confundir identificador com segredo não resolve o problema. NT, seções 2.3 e 3.7.

Esses elementos também são diferentes do certificado digital e do CSC utilizado em regras da NFC-e. Trocar um pelo outro compromete a configuração. Para investigar a 975, basta inicialmente verificar a presença e o mapeamento dos campos, sem expor a credencial.

Roteiro de correção no emissor

1. Identifique o retorno individual da nota e confirme modelo, UF, ambiente e tipo de emissão.

2. Examine infRespTec no XML transmitido. Verifique se idCSRT e hashCSRT foram gerados e preservados pela integração.

3. Confirme com o fornecedor que o emissor está preparado para a obrigação vigente e que utiliza a credencial correspondente ao seu cadastro.

4. Revise o mapeamento entre ERP, biblioteca e transmissor. Uma informação existente na configuração pode ser descartada na montagem do arquivo.

5. Gere novamente o documento pelo fluxo suportado, valide a estrutura e assine o XML antes de transmitir.

6. Leia o novo retorno. Cadastro inexistente, revogação ou hash divergente têm tratamentos específicos nas rejeições 976, 977 e 978.

Caso apenas um dos campos seja montado, também pode haver incompatibilidade com a sequência definida no schema. Não classifique toda falha estrutural como 975 sem examinar o cStat e o xMotivo efetivamente recebidos.

Por que a solução varia entre sistemas

A TecnoSpeed documenta os campos idCSRT_ZD08 e hashCSRT_ZD09. A orientação da TOTVS para Datasul envolve atualização de componentes e parametrização específica por UF. A Treeunfe explica a inclusão dos dois campos e a geração do hash.

Esses guias ajudam a localizar a configuração, mas não tornam seus menus, credenciais ou procedimentos transferíveis para outro emissor. Use a documentação da versão instalada. Evite editar diretamente a base ou incluir valores copiados de exemplos.

Como evitar recorrência

Não remova infRespTec para esconder a falta do CSRT: isso pode gerar a 972 onde a identificação é exigida. Mantenha os dados do responsável, a credencial protegida e a rotina de hash coerentes entre os componentes do sistema.

Na manutenção do grupo, considere também o CNPJ alfanumérico previsto para ZD02 na NT 2026.004. A mudança do identificador empresarial não permite inventar um novo idCSRT ou reutilizar um hash antigo. NT 2026.004, página 9.

Registre versão, ambiente, horário, retorno original e resultado após o ajuste. Compartilhe somente o necessário para o atendimento, sem senhas ou segredo CSRT. A correção estará confirmada pelo novo processamento da SEFAZ, que ainda poderá apontar outras inconsistências da nota.