Rejeição 297 — Assinatura difere do calculado

O que é esta rejeição?#

A Rejeição 297 é retornada pela SEFAZ durante a validação da NF-e quando há uma inconsistência relacionada a assinatura digital do documento. Isso significa que a nota fiscal não foi autorizada e precisa ser corrigida antes de ser retransmitida.

Este código indica que rejeição: Assinatura difere do calculado.

Os campos afetados estão na seção de certificado digital do XML.

Campos XML relacionados#

Esta rejeição está associada aos seguintes campos do XML da NF-e. Verifique cada um deles ao diagnosticar o problema:

Causas comuns#

• A assinatura digital do XML está corrompida ou não corresponde ao conteúdo do documento
• O XML foi alterado após a assinatura, invalidando a integridade
• O algoritmo de assinatura utilizado não é compatível com o exigido pela SEFAZ
• O certificado usado para assinar não está na cadeia de confiança ICP-Brasil

Como resolver#

1. Gere novamente a assinatura digital do XML sem alterar nenhum campo após a assinatura
2. Verifique se o certificado digital utilizado é válido e do tipo ICP-Brasil
3. Confirme que o algoritmo de assinatura é SHA-1 (para versões antigas) ou SHA-256
4. Certifique-se de que não há espaços, quebras de linha ou caracteres extras inseridos no XML após a assinatura

Verificações analíticas#

• Se o campo CRT do emitente for igual a 1 (Simples Nacional) e os campos de ICMS dos itens utilizarem CST da tabela A (00, 10, 20, 30, 40, 41, 50, 51, 60, 70, 90) em vez de CSOSN da tabela B (101, 102, 103, 201, 202, 203, 300, 400, 500, 900), então há inconsistência entre regime tributário e tributação de ICMS: substitua os valores CST pelos códigos CSOSN correspondentes ao regime Simples Nacional, pois essa divergência pode ter motivado correção manual no XML após a assinatura, invalidando-a.
• Se o valor calculado de vICMS (vBC multiplicado por pICMS dividido por 100) diferir do vICMS declarado no XML em qualquer item de detalhe, e o campo pRedBC estiver presente sem que vBC reflita a base reduzida (vBCOrig multiplicado por 1 menos pRedBC dividido por 100), então há inconsistência aritmética na apuração da base de cálculo reduzida: recalcule vBC aplicando corretamente o percentual de redução antes de assinar, pois ajustes manuais posteriores à assinatura para corrigir esse valor corrompem a integridade do documento.
• Se o campo tpNF for igual a 1 (saída) e o CFOP de algum item iniciar com dígito 1 ou 2 (entradas), ou se tpNF for igual a 0 (entrada) e o CFOP iniciar com dígito 3, 5, 6 ou 7 (saídas ou exportações), então há divergência entre a natureza da operação declarada e o CFOP utilizado nos itens: corrija o CFOP para que seu primeiro dígito seja compatível com o tipo da nota (1 ou 2 para entradas, 5, 6 ou 7 para saídas) antes de gerar e assinar o XML, evitando retrabalho pós-assinatura.
• Se o somatório de vPag em todos os elementos detPag da seção pag diferir do valor de vNF declarado no total da nota e o campo tPag não incluir o código 90 (sem pagamento) ou 99 (outros) para cobrir a diferença, então há inconsistência entre o valor total da nota e a forma de pagamento declarada: ajuste os valores de vPag ou acrescente um detPag complementar para que o total de pagamentos corresponda exatamente a vNF antes da assinatura, pois alterações nessa seção após assinar invalidam o hash.
• Se o campo finNFe for igual a 2 (NF-e complementar) ou 4 (devolução) e o grupo NFref estiver ausente dentro de ide, ou se NFref estiver presente mas a chave de acesso referenciada tiver comprimento diferente de 44 dígitos numéricos, então a nota carece da referência obrigatória à NF-e de origem: inclua o elemento NFref com a chave de acesso correta e completa na estrutura ide antes de assinar, pois a ausência ou correção desse campo após a assinatura inicial é causa direta de rejeição por divergência de assinatura.