Rejeição 978 e a conferência do hash CSRT

A rejeição 978 ocorre quando o hashCSRT enviado na NF-e diverge do resultado calculado pela SEFAZ. Para corrigir, o responsável pelo emissor deve verificar a credencial selecionada, a chave de acesso usada e a transformação aplicada pelo programa. Preencher um texto com o tamanho esperado não garante que o cálculo esteja correto.

Mensagem: “Rejeição: Hash do CSRT diverge do calculado”.

A regra é 7ZD09-10, e o campo fica em infNFe/infRespTec/hashCSRT. O XML leva esse resultado e o identificador idCSRT. O valor secreto do CSRT deve permanecer protegido; ele não deve ser inserido no XML, em exemplos de atendimento ou em validadores públicos. NT 2018.005 v1.52, páginas 8, 20 e 25.

Confira o alcance antes de aplicar um tutorial

O cenário documentado da regra é o Paraná, NF-e modelo 55. A NT estabelece validação em homologação desde 16 de setembro de 2024 e em produção desde 1º de outubro de 2024 para os campos informados. NFC-e, modelo 65, permanece com implementação futura; NFF, tpEmis igual a 3, e SVC, tpEmis igual a 7 ou 8, são exceções expressas.

Na v1.52, a observação antiga de implantação genérica por UF e futura na SVC está riscada. Não a trate como trecho vigente só porque apareceu na extração de texto. Minas Gerais marca 978 como não validada, enquanto São Paulo apresenta situação inativa em NF-e e NFC-e. Isso impede a generalização nacional e não elimina a aplicação documentada no Paraná. Tabela MG, SP NF-e e SP NFC-e.

A obrigação de informar o CSRT na NF-e paranaense em produção passou a valer em 1º de abril de 2026, conforme o Boletim 005/2026. Esse prazo da presença obrigatória não substitui o marco de validação dos campos já enviados desde 2024. Apagar idCSRT e hashCSRT onde são exigidos pode apenas trocar a 978 pela 975.

Como o resultado deve ser produzido

A seção 2.3 da NT descreve a sequência: concatenar o CSRT com a chave de acesso da nota, aplicar SHA-1 e converter o resultado para Base64. O idCSRT deve identificar precisamente a credencial empregada nesse cálculo. NT v1.52, páginas 8 e 9.

Na implementação, o resultado do SHA-1 é um resumo binário de 20 bytes. É esse conjunto de bytes que deve receber a codificação Base64, produzindo 28 caracteres. Uma biblioteca pode oferecer tanto o resumo binário quanto sua representação hexadecimal em 40 caracteres. Codificar esses 40 caracteres como texto gera outro resultado e não corresponde ao procedimento esperado.

Também não se calcula o hash sobre o identificador idCSRT, sobre o XML inteiro ou sobre uma chave de outra NF-e. A ordem é CSRT seguido da chave. Incluir separadores, espaços, quebras de linha ou o prefixo literal “NFe” na chave usada como entrada altera os dados processados. Essas são verificações técnicas decorrentes da sequência definida na NT, não causas confirmadas apenas pelo retorno 978.

O CSRT não é o CSC utilizado no QR-Code da NFC-e. Da mesma forma, hashCSRT não substitui a assinatura digital do XML e não é o DigestValue dessa assinatura. Reaproveitar uma rotina de outro mecanismo sem conferir suas entradas e saída pode produzir um valor estruturalmente aceitável, mas divergente.

O que conferir na configuração e no documento

Comece pelo XML realmente transmitido, preservando seu retorno. Verifique qual idCSRT foi enviado e peça à equipe responsável que confirme, internamente, se o segredo carregado corresponde a esse identificador. Uma troca parcial de configuração pode manter o identificador novo e o segredo anterior, ou o contrário.

Em seguida, confira o ambiente. Registre tpAmb e o serviço utilizado, e examine a configuração efetivamente carregada nesse processo. O sucesso em homologação não certifica o comportamento em produção. Não presuma, sem confirmação do fornecedor, que copiar parâmetros entre ambientes resolve a divergência.

Compare a chave usada no cálculo com a chave final do documento. Se algum dado que compõe a chave foi alterado após o cálculo, o hash anterior precisa ser substituído pelo resultado gerado para a chave correta. Não remova letras válidas nem converta indiscriminadamente a chave para número: a adequação ao CNPJ alfanumérico passou campos de chave a tipo caractere, mantendo 44 posições. NT 2026.004 v1.01, páginas 3 e 9.

Confira também o valor após a serialização do XML. A rotina pode calcular corretamente e outra etapa truncar, substituir ou reaproveitar o resultado. Ter 28 caracteres é uma conferência de formato, não uma prova de correspondência com a SEFAZ.

Sequência prática de correção

1. Registre cStat, xMotivo, UF, modelo, ambiente e versão do emissor.

2. Confirme o vínculo entre idCSRT e a credencial carregada, sem revelar o segredo.

3. Valide internamente as entradas, a ordem da concatenação e o uso do resumo binário SHA-1 antes do Base64.

4. Recalcule com a chave final e confira o hashCSRT efetivamente gravado no XML.

5. Gere e assine novamente o documento pelo fluxo suportado; não edite manualmente um XML já assinado.

6. Transmita e examine o retorno individual. Registre autorização somente quando ela estiver confirmada.

A InvoiSys orienta revisar o cálculo. A Webmania informa que sua aplicação o realiza durante a emissão. A Berga sugere investigar configuração e caracteres indevidos. Esses procedimentos ajudam a localizar a falha, mas não demonstram que toda 978 tenha uma causa única ou uma ordem fixa em relação a outros retornos.

Quando o problema persiste

Se apenas algumas notas falham, compare como suas chaves e hashes foram gerados, sem substituir valores por dados de uma nota autorizada. Se todas falham após uma atualização, investigue parâmetros e bibliotecas alterados, mantendo a hipótese aberta até conferir o processamento.

Identificador revogado é o diagnóstico da 977; identificador não cadastrado corresponde à 976. O SAC-PR, pergunta 2566, remete a 978 ao procedimento de geração do hash. Encaminhe ao suporte os dados mínimos do retorno e a versão do sistema. Não envie o CSRT secreto, não o cole em calculadoras externas e não desative validações para concluir o atendimento.