Rejeição 298 — Assinatura difere do padrão do Sistema

O que é esta rejeição?#

A Rejeição 298 é 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 padrão do Projeto.

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 tpEmis for diferente de 1 (emissão normal) e a dhEmi registrada no XML for anterior ao momento de transmissão sem que exista um evento de registro de contingência correspondente, então o XML pode ter sido manipulado após a assinatura para alterar o modo de emissão retroativamente: reconstrua o XML a partir do evento de contingência original e reassine antes de transmitir.
• Se o valor calculado de vNF no total (ICMSTot) divergir da soma dos campos vPag em detPag, e adicionalmente o campo tPag ou vPag tiver sido editado para reconciliar a diferença sem nova assinatura, então a integridade do bloco de pagamento está comprometida em relação ao conteúdo assinado: recalcule todos os totais a partir dos itens det, ajuste detPag e gere nova assinatura cobrindo o nó NFe completo.
• Se o CRT do emitente for 1 (Simples Nacional) e houver itens det com CST de ICMS pertencente à tabela B (regime normal, como 00, 10, 20, 51, 60, 70, 90) em vez de CSOSN da tabela A (101, 102, 103, 201, 202, 203, 300, 400, 500, 900), então a estrutura tributária dos itens é incompatível com o regime declarado, indicando possível substituição de campos após a assinatura original: reverta os campos de imposto ao estado assinado e utilize os CSTs corretos para o regime.
• Se o CFOP dos itens det indicar operação interestadual (série 6xxx) mas a UF do emitente (emit/enderEmit/UF) for igual à UF do destinatário (dest/enderDest/UF), ou o inverso ocorrer com CFOP 5xxx em UF distintas, e o campo idDest for inconsistente com essa relação, então houve alteração de pelo menos um desses campos após a assinatura, corrompendo a consistência geográfica da operação: restaure o XML ao estado original assinado, corrija o CFOP e idDest de acordo com as UFs reais e reassine.
• Se o campo finNFe for 2 (NF-e complementar) ou 4 (devolução) e não existir o grupo NFref com a chave de acesso da NF-e referenciada dentro de ide, então a nota está estruturalmente incompleta para sua finalidade declarada, sugerindo que o campo finNFe foi alterado para um valor diferente do original após a assinatura sem inclusão do NFref obrigatório: adicione o NFref com a chave correta ou reverta finNFe ao valor original, reconstituindo o XML íntegro antes de assinar novamente.