Rejeição 583: corrija a assinatura do QR Code de contingência

A rejeição 583 informa que a assinatura enviada no QR Code diverge daquela que o autorizador consegue validar com os dados do documento. Para a empresa, o primeiro cuidado é identificar qual QR Code o sistema produziu. O cenário documentado envolve a versão 3 em emissão offline, com tpEmis=9. Trocar o CSC, alterar o valor da venda ou gerar outra numeração sem investigar pode deixar a causa intacta.

Esse retorno aparece na validação da autorização. Um comprovante impresso durante a contingência não substitui o resultado posterior do processamento. Guarde o XML rejeitado e a resposta recebida, mantendo a operação na fila de regularização até verificar seu desfecho.

Em quais documentos a regra aparece

Na NT 2025.001 v1.03, página 13, a regra ZX02-338 é obrigatória para NFC-e, modelo 65, com QR Code versão 3 e emissão em contingência offline. A versão 1.01 já continha esse controle; ela serve como referência histórica, enquanto a revisão 1.03 é a versão posterior consultada.

A NT 2026.002 v1.11, página 23 estende a linha aos modelos 55/65, quando o QR Code é informado. Para NF-e modelo 55, a própria observação restringe a contingência offline ao DANFE Simplificado Tipo 2, identificado por tpImp=6. Isso não autoriza configurar tpEmis=9 em qualquer NF-e.

O cronograma desse conjunto de alterações aponta produção em 3 de agosto de 2026. O adiamento para 14 de dezembro, registrado na revisão 1.11, alcança outras três regras expressamente indicadas, sem incluir ZX02-338. Essas datas documentais não comprovam a implantação de cada ambiente. Confira UF, autorizador, versão do sistema e disponibilidade do cenário efetivamente utilizado.

Assinatura da versão 3 e hash da versão 2

No QR Code versão 3 offline, a assinatura protege uma sequência de informações da nota. O Manual de Padrões Técnicos do DANFE NFC-e e QR Code, versão 6.0, página 30, especifica os sete primeiros parâmetros, seus separadores e a assinatura acrescentada na oitava posição. O padrão descrito é RSA SHA-1, com resultado em Base64, utilizando o mesmo certificado que assina a NFC-e.

Os parâmetros incluem chave de acesso, versão, ambiente, dia da emissão, valor total e identificação do destinatário conforme o leiaute. O dia possui duas posições; o valor usa ponto decimal. Posições vazias previstas no manual precisam conservar os separadores. A integração deve produzir a sequência exatamente como especificada antes de assiná-la.

Já o QR Code versão 2 utiliza um mecanismo com identificador do CSC e hash, além de informações próprias do fluxo online ou offline. O DigestValue empregado naquele contexto também não pode ser simplesmente copiado como assinatura da versão 3. Uma rotina antiga de geração do QR Code pode continuar funcionando para determinada configuração e falhar ao ser reutilizada na outra.

O problema também não se resolve copiando a assinatura XML do documento para o parâmetro do QR Code. São objetos com conteúdos assinados diferentes. O componente fiscal precisa montar cada estrutura de acordo com seu contrato.

O que costuma precisar de revisão no emissor

Imagine que o caixa gera o QR Code antes de concluir o total da venda. Depois, o sistema recalcula um desconto e transmite um XML com outro valor, mas conserva a assinatura anterior. Esse é um exemplo de divergência que a equipe técnica deve investigar, comparando a sequência assinada com os parâmetros efetivamente enviados.

Outras hipóteses de diagnóstico são a seleção de certificado diferente, separadores removidos, formatação monetária regional e transformação indevida da assinatura durante o transporte da URL. Nenhuma dessas hipóteses é comprovada apenas pelo número 583. O suporte precisa localizar a diferença real, preservando os arquivos de entrada e saída.

Uma imagem de QR Code legível também não demonstra integridade criptográfica. A câmera conseguir ler uma URL apenas comprova que reconheceu seus caracteres. A conferência deve alcançar os dados, a assinatura e a correspondência com o XML final.

A orientação prática da TecnoSpeed associa 583 às notas em contingência e à geração pelo componente emissor. A Avalara contextualiza a mudança para assinatura digital no novo leiaute. Ambos ajudam a direcionar a investigação ao software, sem substituir a regra oficial de modelo, versão e forma de emissão.

Um roteiro seguro para liberar a pendência

1. Confirme cStat e xMotivo no retorno individual da nota, além da chave e do ambiente

2. Identifique modelo, tpEmis, versão do QR Code e, no modelo 55, tpImp e enquadramento no Tipo 2

3. Compare os parâmetros do QR Code com os dados finais do XML, inclusive campos vazios e separadores

4. Peça ao fornecedor que confira o certificado selecionado e a implementação da assinatura prevista no manual

5. Corrija a geração na origem e valide o novo arquivo, mantendo o vínculo com a operação real

6. Confira a situação da chave antes de repetir uma transmissão cujo resultado tenha ficado incerto

7. Guarde a resposta conclusiva e o protocolo aplicável à tentativa corrigida

Não altere preço, destinatário, data ou tipo de emissão para fazer o cálculo passar. Se algum dado estava realmente errado, sua correção deve refletir a operação e passar novamente pelo processo de geração apropriado. XML já autorizado precisa permanecer preservado.

Como evitar que o erro se repita

Inclua o fluxo offline nos testes de atualização do PDV, com destinatário identificado e não identificado, valores com centavos e retorno posterior à conexão. Testar somente a emissão online não exercita a mesma estrutura: no QR Code versão 3 online, o parâmetro de assinatura não deve ser enviado, situação tratada por 445. Na contingência, ausência da assinatura corresponde a 474; divergência de seu valor corresponde a 583.

A documentação da Treeunfe também recomenda revisar dados e algoritmo, mas menciona uma opção chamada “v4”. Essa indicação não foi adotada como versão fiscal do QR Code: as fontes oficiais deste diagnóstico tratam a versão 3. Nome de tela e versão do XML devem ser conferidos separadamente.

Base consultada e limites

Corpus oficial preservado com corte em 9 de outubro de 2026, relido em 10 de outubro; sem certificação operacional por UF. Três editores práticos lidos: TecnoSpeed, rejeição 583, Treeunfe, diagnóstico da assinatura e Avalara, contexto da NT 2025.001. O último é contextual; instruções de produto ou de revisões anteriores não substituem o contrato oficial aplicável.