Pular para o conteúdo
Fiscal ProBiblioteca
NF-e e NFC-e · Responsável técnico, NFF, agro e PAA

hashCSRT: geração SHA-1/Base64 e diagnóstico da rejeição 978

<hashCSRT>infRespTec › hashCSRT

Revisão editorial em 14 de out. de 2026. As versões e condições das regras estão indicadas ao longo do artigo.

hashCSRT é o resultado em Base64 do hash SHA-1 calculado a partir do CSRT concatenado com a chave de acesso da NF-e/NFC-e. O CSRT é um segredo do responsável técnico e do Fisco; ele não deve aparecer no XML. A tag transporta o resultado derivado, junto do identificador idCSRT.

Caminho desta página: /nfeProc/NFe/infNFe/infRespTec/hashCSRT. O prefixo nfeProc identifica a nota processada; a informação estudada pertence ao conteúdo da NF-e, dentro de NFe/infNFe.

Entradas e sequência de geração

A NT 2018.005 v1.52 descreve: concatenar CSRT com a chave de acesso, nessa ordem; calcular SHA-1; converter o resultado para Base64; informar idCSRT correspondente e hashCSRT. Não há separador entre as duas entradas na concatenação documentada.

SHA-1 produz 20 bytes. Sua representação hexadecimal tem 40 caracteres; codificar esses 40 caracteres como se fossem os 20 bytes produz outro resultado. Para a forma canônica documentada, o Base64 dos 20 bytes tem 28 caracteres. A redação explicativa da NT menciona bytes hexadecimais; o XSD é inequívoco ao exigir comprimento binário 20, por isso a implementação deve trabalhar com o resultado binário do hash. NT, p. 8–10 e XSD.

Amostra de codificação sem segredo fiscal

Apenas para mostrar o tamanho binário, os 20 bytes didáticos todos iguais a zero têm esta representação:

<hashCSRT xmlns="http://www.portalfiscal.inf.br/nfe">AAAAAAAAAAAAAAAAAAAAAAAAAAA=</hashCSRT>

Não é um hashCSRT operacional, não corresponde a uma nota ou segredo de cliente e não deve ser usado para emissão. O fragmento é parcial, sem XML completo. Ele demonstra a forma Base64 aceita para 20 bytes, não comprova cálculo, credenciamento ou autoria.

No documento real, idCSRT e hashCSRT formam a sequência opcional de segurança: quando a sequência existe, ambos são obrigatórios. idCSRT identifica o segredo usado; não é o próprio segredo e não é concatenado no lugar dele.

Onde a NT v1.52 exige e valida o par

A NT 2018.005 v1.52 apresenta, para ZD07-10 na NF-e modelo 55 do Paraná: 19/01/2026 em homologação e 23/02/2026 em produção. Há uma comunicação estadual posterior: o Boletim 005/2026, publicado em 03/03/2026, informa a obrigatoriedade do CSRT na NF-e em produção a partir de 01/04/2026. A página estadual de CSRT ainda reproduz a previsão de 23/02/2026; para a exigência em produção, é necessário considerar a comunicação posterior, sem confundir os dois registros.

As verificações de credenciais informadas possuem outro histórico: 7ZD08-10, 7ZD08-20 e 7ZD09-10 registram PR/modelo 55, homologação desde 16/09/2024 e produção desde 01/10/2024. Exigir presença e validar conteúdo quando informado não são a mesma etapa. Modelo 65 permanece assinalado como implementação futura nas linhas da NT; há exceções para NFF (tpEmis=3) e SVC (tpEmis=7 ou 8). Essas condições não devem ser generalizadas para todas as UFs.

NT 2018.005 v1.52, p. 4 e 23–25 e Boletim estadual 005/2026.

Como investigar 978 sem expor o CSRT

Confirme UF, ambiente, emitente e CNPJ do responsável, depois verifique se o identificador corresponde ao CSRT vigente configurado. Compare a chave final da nota com a usada no cálculo; alterações de componentes da chave exigem novo resultado correspondente antes da assinatura.

Revise ordem da concatenação, caracteres adicionais, codificação de entrada e conversão dos 20 bytes para Base64. Teste localmente sem imprimir o segredo ou registrar a concatenação em logs. Se houver 976 ou 977, investigue cadastro ou revogação do identificador em vez de recalcular indefinidamente o mesmo hash. Corrija a causa comprovada, preservando histórico e credenciais de cada ambiente.

Fontes oficiais

Referência técnica para integração

XPath completo
/nfeProc/NFe/infNFe/infRespTec/hashCSRT
Namespace
http://www.portalfiscal.inf.br/nfe
Leiaute
4.00 · PL_010e_v1.02
Ocorrências no XSD
1–1 no contexto do elemento pai
Tipo
inline:xs:base64Binary · base64Binary
Preenchimento no catálogo
Condicional

A ocorrência vale dentro da estrutura XML: um campo obrigatório em um grupo opcional não torna esse grupo obrigatório. A aplicação fiscal depende da operação e da versão da regra.

length
20