NF-e e NFC-e
Rejeição 298: como corrigir uma assinatura fora do padrão da NF-e
A rejeição 298 indica que a estrutura da assinatura digital não atende ao perfil exigido pelo serviço fiscal. O caminho é revisar o componente que gera e assina o XML, conferir a referência ao elemento assinado e validar o resultado com o schema oficial aplicável. Trocar valores da nota ou comprar outro certificado…
A rejeição 298 indica que a estrutura da assinatura digital não atende ao perfil exigido pelo serviço fiscal. O caminho é revisar o componente que gera e assina o XML, conferir a referência ao elemento assinado e validar o resultado com o schema oficial aplicável. Trocar valores da nota ou comprar outro certificado sem diagnóstico não resolve uma assinatura montada incorretamente.
Mensagem: “Rejeição: Assinatura difere do padrão do Sistema”. Algumas especificações usam a expressão “padrão do Projeto”.
O que a SEFAZ verifica
A regra F01 do MOC, de aplicação obrigatória na especificação, contempla a ausência da referência ao atributo Id e das transformações previstas para a assinatura. O XMLDSig da NF-e exige as transformações Enveloped e C14N. A F01 também informa que essas verificações são implementadas pelo schema da assinatura. MOC 7.0, Anexo I, seção 4.1.5.
Isso é diferente da rejeição 297, que trata de um valor de assinatura diferente do calculado. Também não se deve usar a 298 como nome genérico para certificado vencido, revogado ou fora da ICP-Brasil: o MOC tem verificações próprias para essas situações. A mensagem original ajuda a escolher o teste correto.
A assinatura precisa apontar para o elemento determinado pelo serviço. Na autorização, o alvo é o infNFe identificado por seu Id; em um evento, o leiaute define a assinatura de infEvento. Assinar o envelope SOAP ou o lote inteiro no lugar do elemento exigido não substitui essa assinatura. MOC, Visão Geral, seções 4.2.4, 5.1 e 5.8.
Diagnóstico passo a passo
Guarde o retorno completo e identifique se a rejeição veio da autorização, de um evento ou de outro pedido assinado. Anote modelo, UF ou autorizador, ambiente, versão do leiaute e horário. O mesmo código não determina sozinho qual XML precisa ser revisado.
Peça ao suporte que examine o arquivo efetivamente transmitido, preservando uma cópia íntegra para análise em canal seguro. Comparar somente o XML anterior à assinatura pode esconder uma transformação feita depois pelo integrador.
Confira se existe o bloco Signature e se Reference URI aponta para o Id do elemento correto. A referência deve resolver para um único elemento esperado: na nota, URI repete o Id de infNFe precedido por #. Não invente um Id para satisfazer o validador: ele precisa ser gerado de acordo com o leiaute da própria mensagem.
Verifique a presença e os identificadores das transformações Enveloped e C14N. A TecnoSpeed destaca esses pontos da F01. Essa conferência cabe ao responsável pelo assinador, sem edição manual de uma assinatura pronta.
Valide a mensagem com o pacote de schemas correspondente ao serviço e à versão aceita no ambiente. A Datacaixa também orienta confrontar as características da assinatura com o padrão fiscal. Um XML bem-formado pode continuar incompatível com esse perfil.
Corrija a configuração ou implementação do emissor, gere novamente a mensagem rejeitada e assine somente depois que seu conteúdo estiver finalizado. Faça o teste de regressão em homologação antes de liberar a alteração do componente para produção.
Cenários que ajudam a localizar a causa
A falha começou após atualização de biblioteca: confira mudanças nos padrões automáticos de XMLDSig. Uma biblioteca genérica pode usar transformações, algoritmos, referência ou organização de elementos diferentes dos exigidos pela NF-e. A equipe deve comparar a configuração anterior e a nova contra a especificação vigente, sem voltar a uma versão vulnerável apenas para obter aceitação.
Uma nota funciona, mas determinado evento falha: não reutilize a rotina de assinatura da nota sem adaptar o elemento alvo e o leiaute do evento. Confira tpEvento, verEvento e o schema específico. O certificado correto não compensa uma assinatura aplicada no lugar errado.
A assinatura valida localmente: verifique o que foi validado. Uma verificação criptográfica genérica pode não exigir o subconjunto XMLDSig da NF-e. Além disso, o arquivo transmitido pode ser diferente do arquivo usado no teste.
A configuração não é acessível ao operador: encaminhe o diagnóstico ao fornecedor do emissor ou integrador. A Omie trata a correção como análise técnica de estrutura e configuração. Não há um ajuste tributário universal a fazer na nota.
Algoritmos, e-CPF, NFF e PAA
O MOC 7 documenta um perfil XMLDSig que inclui RSA-SHA1 e SHA-1. Isso é uma descrição do protocolo fiscal documentado, não uma recomendação geral de criptografia nem autorização para enfraquecer TLS ou desativar validações. Não substitua algoritmos por SHA-256 por tentativa, nem habilite algoritmos antigos globalmente no computador. A implementação precisa seguir a versão oficial aplicável; incompatibilidade com a política de segurança deve ser tratada pelo fornecedor e pelo responsável técnico.
Nos fluxos previstos para emitente pessoa física, o uso de e-CPF não elimina a exigência de assinatura no formato fiscal. Na NFF, o XML é assinado pela SVRS conforme o regime próprio. NT 2021.002 v1.12, grupo F.
O PAA acrescenta uma assinatura avançada específica do emitente e exige também a assinatura qualificada do documento com certificado ICP-Brasil do provedor. A estrutura PAASignature não deve ser confundida com a Signature fiscal. A NT 2026.001 v1.02b corrige, inclusive, uma instrução anterior riscada na descrição de SignatureValue. Por isso, copiar um trecho antigo de implementação pode produzir resultado incompatível. O recorte dessa NT é NF-e modelo 55, com autorização centralizada na SVRS; não estenda o procedimento à NFC-e. NT PAA, seções 1.1, 8.1 e 8.3.
Exemplo hipotético
Após uma atualização, o integrador gera Reference URI vazio e só uma transformação. A equipe corrige o alvo e restaura as duas transformações distintas exigidas. Este fragmento didático mostra os identificadores; não é uma assinatura completa nem deve ser transmitido:
<Transforms xmlns="http://www.w3.org/2000/09/xmldsig#"> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </Transforms>
O suporte regenera a assinatura completa e valida o XML final. Não altera a operação comercial ou os dados fiscais.
Como confirmar a solução e quando interromper a tentativa
A validação local deve passar, mas a confirmação depende do resultado definitivo do serviço. Na autorização, verifique o protocolo da nota; em um evento, confira o resultado individual do evento, além do retorno do lote. Se uma tentativa anterior ficou sem resposta, consulte a situação antes de enviar novamente.
A F01 aparece na autorização de NF-e/NFC-e e nos serviços que exigem assinatura. Há ocorrência expressa nos eventos de prorrogação da NF-e e no EPEC da NFC-e. Isso não comprova disponibilidade de cada evento em todas as UFs. Se não for possível identificar o serviço, seu schema vigente ou o fluxo NFF/PAA, interrompa as mudanças no assinador até obter essas informações do suporte ou do autorizador.
Não compartilhe senha, PIN, chave privada ou arquivo de certificado com chave privada em mensagens. Não desative validação criptográfica, cadeia de confiança ou proteção da conexão.
Revisão documental: 09/10/2026. O cronograma PAA consultado prevê produção em 05/10/2026; a data publicada não comprova habilitação ou disponibilidade para um contribuinte específico.