Rejeição 297: como investigar a divergência na assinatura do XML

A rejeição 297 indica que o valor da assinatura digital não confere na validação da mensagem recebida. Preserve o XML enviado e peça ao suporte que confira a geração da assinatura e possíveis alterações entre a assinatura e a transmissão. A correção deve ocorrer no processo do emissor, seguida de nova geração e assinatura da mensagem rejeitada, sem editar manualmente o arquivo já assinado.

Mensagem: “Rejeição: Assinatura difere do calculado”.

O que a SEFAZ está conferindo

A regra F02 descreve a divergência entre SignatureValue e o valor calculado na verificação. Ela pertence ao grupo de validação da assinatura digital. Ter um certificado válido, conseguir abrir uma conexão ou passar pela validação de estrutura do XML não comprova que a assinatura daquela mensagem esteja íntegra. MOC 7.0, Anexo I, seção 4.1.5, página 74.

Na assinatura XML, DigestValue é o resumo do conteúdo referenciado após as transformações previstas. SignatureValue é a assinatura criptográfica sobre a forma canonicalizada de SignedInfo, que contém as referências e os métodos. A validação técnica precisa conferir essas duas partes; elas não são o mesmo campo nem devem ser recalculadas e coladas à mão no documento. W3C, XML Signature, seção 3.2.

Se apenas o conteúdo referenciado for alterado, a comparação com DigestValue pode falhar mesmo que a verificação isolada da assinatura de SignedInfo ainda passe. A assinatura XML só é válida quando as duas etapas passam. Essa distinção orienta o diagnóstico técnico; não muda a definição da F02 no MOC.

O MOC define o perfil XMLDSig utilizado pela NF-e. A identificação do conteúdo assinado, a canonicalização e os algoritmos devem seguir esse perfil. Canonicalização é o tratamento padronizado do XML para o cálculo; uma comparação apenas visual entre arquivos não substitui a validação criptográfica. MOC, Visão Geral, seção 4.2.4.

Antes de tentar corrigir

1. Confira o cStat e o xMotivo originais. Registre serviço, modelo, ambiente, autorizador, horário e versão do emissor. Identifique se o retorno é da nota, de uma inutilização ou de um evento.

2. Preserve, sem abrir e salvar novamente, o XML assinado e a cópia efetivamente enviada. O suporte deve investigar o arquivo da tentativa rejeitada, não uma versão regenerada depois.

3. Se houve tentativa anterior sem resposta conclusiva, consulte sua situação antes de reenviar. Uma tela local de erro não justifica criar outra nota ou mudar a numeração.

4. Informe ao suporte se houve atualização do emissor, troca de componente de assinatura, integração intermediária ou alteração de dados depois da assinatura. São pistas, não provas da causa.

A Dynamicca relaciona a rejeição à integridade do conteúdo assinado e orienta preservá-lo depois da assinatura. A TecnoSpeed também inclui a manipulação posterior entre os pontos a investigar.

O que o suporte deve conferir

A assinatura já falha antes do envio: revisar o componente de assinatura, o elemento indicado pela Reference URI, os métodos previstos no leiaute e a correspondência entre a chave usada e o certificado presente na assinatura. A verificação deve incluir o resumo referenciado e a assinatura de SignedInfo.

A assinatura é válida ao sair do assinador e falha na mensagem transmitida: comparar o conteúdo nas etapas seguintes. Integrações podem regravar texto, ajustar espaços, converter caracteres ou reorganizar o XML. É preciso localizar a transformação que afetou a validação e corrigi-la no processo.

O XML passou no schema: validar também a assinatura. O schema verifica a estrutura e as restrições do leiaute; isso não substitui a conferência criptográfica. O MOC trata essas verificações separadamente.

O erro aparece somente em um evento: analisar a assinatura do próprio evento. Não substituir o XML da nota autorizada por uma nova versão. A Omie documenta a ocorrência também em Carta de Correção, que deve ser examinada no fluxo e modelo em que é permitida.

O XML enviado passa em uma validação técnica, mas a SEFAZ retorna 297: confirmar que o teste usou exatamente a mensagem transmitida, o perfil NF-e e a versão aplicável. Reúna o diagnóstico para o fornecedor e, se necessário, para o autorizador. Não desative verificações nem atribua automaticamente a divergência à SEFAZ.

