Rejeição 975: faltam idCSRT e hashCSRT na NF-e

A Rejeição 975, regra ZD07-10, exige o identificador do Código de Segurança do Responsável Técnico (idCSRT) e seu hash (hashCSRT) no grupo infRespTec. A NT 2018.005 v1.52 prevê a regra para o Paraná, modelo 55, a partir de 19/01/2026 em homologação e 23/02/2026 em produção. O resumo antigo de “implementação futura para todas as UFs” não descreve esse recorte atualizado.

A regra vale para NFC-e ou qualquer UF?

A tabela atual registra modelo 65 como implementação futura. Também preserva a exceção de não aplicação para NFF, tpEmis=3, e para os códigos de SVC que o texto da ZD07-10 indica como tpEmis=7 ou 8. Esses números são os da exceção escrita na fonte, e não uma orientação para mudar o tipo de emissão de uma nota comum.

Não estenda o cronograma do PR a outras UFs ou ao modelo 65. Na hipótese de retorno 975 fora desse contexto, confirme o documento efetivamente enviado, a UF e o ambiente autorizador e obtenha a orientação oficial específica. A identidade da tentativa deve ser mantida enquanto a divergência é esclarecida.

O que são CSRT, idCSRT e hashCSRT?

O CSRT é um segredo alfanumérico de 16 a 36 bytes conhecido pela SEFAZ e pela empresa responsável pelo sistema. Seu fornecimento, consulta e revogação são realizados no portal da UF, pelo responsável técnico, conforme o procedimento documentado. Ele não é o certificado digital e não é o CSC do contribuinte usado no QR-Code versão 2.

O idCSRT identifica o segredo usado, sem revelar seu conteúdo. No XSD, possui dois algarismos. O hashCSRT resulta da concatenação do CSRT com a chave de acesso da nota, aplicação de SHA-1 e representação em Base 64. O tipo do XSD é base64Binary com 20 bytes. Não é a escrita hexadecimal do hash do QR-Code.

O segredo CSRT não deve ser colocado no XML. Sob NFe/infNFe/infRespTec, o leiaute prevê o par idCSRT e hashCSRT em uma sequência opcional estruturalmente: quando essa sequência é usada, ambos os campos aparecem. A regra contextual pode exigir esse par, mesmo que o XSD geral permita sua ausência.

Presença dos campos garante que o CSRT está correto?

Não. A 975 trata a exigência dos campos. A NT também documenta validações distintas de cadastro do responsável técnico, identificador não cadastrado, identificador revogado e hash diferente do calculado. Um par presente, mas montado com segredo de outro fornecedor ou outra chave, não se torna válido por satisfazer a presença.

Para conferir a geração, a equipe autorizada compara o identificador com o cadastro da UF e verifica internamente qual segredo foi selecionado. Depois usa a chave exata da nota, sem conversão numérica que perca zeros ou caracteres. A NT 2026.004 adequou tipos de CNPJ e chave para alfanuméricos; limpar letras indiscriminadamente é incompatível com a preservação da chave oficial.

Exemplo: par omitido e hash reaproveitado

Cenário sintético A: uma NF-e comum, modelo 55, do PR, em produção após 23/02/2026, tem a identificação básica do fornecedor, mas omite o par CSRT. O diagnóstico da 975 não é a falta de nome ou telefone: a equipe precisa conferir por que a configuração segura do fornecedor não foi aplicada à geração desse par.

Cenário sintético B: após corrigir a presença, uma rotina reaproveita o hashCSRT de outra nota. A entrada do cálculo inclui a chave de cada documento; por isso, copiar o resultado anterior não verifica o novo documento. A etapa seguinte é revisar a seleção da chave e o cálculo, sem expor o segredo em log ou chamado.

Não há XML nem hash operacional de exemplo. A reprodução fiel exige segredo cadastrado e chave real protegida. O procedimento deve ser executado internamente pela equipe autorizada; valores inventados não demonstrariam a validade do vínculo.

Como encerrar o diagnóstico com segurança?

Preserve envio e retorno, confirme PR/modelo 55/ambiente/data e examine o par sob infRespTec no XML enviado. Confira a referência do segredo no cadastro seguro do fornecedor e a geração Base 64, com o schema aplicável. Se uma alteração for necessária, faça-a no emissor antes de gerar e assinar adequadamente o documento; não edite arquivo autorizado.

Confirme o resultado fiscal da mesma nota e ambiente. Não presuma autorização porque a 975 desapareceu: outra regra pode apontar cadastro ou hash incorretos. Uma tentativa com retorno ainda incerto precisa ter seu estado esclarecido antes de considerar novo envio.

Fontes oficiais

• MOC 7.0 Anexo I — 7.00: pp. 65–66 leiaute ZD/ZX; pp. 128–133 regras ZD/ZX.
• NT 2018.005 — 1.52: p. 4 cronograma; pp. 7–9 CSRT; p. 23 ZD01-10/ZD02-10/ZD07-10 e rasuras.
• NT 2026.004 CNPJ alfanumérico — 1.01: pp. 3–4 cronograma e alcance da atualização de tipos.