Rejeição 297: Assinatura difere do calculado

• O XML foi alterado depois de assinado — às vezes só reformatado, com espaços, quebras de linha ou recuo.
• O arquivo foi convertido para outra codificação que não UTF-8.
• A assinatura foi calculada sobre um elemento diferente do infNFe.

Um integrador abre o XML já assinado para incluir uma observação nas informações complementares e salva. A assinatura foi calculada sobre o texto antigo; a SEFAZ recalcula sobre o novo e os valores não batem: 297.

1. Assine por último: nenhuma alteração, nem de formatação, depois da assinatura.
2. Gere o XML sem espaços e quebras de linha entre as tags, em UTF-8.
3. Se o problema começou depois de trocar o certificado, confira se o novo está instalado corretamente no emissor.

• Qualquer alteração na nota acontece antes da assinatura, nunca depois.
• Não passe o XML assinado por ferramentas que reorganizam ou reindentam o arquivo.

A validação acontece em camadas, e esta é uma das primeiras. Antes de olhar valores ou cadastro, a SEFAZ confere se o arquivo está montado como o leiaute manda: tags na ordem certa, formatos de data e número, assinatura digital íntegra e chave de acesso coerente com os campos.

Por isso o erro desta etapa quase nunca é do usuário que digitou a nota, e sim do sistema que gerou o XML. Se aparece em todas as notas, é configuração ou versão do emissor; se aparece em uma só, algum dado daquela nota (um texto, um valor) saiu num formato que o sistema não tratou.

Quando a SEFAZ rejeita, a nota não é registrada: o número continua disponível e a mesma nota pode ser reenviada depois de corrigida. O cuidado é não reenviar sem corrigir — com mais de 30 rejeições iguais, o serviço de autorização passa a responder com a rejeição 656 por cerca de uma hora para tudo o que o emissor mandar.

• 298Assinatura difere do padrão do Sistema
• 213CNPJ-Base do Emitente difere do CNPJ-Base do Certificado Digital