Diferenças nos arquivos podem ajudar a localizar a etapa alterada, mas nem toda diferença de serialização implica falha de assinatura: o padrão leva em conta a forma canonicalizada. O resultado deve vir de uma verificação compatível com o perfil fiscal. W3C, validação das referências.

Devo remover acentos, espaços e caracteres especiais?

Não faça uma limpeza indiscriminada dos dados fiscais. O MOC exige cuidados na geração, como não inserir espaços nas extremidades dos campos nem caracteres de formatação entre as tags. Também prevê sequências de escape para caracteres que afetam o XML, como o “&”. Essas regras devem ser aplicadas pelo gerador antes da assinatura, preservando o significado da informação. MOC, Visão Geral, seções 4.2.1.3 a 4.2.1.5, página 51.

Uma orientação genérica para “retirar caracteres especiais” não identifica a causa de toda 297. Se uma razão social contém um “&” legítimo, o emissor deve representá-lo corretamente no XML; não se deve mutilar o nome apenas para tentar obter autorização. Erros de estrutura, preenchimento e assinatura podem produzir retornos diferentes.

Nunca remova quebras de linha, altere codificação ou reformate o XML depois de assinado como tentativa de correção. Corrigido o gerador, valide os dados legítimos e deixe o emissor gerar e assinar novamente a mensagem rejeitada.

Confira os códigos próximos

A 298, regra F01, trata de assinatura fora do padrão exigido, incluindo problemas na referência ou nas transformações previstas. A 297, regra F02, trata da divergência na verificação do valor da assinatura. Já as rejeições 290 a 296 verificam características do certificado, como validade, cadeia e revogação. Não renove o certificado nem altere dados tributários sem evidência de que essa seja a causa do caso.

Nos fluxos PAA, há uma assinatura adicional específica, além da assinatura fiscal qualificada. A NT possui regras próprias para essa estrutura. O suporte deve identificar qual assinatura está sendo validada, em vez de tratar qualquer campo chamado SignatureValue como a mesma verificação F02. A assinatura do PAA não elimina as validações do MOC. NT 2026.001 v1.02b, seção 1.1 e regras ZG04-10 e P83-10.

Exemplo hipotético

Uma distribuidora recebe 297 depois de atualizar sua integração. O suporte compara as cópias preservadas e identifica que uma rotina intermediária modificou o conteúdo de SignedInfo depois da geração de SignatureValue. A forma canonicalizada transmitida já não é a mesma sobre a qual a assinatura foi calculada.

A rotina é corrigida para preservar a saída do assinador. O preenchimento deve estar concluído antes da assinatura. Para a mensagem rejeitada, o emissor gera novamente o XML com as informações corretas, produz uma nova assinatura e valida o arquivo final. A distribuidora não edita DigestValue ou SignatureValue à mão e não muda tributos ou valores da operação.

Onde se aplica e como confirmar a solução

A validação da assinatura é prevista em autorização de NF-e, modelo 55, e NFC-e, modelo 65, inutilização e recepção de eventos. As especificações de prorrogação da NF-e e EPEC da NFC-e também relacionam a 297. Cada evento tem seu modelo, autor, ambiente e disponibilidade próprios; essa relação não autoriza qualquer evento ou contingência em todas as UFs. MOC, Visão Geral, tabelas 5-3, 5-11 e 5-34.

Confira a validação técnica da mensagem final e, depois, o resultado oficial da operação. Uma assinatura íntegra não garante aprovação em todas as regras fiscais. Guarde a autorização e o protocolo da nota ou o retorno específico da inutilização ou do evento. Preserve os documentos já autorizados.

Use o canal de suporte autorizado para informações fiscais. Não envie XML real a validadores desconhecidos e nunca compartilhe senha, PIN ou chave privada para que alguém confira uma assinatura.

Revisão documental: 09/10/2026. Procedimento de diagnóstico; serviço e implantação precisam ser confirmados para a UF e o ambiente envolvidos.

Referências complementares

• Pedido de prorrogação, NT 2015.001 v1.30, seções 6.7(d) e 7.7(d): https://dfe-portal.svrs.rs.gov.br/NFE/DownloadArquivoEstatico/?sistema=NFE&tipoArquivo=3&nomeArquivo=NT+2015.001+-+v+1.30.pdf

• EPEC NFC-e, NT 2014.003 v1.02, seção 03.8(d); adoção a critério da UF: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=HYPw%2BDBncKo%3D