Rejeição 445 e a assinatura indevida no QR Code

A rejeição 445 indica que foi informado o parâmetro de assinatura do QR Code v3 em uma nota que não está em contingência offline. O primeiro dado a conferir é a forma de emissão do XML. Pela regra ZX02-330, a restrição vale quando tpEmis é diferente de 9.

Essa orientação se refere à assinatura incluída na sequência de parâmetros do QR. A assinatura digital do próprio XML continua necessária conforme o processo de emissão. Apagar a assinatura do documento, desativar o certificado ou eliminar indiscriminadamente toda assinatura do QR são medidas que não corrigem o enquadramento e podem produzir novas falhas.

Leia a condição antes de remover qualquer campo

A NT 2025.001 v1.03 apresenta três verificações complementares para NFC-e, modelo 65:

• ZX02-330, código 445: assinatura do QR v3 informada fora da contingência offline

• ZX02-334, código 474: assinatura do QR v3 ausente quando a emissão é offline, tpEmis=9

• ZX02-338, código 583: assinatura do QR v3 offline diferente do valor calculado

Portanto, a assinatura pode estar proibida, obrigatória ou incorreta, dependendo da condição analisada. O número da rejeição e o XML precisam ser lidos juntos. NT 2025.001 v1.03 corrigida, página 13

Se o sistema exibe 445, mas o arquivo separado para análise contém tpEmis=9, não apague a assinatura para experimentar. Confirme se esse é exatamente o XML enviado, se houve transformação por uma integração e se o retorno pertence à mesma tentativa. Uma prévia de impressão ou cópia antiga pode não reproduzir o conteúdo recebido pela SEFAZ.

O QR normal e o offline têm conteúdos diferentes

Na emissão normal, o QR v3 carrega três parâmetros: chave de acesso, versão e ambiente. Não contém dia da emissão, total, identificação do destinatário ou assinatura adicional. O fato de essas informações existirem no XML não obriga sua repetição no QR normal.

Na emissão offline, são oito posições. Depois dos três elementos iniciais, vêm dia da emissão, total, tipo de identificação do destinatário, identificação e assinatura. O Manual v6.0 determina que a assinatura seja calculada sobre os parâmetros de 1 a 7, preservando os separadores, com o mesmo certificado digital que assina a NFC-e. A saída prevista é RSA SHA-1 em Base64. Manual DANFE-NFC-e e QR Code v6.0, páginas 29–30

Essas duas assinaturas protegem conteúdos distintos, mesmo quando utilizam o mesmo certificado. Não copie automaticamente o SignatureValue do XML para a posição de assinatura do QR. Também não use o hash do QR v2 ou o DigestValue como substituto. A estrutura v3 não leva CSC, identificador de CSC, hash ou DigestValue como parâmetros.

Um erro possível de implementação é reaproveitar a montagem offline para uma emissão normal. Outro é manter um QR antigo em memória depois de alterar o documento. A correção deve ocorrer no componente que gera o conteúdo transmitido, para que impressão, XML e forma de emissão permaneçam coerentes.

A regra também alcança a NF-e Tipo 2

A NT 2026.002 v1.11 apresenta ZX02-330 para os modelos 55/65, condicionada à presença de QR v3. No modelo 55, o contexto de DANFE Simplificado Tipo 2 é identificado por tpImp=6. Sua versão de QR exigida é 3; o uso de versão diferente tem tratamento próprio, com código 672.

O documento também limita a contingência offline, tpEmis=9, do modelo 55 ao DANFE Simplificado Tipo 2. Não se deve habilitar essa forma de emissão em qualquer NF-e para justificar uma assinatura já existente. Tampouco essas regras criam uma exigência universal de QR nos formatos retrato e paisagem. NT 2026.002 v1.11, páginas 20 e 23

O calendário desse bloco indica testes em 01/07/2026 e produção em 03/08/2026. A versão 1.11 desloca para 14/12/2026 apenas I08-180, BA02-35 e VC02-40. Para a mudança original do QR NFC-e, a NT 2025.001 previa testes até 02/06/2025 e produção até 01/09/2025. São cronogramas documentais específicos, não comprovação de funcionamento idêntico em todas as UFs.

Como organizar a correção sem comprometer o documento

Comece consultando a situação da nota quando houver dúvida sobre a resposta recebida. Isso evita tratar como rejeitada uma tentativa diferente de outra já autorizada. Em seguida, separe o XML transmitido, o retorno completo e a versão do módulo fiscal, sem divulgar certificados, senhas ou dados de clientes em canais públicos.

Peça ao suporte que compare modelo, tpImp, tpEmis, versão do QR e parâmetros gerados. Confirmada uma emissão normal com assinatura indevida, o sistema deve reconstruir o QR conforme o leiaute normal, mantendo a assinatura do XML. Alterar apenas a imagem impressa não muda o conteúdo transmitido para autorização.

Para documento realmente emitido offline, preserve a forma de emissão e sua assinatura de QR obrigatória. O retorno da conexão à internet não transforma automaticamente aquela emissão em normal. O procedimento de transmissão posterior deve manter a coerência do documento, em vez de trocar tpEmis para contornar uma validação.

Faça testes separados para normal e offline, incluindo a sequência dos campos e a leitura do DANFE resultante. Depois de corrigir e transmitir conforme a situação apurada, verifique a autorização e seu protocolo. A ausência de 445, isoladamente, não comprova que todas as demais regras foram atendidas.

Como avaliar uma orientação encontrada na internet

A CIGAM documenta a mudança das estruturas normal e offline; a VARITUS explica o uso da assinatura específica na contingência. A MOVERE distingue 445 e 474 na tabela de mensagens, mas seu exemplo offline está incompleto. Não o copie como receita de montagem.

Há também uma página da TecnoSpeed sobre 445 cuja descrição associa o erro a tpEmis=9. Essa frase conflita com ZX02-330: nas fontes oficiais citadas, a proibição ocorre com tpEmis diferente de 9. Use a condição oficial para evitar retirar uma assinatura obrigatória.

Finalmente, não retorne automaticamente ao QR v2 para escapar da 445. A NFC-e emitida por pessoa física tem restrição específica ao v2, pela regra 444, e o Tipo 2 exige v3. A escolha correta depende do documento; corrigir sua composição é mais seguro que trocar versões sem verificar o contexto.

Isso também não significa que o v2 foi universalmente eliminado para emitentes CNPJ. A NT 2025.001 prevê exclusividade futura do v3 sem data definida. A antiga regra 407 está riscada e foi removida; ela não justifica rejeitar toda adoção de v3 nem estabelecer uma data geral de migração.